Quartus II - kontrola kompilacji

May 02, 2006 1 Replies

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?


  1. 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


czerstwy:

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;

'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;

JA

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required