Kontrola kompilacji w Quartus II dla FPGA Altery Flex i Acex - optymalizacja?
Quartus II - kontrola kompilacji
From: czerstwy <czebaka_at_nospam_o2.pl>
Subject: Quartus II - kontrola kompilacji
Date: Tue, 02 May 2006 09:32:40 +0200
Witam
Mam dwa pytania dotyczące układów altery i kompilacji w środowisku Quartus.
1. Czy/jak można kontrolować kompilację dla mniejszych/starszych rodzin
układów FPGA Altery? Mam na myśli rodziny Flex i Acex. Chodzi mi o to,
że często do działającego już projektu muszę dodawać nową funkcjonalność
ewentualnie poprawiać błędy, co powoduje ponowną kompilację całego
układu i zmianę parametrów typu fmax dla uruchomionej poprzednio części.
Myślałem, że podział projektu na partycje będzie rozwiązaniem ale nie
jest możliwy dla tych układów i nie ma go w darmowej wersji Quartusa.
Czy istnieje jakaś inna metoda przeniesienia już skompilowanego modułu
do nowszej wersji programu?
2. Fitter Quartusa w czasie kompilacji postępuje według jakiegoś
algorytmu. Dwie kompilacje tego samego programu z takimi samymi
ustawieniami dają ten sam wynik, ale można sobie wyobrazić, że w
projektach o zajętości 30% jest wiele metod rozmieszczenia układu
logicznego w dostępnym fizycznym. Jeśli dobrze rozumiem to fittera mozna
kontrolować przy użyciu parametrów (Dostępnych w
Project->settings->fitter settings): Seed, Placement Effort Multiplier,
Router Effort Multiplier. Czy istnieje jeszcze jakaś metoda poprawienia
parametrów układu (sprawdzonego i działającego) niż napisanie skryptu w
TCL i przepuszczenia kompilacji przez kilkadziesiąt kombinacji tych
parametrów a potem wybranie najlepszej?
Może ktoś spotkał się juz z tymi zagadnieniami i mógłby mi coś poradzić
lub wskazać jakieś materiały źródłowe.
Pozdrawiam
czerstwy
From: JA <j_andr_bezsmieci_at_nospam_freeent.de>
Subject: Re: Quartus II - kontrola kompilacji
Date: Wed, 03 May 2006 20:11:25 +0200
czerstwy:
1. Czy/jak można kontrolować kompilację dla mniejszych/starszych rodzin
układów FPGA Altery? Mam na myśli rodziny Flex i Acex. Chodzi mi o to,
że często do działającego już projektu muszę dodawać nową funkcjonalność
ewentualnie poprawiać błędy, co powoduje ponowną kompilację całego
układu i zmianę parametrów typu fmax dla uruchomionej poprzednio części.
Myślałem, że podział projektu na partycje będzie rozwiązaniem ale nie
jest możliwy dla tych układów i nie ma go w darmowej wersji Quartusa.
Czy istnieje jakaś inna metoda przeniesienia już skompilowanego modułu
do nowszej wersji programu?
teoretycznie mozesz poprosic quartus o back-annotate projektu,
ktory spelnia twoje oczekiwania timingowe, a potem dodac/zmienic
jakis modul;
pisze 'teoretycznie', bo kiedys uznalem to za dobre rozwiazanie,
ale w praktyce prawie zawsze quartus po takim 'back-annotate'
jakiegos kawalka raportowal niemoznosc rutowania calosci;
takie proby robilem z q.4x, moze w wersji 5.1 jest lepiej;
2. Fitter Quartusa w czasie kompilacji postępuje według jakiegoś
algorytmu. Dwie kompilacje tego samego programu z takimi samymi
ustawieniami dają ten sam wynik, ale można sobie wyobrazić, że w
projektach o zajętości 30% jest wiele metod rozmieszczenia układu
logicznego w dostępnym fizycznym. Jeśli dobrze rozumiem to fittera mozna
kontrolować przy użyciu parametrów (Dostępnych w
Project->settings->fitter settings): Seed, Placement Effort Multiplier,
Router Effort Multiplier. Czy istnieje jeszcze jakaś metoda poprawienia
parametrów układu (sprawdzonego i działającego) niż napisanie skryptu w
TCL i przepuszczenia kompilacji przez kilkadziesiąt kombinacji tych
parametrów a potem wybranie najlepszej?
'seed' to wyjsciowe rozlozenie logiki, ktore nastepnie placer
usiluje poprawic;
zdazylo mi sie kilka razy, ze zmiana 'seed' umozliwila pomyslna
kompilacje projektu, ktory 'wykladal' sie z powodu braku zasobow,
[wykorzystanie fpga > 90%], watpie, by zmaina 'seed' poprawila znaczaco
timing, Fmax, zwlaszcza w projekcie, ktory zajmuje tylko ok. 30% fpga;
zeby poprawic szybkosc, musisz uwaznie przeczytac czesc manuala
dotyczaca timing constrains i zastosowac w praktyce;
zwykle najwieksze mozliwosci poprawienia maksymalnej czestotliwosci
projektu tkwia w samym kodzie RTL;
dla przykladu - warto czasami zduplikowac FSM, jesli steruje ona
wielka iloscia logiki, albo uzyc wew. pamieci jako LOOK-UP table
zamiast wielopoziomowej logiki kombinacyjnej;
czerstwy
JA