VHDL-XILINX symulacja ?

Xilinxa nie znam. W Alterze jest 'virtual pin' - wtedy mozna popatrzec, bo optymalizator zostawia ten sygnal.

On Behalf Of jerry1111

Czy "virtual pin" to jest pin przed wprowadzeniem w strukturę? Tzn. rysując_schemat/wprowadzając_algorytm, po wstępnej kompilacji można obejrzeć wyniki dla "wirtualnego scalaka"?

pzdr Artur PS Mój czas jeszcze nie nadszedł, ale co nieco czytam sobie do poduszki ;-)

Nie o to chodzi. Sprawa wyglada tak (zdrrrrowko :), ze robisz sobie uklad - wszystko jedno czy w VHDL, czy schemat namalujesz. Masz jakies sygnaly we/wy oraz jakies wewnetrzne. Podczas kompilacji optymalizator moze co nieco wypieprzyc :-) A jak mu dajesz atrybut 'virtual pin', to nie wypieprza tego sygnalu (tak jakby go nie wypieprzyl gdyby ten sygnal byl naprawde do pina podlaczony). I wtedy w symulatorze mozna ten pin obejrzec.

A czytaj, czytaj :-)

1. Uzywajac 'signalspy' z ModelSim'a. Nie jestem pewien czy wersja XE (starter) ma to narzedzie.
2. Przez 'package' zawierajace sygnal takiego samego typu jak monitorowany. Nalezy przypisac sygnal monitorowany do sygnalu z package. Package trzeba oczywiscie dodac do testbench'a. Polecam to rozwiazanie jako przenosne.

pozdrawiam Robert

jerry1111 napisal(a):

Pod AHDLem sygnal, ktory ma nie zostac wyciety definiuje sie jako LCELL, a nie NODE. Ale warto przy tym zwrocic uwage, ze wstawienie czegos takiego do symulacji, a nastepnie wyciecie (do wersji docelowej na przyklad) powoduje zmiane dzialania ukladu....

BTW sa czasem sytuacje, gdy projekt w malym PLD jest juz upchany, gdy oplaca sie uzyc LCELL zamiast NODE, poniewaz wtedy w ogole mozna 'sfitować' projekt.

AHDLa nie uzywam, ale jak to powoduje zmiane dzialania... :-) to krotko mowiac robi cos innego niz zapobieganie 'wycinaniu' sygnalow.

:-)

W 'duzych' masz w Quartusie parametr 'initial placement' - wstawiasz rozne liczby i wychodzi szybszy/wolniejszy. Znaczy to nie mniej i nie wiecej, tylko ze jest jakas pseudolosowosc w ukladaniu. Roznice bywaja spore - nawet 20% f_max.

jerry1111 napisal(a):

? Zastanow sie. Jesli sygnal nie jest wyciety, to znaczy, ze uklad musi inaczej dzialac. Jest inaczej zoptymalizowany. Przynajmniej ja to tak rozumiem. Jest przepuszczony przez bufor czy inny whatever.

Cos takiego jest czy raczej bylo takze w fitterze do kosci MPA z Motoroli. Czasem projekt dalo sie sfitowac dopiero po ustawieniu Poczatkowego Zapelnienia na wartosc zblizona do wartosci podawanej przez program w LOGu. Bylo tak pomimo malego zapelnienia kosci. No ale powyzej o cos inego mi chodzilo: Mamy mocno zapelniona kostke (np.

7128), a chcemy cos zrobic z duza iloscia sygnalow. Czasem to nie wypali ze wzgledu na brak mozliwosci zrutowania. Wstawienie LCELL spowoduje, ze zostanie wykonana funkcja w jakiejs tam makroceli, w niej zostanie wygenerowany sygnal, z ktorym juz nie bedzie klopotu z rutingiem. Ale oczywiscie kosztem dodatkowego opoznienia.

Wiesz - chodzi o _funkcjonalne_ dzialanie. Jesli design jest synchroniczny, to nie ma prawa byc zmiany dzialania. Co najwyzej zmniejsza sie opoznienia... Poza tym jak optymalizator stwierdza, ze lepiej wyciac sygnal (bo np: nie jest uzywany) to generalnie poprawi to timingi a dzialania nie zmieni. Asynchronicznych ukladow nie robie - co najwyzej na wiecej niz 1 domene clk, ale one dalej synchroniczne sa.

Znaczy interconnecty sie konczyly pewnie.

Zgadza sie - wtedy dobrze przejrzec uklad po P&R. Mozna zobaczyc gdzie mamy 'gesto' z sygnalami.

Ja sie przylaczam do pytania Jerrego, _dozwolone_ wyciecie sygnalu nie ma prawa wplynac na dzialanie ukladu. Od tego wlasnie jest optymalizator, aby powycinal wszystko, co sie da wyciac nie zmieniajac przy tym funkcji realizowanej przez uklad. Jesli jest inaczej, to zachodzi co najmniej jedno z ponizszych:

a) optymalizator jest blednie zaprogramowany, b) uzyta funkcja robi co innego, niz sie uzytkownikowi wydaje.

Nie ma innej mozliwosci. :-)

Pozdrawiam Piotr Wyderski

Znaczy wiesz - tak naprawde to wplywa na dzialanie ukladu, bo cos tam zmienia. Natomiast jesli odnotujemy _funkcjonalne_ zmiany w dzialaniu ukladu (znaczy po prostu zacznie nam zle dzialac), to czepiajmy sie sami siebie za piekny i sensowny kod w VHDL i zostawmy optymalizator w spokoju.

:-)

Znaczy ja zrozumialem, ze chodzi o symulacje po P&R... ale calkiem prawdopodobne, ze Ty masz racje :-)

Zmienia, ale _strukturalnie_, a nie funkcjonalnie.

Zazwyczaj tak, ale bledy w kompilatorach juz widzialem, wiec dlaczego optymalizator mialby ich rowniez nie zawierac? :-) Przeciez formalne narzedzia do weryfikacji i walidacji takiego oprogramowania dopiero raczkuja, wiec jest bardzo prawdopodobne, ze jakies bugi to-to ma.

Pozdrawiam Piotr Wyderski