VHDL-XILINX symulacja ?

Dec 23, 2003 14 Replies

Witam



W jaki sposób mo¿na podczas symulacji uk³adu (Xuilinx ISE WebPack-ModelSim XE) obserwowaæ sygna³y wewnêtrzne (nie wyprowadzone na port). Poni¿ej przedstawiam projekt licznika z wyprowadzonym tylko najstarszym bitem. W jaki sposób ¶ledziæ wszystkie bity licznika, czy konieczne jest pod³±czenie ich do portu?



Jarek


-----test.vhd library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;



entity Test is Port ( clock: in std_logic; -- system clock (25 MHz) resetn: in std_logic; -- active low reset c_out: out std_logic); end Test;



architecture Behavioral of Test is



signal counter: std_logic_vector(3 downto 0); begin



COUNT: process (clock, resetn) begin if (resetn = '0') then counter <= (others => '0'); elsif (clock'event and clock = '1') then counter <= counter + 1; end if; end process;



c_out <= counter(3);



end Behavioral;


--------------Program do symulacji



LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.ALL;



ENTITY testbench IS constant Period : time := 40 ns; -- 25 MHz System Clock END testbench;



ARCHITECTURE behavior OF testbench IS



COMPONENT test PORT( clock : IN std_logic; resetn : IN std_logic; c_out : OUT std_logic ); END COMPONENT;



SIGNAL clock : std_logic := '0'; SIGNAL resetn : std_logic; SIGNAL c_out : std_logic;



BEGIN



uut: test PORT MAP( clock => clock, resetn => resetn, c_out => c_out );



clock <= not clock after (Period / 2); resetn <= '0', '1' after Period;



tb : PROCESS BEGIN wait; -- will wait forever END PROCESS;



END;



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.

:-)

Witam Nie jest konieczne pod³±czanie do portu.

W WebPack'u:

- po utworzeniu pliku symulacji (test bencha) i klikniêciu na nim wybierasz w kokienku poni¿ej opcjê "Simulate Behavioral VHDL Model"

Otwiera siê ModelSim z symulacj±:

- w oknie "Structure" klikasz na tej czê¶ci modelu, której sygna³y chcesz ogl±daæ (tu bêdzie to pewnie drugi od góry na li¶cie)

- przechodzisz do okna "Signals" i powinien byæ widoczny licznik (czyli Twój counter), który przeci±gasz sobie na okno Wave i zapuszczasz symulacjê jeszcze raz (Reset All + Run All)

Pozdrawiam Bartosz Sarama

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

Nie ma sensu robiæ symulacji P&R je¶li nie dzia³a Behavioral Post and Route w zasadzie ogranicza siê najczê¶ciej do ostatniego etapu symulacji ca³ego uk³adu (o ile jest poprawnie i sensownie zbudowany - w przeciwnym wypadky rzeczywi¶cie trzeba robiæ zamiast Behaviorala :-)

Pozdrawiam Bartosz Sarama

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

Join the Discussion

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

Didn't find your answer?

Ask the community — no account required