process!

Transkrypt

process!

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 [email protected]
dr inŜ. Paweł J.Rajda [email protected]
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;
begin
TMP:= A and B;
D <= TMP or C;
end process;
A
B
TMP
D
C
Implementacja TMP : przewód
signal A,B,C: bit
...
IS_IT_LATCH: process (A,B,C)
variable TMP: bit;
begin
C <= TMP and B;
TMP := A or C;
Implementacja TMP : zatrzask ?!
end process;
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
-- 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 int3 is int2 range 0 to 7 -- a binary encoding having 3bits.
type int0 is range 0 to 100
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
begin
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;
Two wires;
the encodings of
00 and 11 are "don't cares.”
User Defined Encoding
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
'X',
‘0',
'1',
'Z',
'W',
'L',
'H',
'-'
);
-- Uninitialized
Forcing Unknown
Forcing 0
Forcing 1
High Impedance
Weak
Unknown
Weak
0
Weak
1
Don't care
('U',
---------
attribute enum_encoding of std_ulogic : type is
"M M 0 1 Z M 0 1 -";
'0' 'L'
'1' 'H'
'Z'
'U' 'X' 'W'
'-'
------
Logic value 0
Logic value 1
Logic value tristate
Metalogic value
Don’t care value
Synteza instrukcji przypisań - operatory logiczne
entity logical_ops_1 is
port (a, b, c, d: in bit;
end logical_ops_1;
m: out bit);
architecture example of logical_ops_1 is
signal e: bit;
begin
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
begin
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
begin
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
begin
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
begin
m <= a + b;
end example;
Synteza instrukcji wyboru
VHDL wyraŜenia współbieŜne (concurrent)
conditional signal assignment
selected signal assignment
( when.. )
(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
begin
m <= b when a else c;
end example;
port (sel: bit_vector (0 to 1); a,b,c,d : bit;
bit);
end control_stmts;
begin
with sel select
m <= c when b"00",
m <= d when b"01",
m <= a when b"10",
m <= b when others;
end example;
m: out
Synteza sekwencyjnych instrukcji wyboru
port (a, b, c: in boolean;
end control_stmts;
m: out boolean);
begin
process (a, b, c)
variable n: boolean;
begin
if a then
n := b;
else
n := c;
end if;
m <= n;
end process;
end example;
port (sel: bit_vector (0 to 1);
m: out bit);
end control_stmts;
a,b,c,d : bit;
begin
process (sel,a,b,c,d)
begin
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);
end loop_stmt;
architecture example of loop_stmt is
begin
process (a)
variable b:bit;
begin
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;
entity subprograms is
port (a: bit_vector (0 to 2);
end subprograms;
architecture example of subprograms is
function simple (w, x, y: bit) return bit is
begin
return (w and x) or y;
end;
begin
process (a)
begin
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 sekwencyjnych
Specyfikacja warunkowa
if clk then
y <= a;
else
-- do nothing
end if;
sygnał y latch
if clk then
y <= a;
else
y <= b;
end if;
sygnał y- mux
if clk
and
clk'event
then
y <= a;
end if;
sygnał yD Flip Flop
Instrukcje implikujące syntezę do FF typu latch
process (clk,a,b) -- a list of all signals used in the process
begin
if clk then
y <= a and b;
end if;
end process;
procedure my_latch (signal clk, a, b: in boolean;
signal y: out boolean)
begin
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
begin
--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
begin
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);
begin
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)
begin
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
begin
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)
begin
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)
begin
if set then
q <= true;
elsif clk and clk'event then
-- clock rising
q <= a;
end if;
end;
Styl kodowania
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
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 sim OF 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
A
A
B
A+B+C
A+B+C
A+B+C
A+B+C
C
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
Transformacja
Model źródłowy
Specyfikacja
Interpretacja B
Model docelowy
Model źródłowy
Weryfikacja
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?”
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
Model po syntezie
2. Sprawdzanie modelu
• Sprawdzenie zachowania się
modelu w sytuacjach błędnych
• Problem: jak te
sytuacje znaleźć? Specyfikacja
(automaty stanu,
inne zachowanie
się magistral itp.)
Kodowanie RTL
Model RTL
„Problemy”
Interpretacja
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);
begin
LINT_5009 Reset signal '%s' is active
if (rising_edge(clk)) then
high and low
if (rw = '1') then
Sample Code:
ram(address) := data;
architecture tb of tb is
end if;
signal a, b : std_logic;
data <= ram(address);
begin
end if;
process (reset)
end process;
begin
LINT_3001
if (reset = '1') then
Incomplete sensitivity list
Sample Code:
a <= '0';
process (clk)
end if;
begin
end process;
process (reset)
sig <= '0';
begin
elsif (rising_edge(clk)) then
sig <= not clk;
b <= '0';
end if;
end if;
end process;
end process;
end architecture tb;
Weryfikacja a testowanie
Kodowanie
Wytwarzanie
Model
Specyfikacja
Weryfikacja
Pomyłki
Błędy
Zły Projekt
Dobry Projekt
Krzem
Testowanie
Brak
błędów
Typ II
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++
Za:
Verilog
VHDL
http://home.comcast.net/~cnibb/
Chet Nibby's
Functional Verification Page
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
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
TestBench
Component
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)
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
begin
-- 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
begin
if ENDSIM=false then
CLK <= '0';
wait for CLK_PERIOD/2;
CLK <= '1';
wait for CLK_PERIOD/2;
else
wait;
end if;
end process;
TB część 2
-- reset process
RES: process
begin RESET<='0';
wait for RESET_LENGTH;
RESET<='1';
wait;
end process;
-- stimulus process
STIM: process
begin
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;
end TB_ARCHITECTURE;
TB część 3
TESTBENCH – warianty WAIT
junk : process
begin
CLK <= ’0’, ’1’ after 25 ns; -- not recomended
wait for 50 ns;
end process;
Szybciej symulowane są
TB oparte jedynie o
behawioralne instrukcje
wait for
--Process with explicit “wait for time” statement
--This is a testbench process
process
--Process with explicit “wait on or sensitivity list”
begin
--statement process
RESET <= '0';
--Synthesizable (non-testbench) process style
wait for 50 ns;
begin
RESET <= '1';
wait on WR;
wait for 50 ns;
DATA <= BUS_DATA;
RESET <= '0';
end process;
wait;
end process;
--Process with explicit “wait until edge” statement
--This is a synthesizable (non-testbench) sequential
process
--Combination of “wait on, until, and or” statement
begin
--Synthesizable (non-testbench) process style
wait until CLK = 1;
wait on IN1 until CLK = ’0’;
B <= A;
end process;
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
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)
begin
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)
begin
if CLK’event and CLK = ‘1’ then
if RESET = ‘1’ then
state <= ….;
else
state <=next_state;
……
end process SEQ;
process
begin
...
d_valid <= ‘1’;
wait until ACK = ‘1’;
d_valid <= ‘0’;
wait until ACK = ‘0’;
...
end process
Ł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
begin
CLK_A <= ’0’;
wait for 200 ns;
CLK <= ’1’;
wait for 200 ns;
end process;
Clock_B : process
begin
CLK_B <= ’0’;
wait for 33 ns;
CLK_B <= ’1’;
wait for 33 ns;
end process;
TESTBENCH – zalecenia
decode: process
procedure do_instr(instr:t, data:d) is
begin
....
end do_instr;
begin
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
begin
....
end do_instr;
begin
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);
begin
process(READ_WRITE, DATA)
begin
if (READ_WRITE = ’1’) then
LATCH_OUT <= DATA;
end if;
end process;
process(READ_WRITE, LATCH_OUT)
begin
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;
Sygnały dwukierunkowe
MUSZĄ być wysterowane
w stan ‘Z’ w stanie odczytu
od „strony” TB
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
Testbench
Development (cont.)
Electronic
Design
Architecture
DARPA
Infrastructure
Tri-Service
WAVES Testbench Diagram
Testbench
Input Stimulus
WAVES
Waveform
Generator
VHDL
Model
Instantiation
Expected
Response
Monitor
Processes
Actual Response
Copyright  1995-1999 SCRA
WAVES
Test Vector Set
Error
Messages
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...

process!

Transkrypt

Podobne dokumenty

Zadania powtórzeniowe do ćwiczenia przed kolokwium (niezbyt łatwe)

sprężarka klimatyzacji mercedes clk c209 nowa - Klim-faf

Semafory i monitory