Języki Opisu Sprzętu Studium Zaoczne III rok kierunek Elektronika Język VHDL cz.3
Program wykładu Wstęp do syntezy Sprzętowa reprezentacja obiektów w VHDL Synteza obiektów VHDL Synteza instrukcji VHDL Przykłady aplikacji Kontakt z prowadzącymi: C-3 p.502 tel. (617)3980 dr inŝ. Jerzy Kasperek kasperek@uci.agh.edu.pl dr inŝ. Paweł J.Rajda pjrajda@uci.agh.edu.pl Archiwum wykładu http://fpga.elektro.agh.edu.pl/dydaktyka
Wstęp do syntezy Literatura: A VHDL Synthesis primer J.Bhasker, VHDL A Logic Synthesis Approach D.Naylor, S.Jones, Reuse Methodology Manual M.Keating, P.Bricaud, Xilinx Foundation Express User Guide Synopsys, Inc.
Projekt oparty o VHDL w środowisku Aldec AHDL Zewnętrzne narzędzia do przeprowadzenia syntezy i Implementacji Graficzny Shell po wybraniu Opcji: Prefereces/Flows/ Xilinx Flow (TCL based)
Sprzętowa reprezentacja obiektów w VHDL Obiekt - sygnał lub zmienna moŝe być reprezentowany jako: przewód przerzutnik (element pamięciowy wyzwalany zboczem) przerzutnik latch (element pamięciowy wyzwalany poziomem)
Sprzętowa reprezentacja obiektów w VHDL signal A,B,C,D: bit... NO_MEMORY: process (A,B,C) variable TMP: bit; TMP:= A and B; D <= TMP or C; end process; A TMP B C Implementacja TMP : przewód D signal A,B,C: bit... IS_IT_LATCH: process (A,B,C) variable TMP: bit; C <= TMP and B; TMP := A or C; end process; Implementacja TMP : zatrzask?!
Synteza typów numerycznych: Integer, real Typy i podtypy które zawierają wartości ujemne w swojej definicji zakresu kodowane są w kodzie uzupełnień do 2 Typy i podtypy które zawierają tylko wartości dodatnie kodowane są binarnie Liczb uŝytych bitów zaleŝy od największej dopuszczalnej wartości dla danego obiektu type int0 is range 0 to 100 -- a binary encoding having 7bits. type int1 is range 10 to 100 -- a binary encoding having 7bits type int2 is range -1 to 100 -- a 2's complement encoding having -- 8 bits (including sign). subtype int3is int2range 0 to 7 -- a binary encoding having 3bits.
Synteza typów numerycznych: Integer, real type short is integer 0 to 255; subtype shorter is short range 0 to 31; subtype shortest is short range 0 to 15;. signal op1,op2,res1 : shortest; signal res2 : shorter; signal res3 : short res1 <= op1 + op2;-- truncate carry res2 <= op1 + op2;-- use carry res3 <= op1 + op2;-- use carry and zero extend
Synteza typów wyliczeniowych Typy wyliczeniowe syntezowane są przez binarne kodowanie. Poszczególnym elementów asygnowane są kolejne wartości przy czym pierwszy od lewej otrzymuje wartość zero. Liczba asygnowanych elementów (n) będzie najmniejsza z moŝliwych liczba elementów <= 2**n Typ bit jest syntezowany jako wire Typ character jest syntezowany jako 8 x wire
Synteza typów wyliczeniowych Deklaracja: Jest syntezowana jako type direction is (left, right, up, down); -- Two wires. type cpu_op is (execute, load, store); -- Two wires; -- the encoding of -- 11 is a "don't care." subtype mem_op is cpu_op range load to store; User Defined Encoding Two wires; the encodings of 00 and 11 are "don't cares. attribute enum_encoding of enum_t : type is "001 010 100"; -- or... : type is "one hot"; -- or... : type is "1-hot";
Typ: std_logic_1164 type std_ulogic is ('U', -- Uninitialized 'X', -- Forcing Unknown 0', -- Forcing 0 '1', -- Forcing 1 'Z', -- High Impedance 'W', -- Weak Unknown 'L', -- Weak 0 'H', -- Weak 1 '-' -- Don't care ); attribute enum_encoding of std_ulogic : type is "M M 0 1 Z M 0 1 -"; '0' 'L' -- Logic value 0 '1' 'H' -- Logic value 1 'Z' -- Logic value tristate 'U' 'X' 'W' -- Metalogic value '-' -- Don t care value
Synteza instrukcji przypisań - operatory logiczne entity logical_ops_1 is port (a, b, c, d: in bit; m: out bit); end logical_ops_1; architecture example of logical_ops_1 is signal e: bit; m <= (a and b) or e; -- concurrent signal e <= c xor d; -- assignments end example; entity logical_ops_2 is port (a, b: in bit_vector (0 to 3); m: out bit_vector (0 to 3)); end logical_ops_2 architecture example of logical_ops_2 is m <= a and b; end example;
Synteza instrukcji przypisań - operatory relacji entity relational_ops_1 is port (a, b: in bit_vector (0 to 3); m: out boolean); end relational_ops_1; architecture example of relational_ops_1 is m <= a = b; end example; entity relational_ops_2 is port (a, b: in integer range 0 to 15; m: out boolean); end relational_ops_2; architecture example of relational_ops_2 is m <= a >= b; end example;
Synteza operatorów arytmetycznych package example_arithmetic is type small_int is range 0 to 7; end example_arithmetic; use work.example_arithmetic.all; entity arithmetic is port (a, b: in small_int; m: out small_int); end arithmetic; architecture example of arithmetic is m <= a + b; end example;
Synteza instrukcji wyboru VHDL wyraŝenia współbieŝne (concurrent) conditional signal assignment ( when.. ) selected signal assignment (with.. ) VHDL wyraŝenia sekwencyjne (sequential) (if.. ) (case..)
Synteza współbieŝnych instrukcji wyboru entity control_stmts is port (a, b, c:in boolean; m: out boolean); end control_stmts; architecture example of control_stmts is m <= b when a else c; end example; entity control_stmts is port (sel: bit_vector (0 to 1); a,b,c,d : bit; m: out bit); end control_stmts; architecture example of control_stmts is with sel select m <= c when b"00", m <= d when b"01", m <= a when b"10", m <= b when others; end example;
Synteza sekwencyjnych instrukcji wyboru entity control_stmts is port (a, b, c: in boolean; m: out boolean); end control_stmts; architecture example of control_stmts is process (a, b, c) variable n: boolean; if a then n := b; else n := c; end if; m <= n; end process; end example;
Synteza sekwencyjnych instrukcji wyboru
Synteza sekwencyjnych instrukcji wyboru entity control_stmts is port (sel: bit_vector (0 to 1); a,b,c,d : bit; m: out bit); end control_stmts; architecture example of control_stmts is process (sel,a,b,c,d) case sel is when b"00" => m <= c; when b"01" => m <= d; when b"10" => m <= a; when others => m <= b; end case; end process; end example;
Synteza instrukcji powielających logikę entity loop_stmt is port (a: bit_vector (0 to 3); m: out bit_vector (0 to 3)); end loop_stmt; architecture example of loop_stmt is process (a) variable b:bit; b := '1'; for i in 0 to 3 loop --don't need to declare i b := a(3-i) and b; m(i) <= b; end loop; end process; end example;
Synteza instrukcji powielających logikę entity subprograms is port (a: bit_vector (0 to 2); m: out bit_vector (0 to 2)); end subprograms; architecture example of subprograms is function simple (w, x, y: bit) return bit is return (w and x) or y; end; process (a) m(0) <= simple(a(0), a(1), a(2)); m(1) <= simple(a(2), a(0), a(1)); m(2) <= simple(a(1), a(2), a(0)); end process; end example
Synteza instrukcji powielających logikę
Synteza instrukcji sekwencyjnych Specyfikacja warunkowa if clk then y <= a; else -- do nothing end if; if clk then y <= a; else y <= b; end if; if clk and clk'event then y <= a; end if; sygnał y - latch sygnał y- mux sygnał y- D Flip Flop
Instrukcje implikujące syntezę do FF typu latch process (clk,a,b) -- a list of all signals used in the process if clk then y <= a and b; end if; end process; procedure my_latch (signal clk, a, b: in boolean; signal y: out boolean) if clk then y <= a and b; end if; end; -- A concurrent conditional signal assignment, y <= a and b when clk else y; y <= a and b when clk;
Instrukcje implikujące syntezę do FF typu D Proces zawierający listę aktywującą: process (clk) --a list of all signals that result in --propagation delay if clk and clk'event then --rising clock edge y <= a and b; end if; end process; Proces zawierający klauzulę wait: process wait until not clk; --falling clock edge y <= a and b; end process; Procedura uŝyta jako wywołanie współbieŝne: procedure my_ff (signal clk, a, b: boolean; signal y: out boolean); if not clk and clk'event then --falling clock edge y <= a and b; end if; end; WspółbieŜne przypisania warunkowe: y <= a and b when clk and clk'event else y; -- ERROR y <= a and b when clk and clk'event;--fpga Express SYNTAX-ERR
Instrukcje implikujące synchroniczny Set/Reset process(clk) if clk and clk'event then -- clock rising if set then y <= true; -- y is type boolean else y <= a and b; end if; end if; end process; -- 29 bits reset, 3 bits set by init process wait until clk -- clock rising if init then y <= 7; -- y is type integer else y <= a + b; end if; end process;
Instrukcje implikujące synchroniczny Set/Reset y <= false when reset else a when clk and clk 'event else y; process (clk, reset) if reset then q <= false; -- y is type boolean else if clk and clk'event then -- clock rising q <= d; end if; end if; end process; procedure ff_async_set (signal clk, a, set: boolean; signal q : out boolean) if set then q <= true; elsif clk and clk'event then -- clock rising q <= a; end if; end;
Struktura Jednolita struktura projektów UŜycie zmiennych systemowych w ścieŝkach do projektów UŜycie przyrostków w nazwach plików dla określenia ich zawartości (np.: _tb, _beh, _struct, _rtl, _synt, _impl itp.) Komentarze Nagłówek kaŝdego pliku (skryptu teŝ) zawiera: nazwę pliku, autora, opis funkcji, datę utworzenia, historię modyfikacji) Komentarz opisuje intencje projektanta, a nie zachowanie się kodu Kasowanie złego kodu (zamiast zamiany na komentarz) Układ Wcięcia na min. 3 spacje Styl kodowania Jedna operacja na jedną linię kodu
Styl kodowania Układ c.d. Limit długości linii (przeniesienie logiczne!) UŜycie tabulatorów np. w klauzuli port deklaracji entity Składnia Grupowanie często uŝywanych operacji w podprogramy UŜywanie pętli i tablic Minimalizowanie liczby poziomów zagnieŝdŝenia instrukcji warunkowych Kapitalizacja Nie dodawać znaczenia przez uppercase w narzędziach case-insensitive Zamiast tego uŝywać przedrostków i przyrostków UŜywać underscore zamiast uppercase dla oddzielania słów UŜywać uppercase tylko dla stałych
Styl kodowania Identyfikatory UŜywać znaczących nazw (min. 5 znaków) Nazywać obiekty stosownie do ich funkcji, a nie typu Nie wykorzystywać zakresu działania obiektów Wykorzystywać stałe symboliczne (nie magiczne ) Język VHDL Parametryzacja kodu (szerokość magistral, atrybuty np.: left) W kaŝdym pliku źródłowym tylko jedna jednostka projektowa: (entity, architecture, configuration, package) Deklaracja portów w porządku interfejsów, a nie ich kierunku Etykiety dla instrukcji współbieŝnych (process!) oraz end Nie tworzyć zbyt wielu podtypów (range zamiast subtype) Nie uŝywać trybu buffer (sprzęŝenia zwrotne lokalne) Nie uŝywać przypisań guarded i sygnału guard
Styl kodowania UŜywać nazwy clk dla sygnałów zegarowych i rst dla sygnałów kasowania Nie zmieniać nazwy tego samego sygnału w poszczególnych blokach projektowanego systemu Zaznaczać poziom aktywności sygnału, np. sygnały aktywne stanem niskim kończyć: _n UŜywać porządku downto w obiektach wektorowych Standard VITAL IEEE1076.4: Nie uŝywać underscore w nazwach entity. Po syntezie jest on uŝywany w pliku SDF. Konwencje nazw deklaracji architecture: ARCHITECTURE rtl OF my_syn_model IS dla symulacji po syntezie lub: ARCHITECTURE simof my_behave_model IS dla symulacji behawioranej. W deklaracjach portmap uŝywać notacji specyfikacyjnej Stosować tylko typ std_logic
Styl projektowania CLK Modelowa struktura projektu: Jeden sygnał zegarowy Wszystkie przerzutniki wyzwalane tym samym zboczem Problemy przy dwóch aktywnych zboczach: ZaleŜność od współczynnika wypełnienia (tolerancja na zmiany duty cycle w dokumentacji projektu!) Problemy z metodą testowania typu ścieŝka brzegowa (JTAG 1149)
Styl projektowania CLK Asynchroniczne kluczowanie zegara - same problemy! (niewykorzystanie zasobów dystrybucji sygnałów zegarowych, problemy z testowaniem, gorsze parametry czasowe itp.) Rozwiązanie stosowanie wejść CE kodowanie przez warunek: if ce= 1 po sekwencji if clk event and clk= 1.
Styl projektowania CLK Nie naleŝy stosować wewnętrznie (asynchronicznie!) generowanych sygnałów zegarowych. CE CLK NaleŜy natomiast projektować układy synchroniczne lub uŝywać kilku sygnałów zegarowych (patrz: DLL).
Styl projektowania AA B CC A+B+C A+B+C
Kodowanie uwzględniające proces syntezy 1. Rejestry wyjściowe dla sygnałów 2. Jeden atrybut signal event na jeden proces 3. Sterowanie sygnału tylko z jednego procesu (jeŝeli występuje potrzeba kontroli z 2 lub więcej procesów ok- ale wtedy potrzebny dodatkowa instrukcja arbitraŝu) 4. Odpowiedni podział modułów logiki kombinacyjnej 5. Podział na bloki z uwagi na wymaganą szybkość działania (speed versus area optimisation) 6. Rozdzielenie bloków logiki asynchronicznej i synchronicznej (instrukcja process a instrukcje współbieŝne) 7. Odpowiednie rozwiązania dla modułów realizujących funkcje arytmetyczne 8. Grupowanie sygnałów pod kątem czasu syntezy 9. Unikanie multicycle paths czyli ścieŝek sygnałów, które odchodzą od reguły jednego okresu.
Weryfikacja projektów Weryfikacja zajmuje 70% czasu realizacji projektu ( critical path ) Zagadnieniami weryfikacji zajmuje się dwa razy więcej inŝynierów niŝ wprowadzaniem projektu (oddzielne ekipy!) Kod testbencha stanowi do 80% całego projektu
Weryfikacja Specyfikacja Interpretacja Transformacja Model źródłowy Model docelowy Weryfikacja Transformacja to n.p.: kodowanie RTL, synteza, implementacja Weryfikacja wymaga wspólnego początku z transformacją Uwaga na human factor - jeŝeli ten sam projektant przeprowadza interpretację, kodowanie i weryfikację.
Weryfikacja Automatyzacja (pomysł OK, ale jak go zrealizować?) Strategia atomizacji problemu: sprowadzenie ludzkich decyzji do elementarnych problemów Wprowadzenie redundacji: dwa konkurencyjne zespoły Interpretacja A Model źródłowy Transformacja Specyfikacja Model docelowy Interpretacja B Model źródłowy Weryfikacja
Weryfikacja 1. Porównanie zgodności Porównanie dwóch list połączeń (netlist) Wykrycie ew. błędów narzędzia syntezy Model RTL Synteza Weryfikacja Functional verification answers the question: did I build the right thing? as opposed to implementation verification, which answers the question did I build the thing right? Model po syntezie 2. Sprawdzanie modelu Sprawdzenie zachowania się modelu w sytuacjach błędnych Problem: jak te sytuacje znaleźć? (automaty stanu, inne zachowanie się magistral itp.) Specyfikacja Interpretacja Kodowanie RTL Problemy Model RTL Sprawdzanie modelu
Weryfikacja formalna Linting ALINT is a highly optimized HDL design rule checker. ALINT includes a clear and informative set of violation messages, generated during linting with a direct cross-link to source code, for early bug detection, ensuring correct RTL code early in the design cycle. Key Features Supports 200 VHDL and Verilog Design Rules. Clock Domain Crossing (CDC) support. Source code checks, design elaboration and synthesis emulation. User Modified Design Rules. Cross-Probing of error messages, Violation Viewer. Configuration Management
Przykłady reguł ALINT LINT_3003: Memory '%s' is read and written at the same time Sample Code: process (clk, address, data, rw) type ramtype is array(natural range <>) of std_logic_vector(7 downto 0); variable ram : ramtype(15 downto 0); if (rising_edge(clk)) then if (rw = '1') then ram(address) := data; end if; data <= ram(address); end if; end process; LINT_3001 Incomplete sensitivity list Sample Code: process (clk) if (reset = '1') then sig <= '0'; elsif (rising_edge(clk)) then sig <= not clk; end if; end process; LINT_5009 Reset signal '%s' is active high and low Sample Code: architecture tb of tb is signal a, b : std_logic; process (reset) if (reset = '1') then a <= '0'; end if; end process; process (reset) if (reset = '0') then b <= '0'; end if; end process; end architecture tb;
Weryfikacja a testowanie Kodowanie Wytwarzanie Specyfikacja Model Krzem Weryfikacja Testowanie Pomyłki Zły Projekt Błędy Brak błędów Typ II Dobry Projekt Typ I Basic goals of any comprehensive verification process: 1. It must verify that the design does everything it is supposed to do. 2. It must verify that the design does not do anything it is not supposed to do. 3. It must show when the first two goals have been met.
Plan weryfikacji Współczesne realia wymagają definiowania czasu realizacji poszczególnych etapów projektu (w tym czasu weryfikacji). 1. Odpowiednia i dokładna specyfikacja (kiedy koniec?) 2. Plan pierwszego sukcesu (tylko najwaŝniejsze funkcje) 3. Definicja poziomu weryfikacji: unit-level, system-level, board-level 4. Strategie weryfikacji (black-box, white-box, grey-box, losowa) 5. Identyfikacja weryfikowanych funkcji 6. Priorytety (must-have, should-have, nice-to-have) 7. Projektowanie łatwo weryfikowalne (design for verification) (np.: elementy ładowalne, wprowadzanie modułów w tryb przeźroczysty (unit bypass), punkty weryfikacji (sample points), error injection mechanism itp.)
Weryfikacja funkcjonalna - pytania What Documents? Hardware Requirements Specification Commerical Bus/Component Specifications Hardware Design Specification Verification Environment Specification Test Plan ISO 9000 Process Flow Error Logs Status Reports What Lanaguage for Verification? Specman (HVL) Vera (HVL) System Verilog SystemC with SCV (SystemC Verification Library) TestBuilder (C++) Custom C++ Verilog VHDL Za: http://home.comcast.net/~cnibb/ Chet Nibby's Functional Verification Page
Weryfikacja funkcjonalna - pytania What HDL design Language? Verilog VHDL Mixed Verilog/VHDL What HDL level? Block (unit) Device System What test visibility? Black box White box Gray box Type of test? Directed Random Directed Random What data level? Vector or bit Transaction Data creation? Manual Random Generation (Pre-run) Random Generation (On-the-fly) Testbench checking? Manual Golden model Self-checking (Post-run) Self-checking (On-the-fly) Assertion Checking Are we done? Code coverage Functional coverage Other Considerations? Source Control DUT Performance Code Reuse Regression Testing Load Sharing Simulation performance Acceleration Gate Level
Weryfikacja funkcjonalna - pytania
Zarządzanie procesem weryfikacji Kontrola kolejnych wersji/rewizji Obsługa zdarzeń weryfikacji: - wykryte błędy, - wykryte błędy lub niespójności w specyfikacji, - zagadnienia optymalizacji area/speed, - nowe pomysły na kolejne warianty weryfikacji, Obsługa: - rozmowa z inŝynierem/-ami (w wielu małych firmach działa ) wady brak jasnej odpowiedzialności, brak historii, - karteczka na biurko inŝyniera wady czasami się odkleja... i spada na podłogę + brak priorytetyzacji zadań, brak historii.. - procedury, - bazy danych. W kaŝdej z metod czas przeznaczony na zgłoszenie błędu nie powinien być dłuŝszy niŝ korekta błędu!
TESTBENCH połączenie Process/Component Process Component TestBench Signals UUT Rodzaje procesów testujących Ad Hoc Zbiór wektorów testowych do podstawowych testów funkcjonalnych. Algorytmiczny Prosty algorytm generujący wymuszenia, np. pętla zwiększająca zmienną przez cały jej zakres do testowania dekodera lub ALU. Plik wektorów Rozwiązanie strukturalne: proces czytający plik z wektorami do testowania. NAJLEPIEJ: Testbench automatycznie sprawdzający działanie i generujacy wynik: Error lub OK!!!
TESTBENCH przykład General Testbench Guidelines: -osobne procesy : -obsługa danych, -zegar systemowy, -asynchroniczne sterowanie (reset)
TESTBENCH przykład library IEEE; use IEEE.STD_LOGIC_1164.all; entity counter_tb is end counter_tb; architecture TB_ARCHITECTURE of counter_tb is -- Component declaration of the tested unit component counter port( CLK : in STD_LOGIC; DATA : in STD_LOGIC_VECTOR(3 DOWNTO 0); RESET : in STD_LOGIC; LOAD : in STD_LOGIC; Q : out STD_LOGIC_VECTOR(3 DOWNTO 0) ); end component; -- Stimulus signals - signals mapped to the input and inout ports of tested entity signal CLK : STD_LOGIC; signal DATA : STD_LOGIC_VECTOR(3 DOWNTO 0); signal RESET : STD_LOGIC; signal LOAD : STD_LOGIC; -- Observed signals - signals mapped to the output ports of tested entity signal Q : STD_LOGIC_VECTOR(3 DOWNTO 0); -- User can put declaration here shared variable ENDSIM: boolean:=false; constant CLK_PERIOD:time:= 30 ns; constant RESET_LENGTH:time:= 50 ns; TB część 1
TESTBENCH przykład -- Unit Under Test port map UUT : counter port map (CLK => CLK, DATA => DATA, RESET => RESET, LOAD => LOAD, Q => Q ); -- User can put stimulus here CLK_GEN: process if ENDSIM=false then CLK <= '0'; wait for CLK_PERIOD/2; CLK <= '1'; wait for CLK_PERIOD/2; else wait; end if; end process; -- reset process RES: process RESET<='0'; wait for RESET_LENGTH; RESET<='1'; wait; end process; -- stimulus process STIM: process DATA<="0110"; LOAD<='0'; wait for 350 ns; LOAD<='1'; wait for 50 ns; LOAD<='0'; wait for 100 ns; ENDSIM:=true; wait; end process; TB część 2 end TB_ARCHITECTURE; TB część 3
TESTBENCH warianty WAIT junk : process CLK <= 0, 1 after 25 ns; -- not recomended wait for 50 ns; end process; --Process with explicit wait for time statement --This is a testbench process process RESET <= '0'; wait for 50 ns; RESET <= '1'; wait for 50 ns; RESET <= '0'; wait; end process; --Process with explicit wait until edge statement --This is a synthesizable (non-testbench) sequential process wait until CLK = 1; B <= A; end process; Szybciej symulowane są TB oparte jedynie o behawioralne instrukcje wait for --Process with explicit wait on or sensitivity list --statement process --Synthesizable (non-testbench) process style wait on WR; DATA <= BUS_DATA; end process; --Combination of wait on, until, and or statement --Synthesizable (non-testbench) process style wait on IN1 until CLK = 0 ;
TESTBENCH pole dla instrukcji behavioralnych Kod TB jest bardzo wdzięcznym miejscem na modelowanie systemu instrukcjami behawioralnymi Przykład akcja potwierdzenia When d_valid = 1 & ACK = 0 When d_valid = 1 & ACK = 1 When d_valid = 0 & ACK = 1 When d_valid = 0 & ACK = 0 Zalety podejścia behawioralnego: moŝliwość wykorzystania bogatego zbioru instrukcji HDL, (brak ograniczeń kodowania zgodnego z RTL jak np. uŝywamy artybutu sygnału event tyle razy ile chcemy, instrukcje wait for itp.) szybkość pisania kodu, krótszy czas symulacji.
TESTBENCH pole dla instrukcji behavioralnych comb: process (state, ACK) next_state <= state; case state is... when MAKE_REQ=> d_valid <= 1 ; if ACK = 1 then next_state <= RELEASE; end if; when RELEASE=> d_valid <= 0 ; if ACK = 0 then next_state <=...; end if;... endcase; end; SEQ: process (CLK) if CLK event and CLK = 1 then if RESET = 1 then state <=.; else state <=next_state; end process SEQ; process...... end process d_valid <= 1 ; wait until ACK = 1 ; d_valid <= 0 ; wait until ACK = 0 ; Łatwo, szybko i przyjemnie...
TESTBENCH zalecenia --Generacja podzielonego zegara --głównego divider: process Begin clk50 <= 0 ; clk100 <= 0 ; clk200 <= 0 ; loop -- forever for j in 1 to 2 loop for k in 1 to 2 loop wait on clk; clk200 <= not clk200; end loop; clk100 <= not clk100; end loop; clk50 <= not clk50; end loop; end process divider; W przypadku stosowania osobnych domen czasowych +> osobne procesy generujące CLK Clock_A : process CLK_A <= 0 ; wait for 200 ns; CLK <= 1 ; wait for 200 ns; end process; Clock_B : process CLK_B <= 0 ; wait for 33 ns; CLK_B <= 1 ; wait for 33 ns; end process;
decode: process procedure do_instr(instr:t, data:d) is... end do_instr; TESTBENCH zalecenia case I1 is when "0000" => do_instr(stop, data); when "0001" => do_instr(jmp, data); when "0010" => do_instr(call, data);... end case; Redukcja wielokrotnych wywołań decode: process procedure do_instr(instr:t, data:d) is... end do_instr; case I1 is when "0000" => instr := STOP; when "0001" => instr := JMP; when "0010" => instr := CALL;... end case; do_instr(instr, data);...
TESTBENCH sterowanie sygnałów R/W Library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.STD_LOGIC_UNSIGNED.all; entity bidir_infer is port ( DATA : inout STD_LOGIC_VECTOR(1 downto 0); READ_WRITE : in STD_LOGIC); end bidir_infer ; architecture XILINX of bidir_infer is signal LATCH_OUT : STD_LOGIC_VECTOR(1 downto 0); process(read_write, DATA) if (READ_WRITE = 1 ) then LATCH_OUT <= DATA; end if; end process; Sygnały dwukierunkowe MUSZĄ być wysterowane w stan Z w stanie odczytu od strony TB process(read_write, LATCH_OUT) if (READ_WRITE = 0 ) then DATA(0) <= LATCH_OUT(0) and LATCH_OUT(1); DATA(1) <= LATCH_OUT(0) or LATCH_OUT(1); else DATA(0) <= Z ; DATA(1) <= Z ; end if; end process; end XILINX;
TESTBENCH podejście strukturalne BFMs to control & monitor I/O transactions Externally generated data and expected results Concurrent, coordinated system process modeling Internal transaction and bus monitors
AHDL wsparcie dla TB Szablony TB - generacja zegara, - wymuszenia wartości sygnałów: - Concurrent mode, - Sequenced mode, - porównanie wyników, - zapisywanie wyników, - funkcje randomizacji, Standard Waveform and Vector Exchang WAVES (IEEE-STD-1029.1) Code Coverage Linting
AHDL Code Coverage Code Coverage provides the following benefits to the designer: The users can easily find sections of a model that have not been exercised by a testbench. It allows a modification of the testbench to cover all untested parts of the design. Code Coverage helps to identify sections of the model executed very frequently. This allows the user to optimize the execution of the model during the simulation. Code Coverage is integrated into the Active-HDL simulation kernel. Code Coverage can measure the effectiveness of testbenches so the most effective test can be run first. This helps to uncover bugs in the design verification process immediately during long regression tests.
Standard Waveform & Vector Exchange WAVES Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service Testbench Development (cont.) WAVES Testbench Diagram Testbench VHDL Model Instantiation Actual Response Input Stimulus Expected Response Monitor Processes WAVES Waveform Generator WAVES Test Vector Set Error Messages Copyright 1995-1999 SCRA 12 http://www.eda.org/rassp/modules/m61/m61_03_00.ppt
Aplikacje HDL <=> FPGA glue logic Chyba najbardziej popularne zastosowanie układów programowalnych projektowanych przy wsparciu HDL inteligentne wsparcie dla up
Aplikacje HDL <=> FPGA DSP
Aplikacje HDL <=> FPGA DSP
Koniec wykładu - wpis zaliczeń
Ciąg dalszy nastąpi...