Temat: A structured VHDL design method (Jiri Gaisler) - czy ktoś...

Witam!

Pytanie jak w temacie. Czy ktoś stosował tę metodologię (bo chyba tak to można nazwać) w praktyce? Chodzi mi głównie o rezultaty syntezy w FPGA (Xilinx). Po przejrzeniu źródeł LEON'a dochodzę do wniosku, że ta metodologia ma sens! Spróbowałem jej na małym projekciku dla Virtex-5 (platforma XUPV5) i przy pierwszym podejściu wyniki syntezy były o gorsze o ok 80% (zajętość) oraz 40% (zegar) w stosunku do modelu referencyjnego (duża liczba prostych procesów - to co panu Gaislerowi się nie podoba). Po pewnym treningu - a właściwie przyzwyczajeniu - po trzecim podejściu (za każdym razem zaczynałem od początku - bez wykorzystania modeli z poprzedniej iteracji) uzyskałem rezultaty identyczne (zajętość + zegar) z modelem referencyjnym.

Jestem w przededniu dosyć dużego projektu i interesuje mnie czy są (w praktyce) tak duże korzyści płynące z zastosowania tejże metodologii. Moje największe obawy dotyczą sensownego "poradzenia sobie" przez XST z dużymi procesami pełnymi zmiennych. Przy pierwszym podejściu sprawdziłem jeszcze Precision i rezultat syntezy był lepszy od tego z XST. Jak inne oprogramowanie do syntezy "radzi sobie" z opisem zgodnym z metodologią pana Gaislera.

Z góry dziękuję za wszelkie informacje!

Temat: A structured VHDL design method (Jiri Gaisler) - czy ktoś...

Witam,
Kiedyś widziałem taki kawałek kodu. Wydał mi się nieczytelny. Przyzwyczajony jestem do tradycyjnego kodowania.
Bez wątpienia podejście Gaislera posiada zalety, o których mówi w swojej prezentacji.
Nie zanosi się jednak, żebym miał zmienić swoje przyzwyczajenia.
Zastanawiam się jak można przy tym podejściu rozwiązać synchronizację niezależnych domen zegarowych.
Inna sprawa to nie wszystko da się zsyntezować, trzeba czasem użyć prymitywów. Np. (Xilinx) użycie BlokRAM'u z dwoma różnymi zegarami i różną szerokością danych. Pewnie da się to zrobić, ale czy warto?

Pozdrawiam,

JG

Temat: A structured VHDL design method (Jiri Gaisler) - czy ktoś...

pracowalem kiedys z kodem napisanym w ten sposob. Jak dla mnie jest bardzo nieczytelny, byc moze to kwestia przyzwyczajenia. W kazdym razie dodajac nowa funkcjonalnosc kilka razy sie wylozylem zanim napisalem to poprawnie.

Ograniczenie do dwoch procesow (synchroniczny i async) per architecture jest dosc sztuczne i ograniczajace.

Jeden proces synchroniczny oznacza ten sam reset dla wszystkich rejestrow. A co jesli koniecznosci optymalizacji wymaga uzycia roznych resetow (np DSP48 reset tylko synchroniczny). Jesli rejestr nie potrzebuje resetu lepiej go nie dodawac wogole bo przy duzej zajetosci kosci > 95% i bardzo szybkich zegarach (200-300 MHz) duzy fan-out na resecie spowoduje skew/duze opoznienia routingu ktore moga byc do usuniecia tylko przez logic replication.

Zastanawiam sie tez czy zadziala dodawanie roznych dyrektyw do syntezy typu synthesis direct enable na rejestrze ktory jest polem w recordzie.

Oraz jak wpasowac w te dwa procesy potrzebe uzycia konstrukcji generate.

Temat: A structured VHDL design method (Jiri Gaisler) - czy ktoś...

Witam!

Dziękuję za wszystkie spostrzeżenia!. Jeżeli chodzi o niezależne domeny zegarowe, to chyba to podejście faktycznie się nie sprawdzi (chociaż to może kwestia braku doświadczenia w stosowaniu metodologii :). Przyjrzałem się dokładniej LEON'owi (ale nie całemu - jest tego za dużo) i wydaje mi się, że ta metodologia nie jest stosowana ortodoksyjnie i są miejsca, w których podejście "klasyczne" występuje.

Myślę, że głównym powodem powstania tej metodologii był właśnie konieczność opisu układów pracujących w jednej domenie zegarowej, których działanie można opisać przy zastosowaniu schematu przedstawionego w pracy Gaisler'a. Bo tak naprawdę schemat ten teoretycznie opisuje *dowolny* układ logiczny, pracujący z pojedynczym źródłem sygnału zegarowego.

Co do czytelności kodu, to tutaj polemizowałbym. Faktycznie, z początku trzeba się trochę przyzwyczaić, ale potem jest łatwiej. Mnie osobiście najbardziej podoba się wykorzystanie rekordów - zwłaszcza do sygnałów w entity. Ten element metodologii Gaislera - nawet przy odrzuceniu pozostałej je części - uważa ma b. pożyteczny i wart stosowania.

Jeżeli chodzi o syntezę, to przypadkowo "odkryłem" pewną właściwość przy stosowaniu metodologii Gaisler'a z XST. Otóż, jeżeli pojawiają się sygnały wychodzące, które to są niczym innym jak wyprowadzeniem zawartości rejestrów, to znacznie lepsze efekty (w sensie opóźnień na ścieżce krytycznej) uzyskuje się przy stosowaniu "tradycyjnego" podejścia, niż w przypadku metodologii Gailsera, gdzie sygnały te powinny zostać "wyprowadzone" z procesu asynchronicznego. Teoretycznie synteza powinna dać identyczne rezultaty, bo przecież wyprowadzenie zawartości rejestru "na zewnątrz" jest niczym innym jak funkcją out(x)=rejestr(x) (oczywiście zapis w dużym uproszczeniu), ale w XST tak nie jest. Nie sprawdzałem, czy właściwość ta występuje w przypadku innych programów do syntezy, natomiast dla XST wystąpiła w dla trzech różnych układów.

Szczerze mówiąc kusi mnie, by w tym jednym projekcie spróbować zastosować tę metodologię, tym bardziej, że nie spodziewam się niezależnych domen zegarowych. A nawet jeżeli się zdarzą, to przecież zawsze punkt styku można potraktować jako sygnał asynchroniczny dla strony "after" i zaimplementować odpowiednie FIFO czy też inny mechanizm zwalczania metastabilności

pozdrawiam
MS

Temat: A structured VHDL design method (Jiri Gaisler) - czy ktoś...

Michał Szulc:Teoretycznie synteza powinna dać identyczne rezultaty, bo przecież wyprowadzenie zawartości rejestru "na zewnątrz" jest niczym innym jak funkcją out(x)=rejestr(x) (oczywiście zapis w dużym uproszczeniu), ale w XST tak nie jest. Nie sprawdzałem, czy właściwość ta występuje w przypadku innych programów do syntezy, natomiast dla XST wystąpiła w dla trzech różnych układów.

Na wstępie chciałbym się przywitać w grupie:
Witam!

Prawdopodobnie w pierwszym przypadku rejestry wyjściowe nie są umieszczane w IO Blocku i dlatego opóźnienie jest większe niż w drugim przypadku.

Problem dość często występuje jeżeli jakiś program do syntezy dokona takich optymalizacji, które zastąpią dwa rejestry jednym. Jeżeli wyjścia z dwóch rejestrów wychodzą na dwa różne PADy to w tym momencie narzędzie nie jest w stanie umieścić rejestru w IOB. Jeżeli ustawimy odpowiednie opcje albo oszukamy narzędzie to w w/w przypadku zostaną umieszczone dwa rejestry w różnych IOB.

Rejestr wyjściowy może być umieszczony w IOB jeżeli jego stan nie jest wykorzystywany. Już kilka razy spotykałem się z sytuacją gdy w kodzie stan jakiegoś rejestru nie był wykorzystywany a ISE po wielu optymalizacjach tak to zrobiło, że stan rejestru był "zawracany" no i nie można było wrzucić go w IOB. Dość dobrze, te zjawisko można przeanalizować w PlanAhead.

(Pisząc rejestr mam na myśli jeden bit lub więcej bitów mając świadomość że jeden bit odpowiada jednemu blokowi IOB)Tomasz Tarkiewicz edytował(a) ten post dnia 11.02.11 o godzinie 17:37