CMP238 Projeto e Teste de Sistemas VLSI Verificationfglima/projeto/projeto11.pdf · CMP238 –...

CMP238 – Projeto e Teste de Sistemas VLSI 2006/1

Verification

Aula 11 – Projeto

Prof. Fernanda Lima Kastensmidt

http://www.stefanvhdl.com

CMP238Projeto e Teste de Sistemas VLSI


Verification x Validation• "verification means pre-silicon testing (Verilog/VHDL

simulations) while validation is post-silicon testing (testing silicon on boards in the lab)."


Why verification?• Verification is an important part of any digital system

design cycle. • It's important that complex designs are simulated fully

before prototypes are built, as it's difficult to find bugs in silicon and going through additional layout cycles is costly and time consuming.

• VHDL is well suited for verification.

…. So, we start with using VHDL for verification and the concepts of testbench….


Basic stimulus generation and verification

• First basic stimulus generation is demonstrated. • A simple XOR build from AND and OR gates is used as

an example. • An extra term is added to deliberately introduce an error.

Correto:y <= (x1 and not x2) or (x2 and not x1)Errado:y <= (x1 and not x2) or (x2 and not x1) or (x1 and x2);


Exemplotest_seq: processbeginx1 <= '0'; x2 <= '0'; wait for 10 ns;x1 <= '1'; x2 <= '0'; wait for 10 ns; x1 <= '0'; x2 <= '1'; wait for 10 ns; x1 <= '1'; x2 <= '1';wait for 10 ns; x1 <= 'X'; x2 <= 'X'; ... end process test_seq;

X1 X2 XOR Y0 0 0 00 1 1 11 0 1 11 1 0 1


y <= (x1 and not x2) or (x2 and not x1) or (x1 and x2);

• This code can now be simulated and it's possible to identify thedesign error by observing the waveforms:


Assert Statements• However it's more efficient to build in checks which

automatically verify the result of a simulation. • This can be accomplished with the use of assert

statements. • An assert statement verifies that a certain condition

holds true.• If the condition is violated it will generate the associated

message and will attach the specified severity level to it.


Standard format• A standard format for error messages will also help to

identify the location of a bug. • The standard adopted here uses the first letter to

indicate the severity (I=Information, W=Warning, E=Error, F=Failure) followed by "@" and the entity name of the unit which generated the message.

• The "E@" notation makes it very easy to grep long logfiles and identify problems.

• Knowing the entity which detected a bug will aid fixing it, too.


Exemplo.... wait for 10 ns; x1 <= '1';x2 <= '1'; assert y = (x1 xor x2)

report "E@TB: circuit failed" severity Error;

wait for 10 ns; ...

A simulator executing the code will produce output similar to this:

# ** Error: E@TB: circuit failed # Time: 40 ns Iteration: 0 Instance: /tb1


Assert Package• Ideally the assert statement should provide information

about the condition in which the error occurred. • This will aid debugging substantially. • Below are two alternatives to the previous assert

statements. • One uses the 'image attribute from the VHDL 93

standard. • The other uses the conversion function str() from

package txt_util.vhd which is used extensively throughout this course.

• The package provides a somewhat less cumbersome way to handle string processing and similar tasks.

• Design under test (DUT): file tb1.vhd• Package: file txt_util.vhd


assert y = (x1 xor x2) report "E@TB: failure at: x1="& std_logic'image(x1)& "

x2="& std_logic'image(x2) severity Error;

assert y = (x1 xor x2) report "E@TB: failure at: x1="& str(x1)& " x2="& str(x2) severity Error;

• Shown below is the output of the two assert statements. It's now much easier to identify the cause of the problem.

# ** Error: E@TB: failure at: x1='1' x2='1' # Time: 40 ns Iteration: 0 Instance: /tb1 # ** Error: E@TB: failure at: x1=1 x2=1 # Time: 40 ns Iteration: 0 Instance: /tb1


Testbench Structure• The design and the test code must be located in

separately file. • Typical testbench code - such as text output and assert

statements - can not be synthesized and will at the very least create a number of unnecessary warnings from the tool.

• Also testbench code can have similar complexity as design code and if it's well structured, is quite likely to be reusable.

• The following diagram shows a typical testbenchstructure:


In this example the top level entity (testbench) instantiates four components: the processor transactor, the RAM model, the I2C-Controller transactor and the design which needs to be tested (DUT). Each testbench component and the top level testbench are in their own files, the DUT is also in a separate file. The testbench components produce stimulus and verify the response from the DUT.


Definition of Terms

• The following terms are used frequently in literature. Despite of the statement in the heading, there are no hard definitions, but thefollowing should reflect common usage:

• ModelA model is a description of the device which behaves just like the device does. Generally the behaviour can not be controlled by any other way then applying stimulus to it's input pins. RAMs are usually described in this way.

• TransactorTransactors have additional control mechanisms: they can read control data from a file or contain test specific code. They control which test is run in the testbench in which they are instantiated.

• Bus Functional Model (BFM)A BFM is a model of a device as it appears on a bus. E.g. a processor model coded in this fashion would only contain read and write processes, and none of the internal processing (no ALU, registers etc).


Writing to Files• Writing to files can be useful in a VHDL simulation. • Here is the header of an example program: library ieee; use ieee.std_logic_1164.all; use std.textio.all; use work.txt_util.all; entity FILE_LOG isgeneric ( log_file: string := "res.log" ); port( CLK : in std_logic; RST : in std_logic; x1 : in std_logic; x2 : in std_logic_vector(7 downto 0) ); end FILE_LOG;


• For the purpose of this example two signals x1 and x2 shall be logged to a file on every rising clock edge.

• To operate on files they need to be declared: architecture log_to_file of FILE_LOG isfile l_file: TEXT open write_mode is log_file; begin• Here l_file is the file, it's of type TEXT and opened in write mode.

The log_file parameter is of type string and usually assigned with a generic as shown above.

• The following loop will log x1 and x2 into the file specified bylog_file:

while true loopwrite(l, str(x1)&" "& hstr(x2)& "h"); writeline(l_file, l); end loop; As can be seen VHDL writes to a file in two steps: first a string is

written to a variable of type line (that's what the write command does), then the line is appended to a file with the writeline command.


• In the example shown here,• x1 is of type std_logic• x2 of type std_logic_vector. • The function str() will convert x1 in a string, the function

hstr() will convert x2 in a string in hex format. (Both functions are in txt_util.vhd).

• Strings and characters can be combined into a larger string with the & operator.

• The txt_util package provides a simpler way to write to a file, e.g. with:

print(l_file, str(x1)& " "& hstr(x2)& "h");


• Which fits into a single line and doesn't require a line type variable. Also since the input to print is always a string no type casting is necessary.

• The usage can be illustrated by inserting the lines below in front of the while-loop. (The code will generate a header for the log file.)

print(l_file, "# x1 x2 "); print(l_file, "#----------"); print(l_file, " "); wait until RST='1'; wait until RST='0'; while true loop . . .


Then the following will be the contents of res.log:# x1 x2 #----------0 01h 0 02h 0 03h ... 0 0Fh 1 10h 1 11h ...

If the waveforms shown below are applied to the entity:


Files:

txt_util.vhdfile_log.vhdstim_gen2.vhdtb_file_log.vhd


Reading from Files• Reading from files is very important for VHDL simulation.• Apart from using it in self-designed testbenches, many

commercially available testbench components make use of this method, too.

• Here is an example entity header:

entity FILE_READ isgeneric( stim_file: string :="sim.dat" ); port( CLK : in std_logic; RST : in std_logic; Y : out std_logic_vector(4 downto 0); EOG : out std_logic ); end FILE_READ;


• In this example data is read from a file sim.dat at every rising clock edge and applied to the output vector Y.

• Once every line of the file is read the EOG (End Of Generation) flag is set.

• The declaration of the input file is shown below:

architecture read_from_file of FILE_READ isfile stimulus: TEXT open read_mode is stim_file; begin


• The file is stimulus, it's of type TEXT and opened in read mode. The file name is defined in the string stim_file. (stim_file is a generic, defined in the entity header).

• Just as a file write, a file read is done in two steps. The first step fetches a line from a file and stores it in a line type variable (readline command) the second reads a string from the line (read command):

EOG <= '0'; -- wait for Reset to completewait until RST='1'; wait until RST='0'; while not endfile(stimulus) loop-- read digital data from input file readline(stimulus, l); read(l, s); Y <= to_std_logic_vector(s); wait until CLK = '1'; end loop; print("I@FILE_READ: reached end of "& stim_file); EOG <= '1';wait;


• Since a string is read from the input file, a conversion function is required to obtain a std_logic_vector.

• The function to_std_logic_vector(s) achieves that, it is part of the txt_util package.

• With the following contents of sim.dat: 00010 00011 11100 1UXZW HL111 11111 ...file_read.vhd will generate these waveforms:


Files

• txt_util.vhd• file_read.vhd• sim.dat• tb_file_read.vhd


• In addition to reading data, it's also possible to read commands from files.

• This will be discussed by extending the already introduced file_read.vhd.

• The new version will read hex data and will also understand a command: #count.

• Each time it is found in the input file the file reader shall shall count from 1 to 5 in binary format and present that count on the output port.

• Unfortunately the file I/O of VHDL is not very sophisticated.

• It's not allowed to read a string from a file where the string is longer than the number of characters in that line.


• Here is what needs to be done in order to read variable length strings from an input file:

readline(stimulus, l); s := (others => ' ');for i in s'range loopread(l, c, in_string); s(i) := c; if not in_string then -- found end of line exit; end if; end loop; • The read function will return false for in_string once the last

character of the line has been read. The above function has beenplaced in txt_util.vhd and named str_read(stimulus, s).

• The length of s determines the maximum number of characters in aline which can be evaluated.


• Using this function the following code will implement the set task: while not endfile(stimulus) loopstr_read(stimulus, s); if s(1 to 6) = "#count" then -- check for command "count"

for i in 1 to 5 loopY <= conv_std_logic_vector(i,5); wait until CLK = '1'; end loop;

else-- if it's not a command -> process data normally Y <= to_std_logic_vector(s to 5); wait until CLK = '1';

end if; end loop; print("I@FILE_READ: reached end of "& stim_file); EOG <= '1'; wait;


Note that the appropriate sub-section of the string s needs to be compared with #count as comparing different length strings will always yield the result false. Here is an input file making use of the #count-command. 00010 00011 #count 11100 1UXZW HL111 11111

The resulting waveforms are thus:


Files

• txt_util.vhd• file_read2.vhd• sim2.dat• tb_file_read2.vhd


The World of Perl• it's possible to read more from files than just data. • Many commercially available testbenches support

sophisticated commands. • There are limits however: in most cases structural

elements like loops and procedures are missing. • It's theoretically possible to extend the file reader into a

proper parser and add these language elements, however VHDL is not really suited for these tasks and access to the source code may not always be possible.

• A way to get around these problems is to generate the input files with a different language such as perl.


• The perl script below will generate an input file which can be read by file_read.vhd.

print "00011\n"; print "11100\n"; for ($i=0;$i<10;$i++) {

print num2binary($i,5)."\n"; } print "1UXZW\n";print "11111\n";

File: tgen.pl


Resulting Stimulus File

000111110000000000010001000011 00100 00101 00110 00111 01000 01001 01010 1UXZW HL111 11111

•It's straightforward to extend this approach e.g. for 256 iterations if all values of a 8 bit word are to be covered. •Entering these values manually would be very cumbersome. •The script actually calls a procedure num2binary which can be found in the complete script. •More complex procedures like Pseudo Random Bit Sequences (PRBS) patterns or CRC generators could be used in a similar fashion.


SRAM Modeling • SRAM models are used quite frequently and many

devices have bus interfaces which are similar to SRAMs.

• It's therefore valuable to have a standard approach for modeling these interfaces.

• Below is the data for a simplified SRAM:

Parameter Description Min Max Unit tSU A,D valid to WE_L asserted 4 - ns tH WE_L deasserted to A,D invalid 3 - ns tW_WE WE_L asserted to WE_L deasserted 40 - ns


• For the purpose of this example reading from the SRAM is ignored, and only writes are implemented. It's easier to code transactors rather than models, so initially this approach is taken.

• Core of the implementation is test_prg, a process which contains the write procedure and the test program.

• The purpose of the write procedure is to verify the timing of a write access to the SRAM as well as to verify whether data and address are as expected.

procedure write ( wadd: std_logic_vector(7 downto 0);wdat: std_logic_vector(7 downto 0) )

is variable start_cycle: time;

• The parameters wadd and wdat specify address and data for the expected write access.


BeginD <= (others => 'Z'); wait until WE_L = '0';

• The data bus is assigned to 'Z' (=tristate) values. • This means the SRAM model will not drive the data bus

and therefore will not corrupt the data input. • The procedure will wait for the start of the write access

which is equivalent to waiting for WE_L to be asserted (active low).


start_cycle := now;-- check setup timesassert A'last_event >= tSU

report "E@SIMPLE_SRAM: Address setup time violated" severity Error;

assert D'last_event >= tSUreport "E@SIMPLE_SRAM: Data setup time violated" severity Error;

• The variable start_cycle will be assigned to the simulation time. • This means it will contain the time at which WE_L was first asserted

in the access cycle. (The contents of that variable will be used later.) • The attribute 'last_event is very useful for testbenches, it returns the

time which has expired since the last event of a signal. (Example: if WE_L was asserted at 35 ns, and the current simulation time is 73 ns, then WE_L'last_event will return 73 ns - 35 ns = 38 ns.)


• In this case the A'last_event returns the time A has been stable before WE_L was asserted.

• This is the actual setup time and should be greater or equal to tSU.

• If this is not the case, the assert statement will issue the message "E@SIMPLE_SRAM: Address setup time violated".

• The same mechanism is used to verify the setup time for the data lines.

-- report action for transaction logprint("I@SIMPLE_SRAM: "& hstr(D)& "h written to "&

hstr(A)& "h");


• In any case the access to the SRAM will be reported. • The hstr function is part of the txt_util.vhd package.• It returns the value of a std_logic_vector in hex format.

-- verify addressassert A = wadd

report "E@SIMPLE_SRAM: Address incorrect, expected "& str(wadd)& " received "& str(A) severity Error;


• Next the address is verified, if it's incorrect a message is issued which reports the expected and the actual value.

• This time it's in binary format, so that it's easier to identify which bit was corrupted.

-- verify datafor i in wdat'range loop

if wdat(i) /= '-' and wdat(i) /= D(i) thenprint("E@SIMPLE_SRAM: Write Data Invalid,

written data = "& str(D)& " expected data = "& str(wdat) ); exit; end if;

end loop;


• Somewhat more effort is put into verifying the data bus. • Bits which are marked with "-" (=don't care bits) in the

expected data are not compared with the actual data. • This can be useful especially when modeling devices

with a SRAM like interface when not all control bits at a particular address are actually relevant. (Example: wdat="00010--" and D="0001011" => not error would be indicated.)

• The loop will go through all bits of the expected data word, compare or skip it and issue an error message when a discrepancy is found.

• In that latter case the loop is exited, to avoid reporting the same error several times.


wait until WE_L = '1'; -- verify pulse width on WE_Lassert now - start_cycle >= tW_WE

report "E@SIMPLE_SRAM: WE_L pulse width violated" severity Error;

-- verify address and data haven't changed during the cycleassert A'last_event >= (now - start_cycle)

report "E@SIMPLE_SRAM: Address hold time violated" severity Error;

assert D'last_event >= (now - start_cycle)report "E@SIMPLE_SRAM: Data hold time violated" severity Error;


• The cycle completes when WE_L is deasserted. • Now it's possible to verify the pulse width by comparing

the current time with the time at the beginning of the cycle (= start_cycle).

• The 'last_event attribute can not be used for this purpose since that would now refer to the time expired since WE_L returned to '1' (= 0 ns).

• It's now also possible to verify that A hasn't changed during the cycle.

• If that was the case then A'last_event would be smaller than the time which has expired since the beginning of the cycle (= now - start_cycle).

• The same steps are taken to verify that D hasn't changed.


-- now make sure the hold times are maintainedadd_hold <= true, false after tH;dat_hold <= true, false after tH; add_val <= A; dat_val <= D; end write;


• The cycle is not totally complete yet, as the address and data hold times have not been verified.

• The code above activates two separate processes (the hold time monitors) to check the values of A and D.

-- hold time monitors add_monitor: processbeginwait until A'event; assert not add_hold or A = add_val

report "E@SIMPLE_SRAM: Address hold time violated" severity Error;

end process add_monitor;


• As long as add_hold is true (which it will be for a time tHafter WE_L was deasserted) the hold time memory will verify the value of A, each time an event on A occurs.

• The simulation diagram below shows how the signals add_hold and dat_hold are true (activating the hold time monitors) for 3 ns (the value of tH) and then return to false (deactivating the monitors).


Files

• txt_util.vhd• simple_sram.vhd• stim_gen.vhd• tb_simple.vhd


Passive SRAM Model• Modeling RAMs as models rather than as transactors

has advantages and disadvantages. • A transactor implementation doesn't need to represent

memory and can verify the correct address and data. • In case of a write it's possible to identify the problem at

the time the write access occurs, rather than the time at which reading back occurs.

• However a passive implementation does not need to know which test is executed and is in that respect more generic than the transactor version.

• One of the problems of implementing RAM models is representing internal memory. A large array of std_logic_vectors (eg. 2Mx64 bits) needs a large chunk of memory on the machine it's simulated on.


Passive SRAM Model• A possible approach is to represent the memory cells with integers

(of an appropriate range) rather than std_logic_vectors. • The approach taken here is based on the observation that most

tests only access a tiny fraction of the modeled memory. • For each write access the data as well as the address is stored into

the internal array. • For a subsequent access the model searches the array and

identifies whether the address is already present. • So if there are only 32 different addresses which are accessed, then

there is no reason to have more than that number of memory locations in the model.

• However searching the array is more time intensive than using the address as an index, therefore there is likely to be a cross over point, where searching requires more resources than having a large array.


Here is the VHDL for this memory representation: -- Internal Memorytype mem_add_type is array (integer range <>) of

std_logic_vector(A'range); type mem_dat_type is array (integer range <>) of

std_logic_vector(D'range); variable mem_add: mem_add_type(mem_words-1 downto

0); variable mem_dat: mem_dat_type(mem_words-1 downto

0); variable used_pnt: integer := 0; The parameter mem_words is a generic defined in the

header, it can be set during instantiation for the required number of memory locations.


• One of the additional tasks for the passive memory model, is to decide whether to call the read or the write procedure. The code below will take care of that:

D <= (others => 'Z'); wait until WE_L'event or RD_L'event; assert (WE_L /= 'X' and WE_L /= 'Z' and WE_L /= 'U' and WE_L /= '-')

or no_reset_yetreport "E@SRAM2: WE_L="& str(WE_L)& " invalid value" severity Error;

assert (RD_L /= 'X' and RD_L /= 'Z' and RD_L /= 'U' and WE_L /= '-') or no_reset_yetreport "E@SRAM2: RD_L="& str(RD_L)& " invalid value" severity Error;

assert to_X01(RD_L) /= '0' or to_X01(WE_L) /= '0' report "E@SRAM2: both read and write are asserted"& "RD_L="& str(RD_L)& " WE_L="& str(WE_L) severity Error;


-- decide whether read or write accessif to_X01(WE_L) = '0' thenwrite; end if; if to_X01(RD_L) = '0' thenread; end if; end process test_proc;


• The process will wait until activity either on RD_L or WE_L occurs.

• Illegal values for these signals ('U', 'X', '-' and 'Z') are reported as errors, they should never occur during simulation.

• Also if both signals are asserted simultaneously an error is reported.

• The function to_X01 will convert 'H' and 'L' values to '1'and '0' respectively.

• This is useful on busses which are pulled up or down and reflects the actual behaviour of the SRAM.


... wait until to_X01(WE_L) = '1'; -- Store written datafor i in 0 to used_pnt loop

if i = used_pnt then-- access to a new address mem_add(i) := A; mem_dat(i) := D; if used_pnt < mem_words - 1 then

used_pnt := used_pnt + 1;else

print("W@SRAM2: Simulation model can't handle additional addresses");

end if; end if; if mem_add(i) = A then

-- access to an existing addressmem_dat(i) := D; exit;

end if; end loop;


• The code loops through the already written array until a match for the address is found.

• If no match can be found and there is still room in the array, the new address is entered and the usage pointer is incremented.

• If there is no more space available a warning is issued.


The counterpart of this code can be found in the read procedure:

-- Retrieve data from internal memoryfor i in 0 to used_pnt+1 loop

If i = used_pnt+1 then-- access to a new addressprint("W@SRAM2: Address has not been written to yet"); print("I@SIMPLE_SRAM: "& hstr(xx)& " provided for "& hstr(A)& "h"); D <= (others => 'X'); exit; end if; if mem_add(i) = A then-- access to an existing addressD <= mem_dat(i) after tRD; print("I@SIMPLE_SRAM: "& hstr(mem_dat(i))& "h provided for "& hstr(A)& "h"); exit; end if;

end loop;


• The loop will investigate all written memory locations and try to establish a match.

• If successful it will take the data from that location and drive it onto the bus, otherwise it will issue a warning and drive all X's on the data bus.


Files

• txt_util.vhd• sram2.vhd• mp.vhd• tb_simple2.vhd


Signal Monitors

• Often it's desirable to monitor the status of a signal and display messages whenever it changes.

• A good example for this is an interrupt signal.• Here presented are two possibilities for implementing

this: -- report changes of the interrupt signalmonitor: process(INT_L) beginprint("I@TB: INT_L="& str(INT_L)); end process monitor; • The process will be executed each time there is an event

on INT_L. Whenever that happens a message will be printed.


• Here is an alternative using an extensions of the print command which is available in txt_util.vhd:

-- report when interrupt is assertedprint(INT_L'event and INT_L = '0', "I@TB: INT_L="&

str(INT_L)); • This function has as a first parameter a boolean

expression and as the second parameter a message text.

• The message text will be printed whenever the booleanexpression is true.

• (In this case whenever INT_L changes to '0'). • The function does not need to be part of a process, it

can be used as a concurrent statement.

File simple_mon.vhd


Generating Clock and Reset Stimulus• Practically every testbench needs a clock and a reset

signal. . . . signal clk: std_logic := '0'; signal rst: std_logic; beginrst <= '0', '1' after 10 ns,

'0' after 30 ns; clk <= not clk after 8 ns; . . . Note that the clk signal needs to be initialized in the

declaration, as the inverse of 'U' (=uninitialized) is also 'U'.


File tb_clk_rst.vhd


Approaches to Test Generation• A variety of methods are available to set up transactors

for specific tests, some of the more popular methods are introduced here.

File Read Method• This method is very common, especially in commercially

available testbenches. • The transactor reads commands from an input file and

executes them, creating stimulus and verifying responses for the testbench.

• For each simulation the input files for the simulated test need to be copied into the working directory.

• Usually this method is combined with a pre-processor which generates the input files, as described in the perl.


Some problems of this approach are: • Usually the input file format does not support sophisticated structural

elements (loops, procedures etc) and VHDL is not really suited to implement a sophisticated parser

• Syntactical errors in the input file are usually only found during simulation time (this may result in the loss of valuable computing time)

• Lack of feedback: it's usually not possible to react flexibly on the response of the DUT by examining the value of signals etc

• The input "language" is not standard VHDL and therefore not immediately understandable to other designers

Some of the benefits are: • The testbench VHDL can remain clean and should run on all

platforms without any changes • The testbench structure is straightforward, no configuration

statements are required


Approaches to Test GenerationVHDL pre-processing Method• In this approach the test specific code is written in VHDL.• It is stored in a file separate from the transactor code. • To set up the transactor for a specific test, a pre-

processor will insert that file into the transactor code and then the transactor is recompiled.

• The place where the file is inserted is marked with a special comment e.g. "--insert_file inp.cmd" where inp.cmd is the file name.


• In Unix the pre-processor would be run like this: • awk -f insert.awk < transactor.vhd >

precompiled_transactor.vhd• vcom precompiled_transactor.vhd• The file test_code.vhd is assumed to be in the current

directory. (The compilation command would be appropriate for the MTI simulator, it needs to be replaced by an equivalent command for other simulators.)

Some problems of this approach are: – Reliance on OS specific tools (not strictly pure VHDL) – Recompilation adds to simulation time


Some of the benefits are:• Tests can be compiled before simulation, so syntax

errors are detected before the simulation runs • Tests can be readily understood by designers who are

familiar with VHDL • All structural elements of VHDL are available • Tests can react flexibly on the response of the DUT, full

access to all signals known to the transactor is possible


Approaches to Test GenerationTest-specific Entities• For each test there is a separate testbench which uses

test-specific transactors.• For example there may be a microprocessor transactor

mp.vhd. • The testbench tb_test1 would then instantiate a test-

specific microprocessor transactor mp_test1.vhd which would be coded by enhancing the mp.vhd template.


Some problems of this approach are: • Bug fixes in the transactor code may have to be made in

many files • Results in a large number of files which are difficult to

handle Some of the benefits are: • Pure VHDL, no dependency on OS specific tools • Tests can be compiled before simulation, so syntax





Approaches to Test GenerationConfiguration controlled Test Selection • In this approach the transactors contain the code for all

tests. • The behaviour of the transactor can be controlled by a

generic. • The value of the generic defines which test is run. • For each test a configuration statement exists which

selects the test in the transactor by assigning the appropriate value to the generic parameter.

• For example: configuration tb_A selects test A in the transactor by assigning the value "test_a" to the generic testselector of the transactor.


Some problems of this approach are:• Transactor code becomes very large and difficult to

handle • Modifying the transactor code for one test could

potentially cause a problem in another test (e.g. accidental editing)

Some of the benefits are: • Pure VHDL, no dependency on OS specific tools • Tests can be compiled before simulation, so syntax





Using Transaction Logs • The purpose of this is to show how to use transaction logs and to

demonstrate why they are useful. • First the usefulness shall be demonstrated. • Below are the requirements for two output signals of a device:

Parameter Description Min Max Unit tSU_W Setup time for W asserted 6 - ns tSU_R Setup time for R asserted 5 - ns


• In this example a circuit has been synthesized already, and the simulation shall verify the VHDL description of the synthesized design.

• The following process shall check whether the timing requirements on the pins R and W are fulfilled.

• (The assumption of this test is that the design will execute write and read accesses alternatingly.)


timing_check: processvariable w_asserted: time; variable r_asserted: time; begin-- wait for DUT to be resetwait until RST = '1'; wait until RST = '0'; -- verify write accesswait until W = '0'; w_asserted := now; wait until W = '1'; assert (now - w_asserted) >= tSU_W

report "E@TB: W setup time too short" severity Error;

-- verify read accesswait until R = '0'; r_asserted := now; wait until R = '1';

assert (now - r_asserted) >= tSU_Rreport "E@TB: R setup time too short" severity Error;

end process timing_check;


• Here is the description of the circuit's timing behaviour: -- description of the timing behaviour -- of the DUT implemenationdut: process beginW <= '1'; R <= '1'; wait until RST = '1'; wait until RST = '0'; wait for 10 ns; -- write accessW <= '0', '1' after 8 ns; wait for 10 ns; -- read accessR <= '0', '1' after 9 ns; wait for 10 ns; -- write accessW <= '0', '1' after 7 ns; wait for 10 ns; -- read accessR <= '0', '1' after 4 ns; -- this is a violation we want to detectwait for 10 ns; -- write accessW <= '0', '1' after 8 ns; wait for 10 ns; wait; end process dut;


• As can be seen, the circuit does not meet the requirements. The second read pulse is too short. A simulation results in the following output, however:

VSIM 26> run -all VSIM 27>

• Closer examination of the timing_check process reveals that it contains an error causing it to verify only one write and one read access, as it won't progress after the read unless a second reset pulse occurs.

• However the simulation output is exactly as would be expected for a correctly functioning circuit.

• This kind of error is not infrequent and can be avoided by using transaction logs.


Using the same synthesized circuit the timing checker will be enhanced with transaction reporting:

-- verify the setup time on W and R signals-- we assume W and R are asserted

alternatinglytiming_check: processvariable w_asserted: time; variable r_asserted: time; begin -- wait for DUT to be resetwait until RST = '1'; wait until RST = '0'; -- verify write accesswait until W = '0'; w_asserted := now; wait until W = '1'; print("I@TB: detected W access"); assert (now - w_asserted) >= tSU_W

report "E@TB: W setup time too short" severity Error;

-- verify read accesswait until R = '0';r_asserted := now; wait until R = '1'; print("I@TB: detected R access");

assert (now -r_asserted) >= tSU_R

report "E@TB: R setup time too short"

severity Error; end process timing_check;


• Rerunning the simulation, the problem becomes immediately apparent:

• VSIM 31> run -all • # I@TB: detected W access • # I@TB: detected R access • VSIM 32>


• The transaction log contains an insufficient number of write and read cycles.

• The problem can be fixed in the timing checker as shown:

-- wait for DUT to be resetwait until RST = '1'; wait until RST = '0'; loop

-- verify write accesswait until W = '0'; ...

end loop;end process timing_check;


And now the problem in the circuit is detected: VSIM 8> run -all # I@TB: detected W access # I@TB: detected R access # I@TB: detected W access # I@TB: detected R access # ** Error: E@TB: R setup time too short # Time: 64 ns Iteration: 0 # I@TB: detected W access VSIM 9>


• In order to effectively work with transaction logs it's helpful to write them to files.

• Here is a way to do this with the MTI simulator:

vsim tb1 -c -do "run 400 ns ; exit -f" > sim.log

• These logs should be kept for each test, so that in a later simulation run the current log can be automatically compared with the golden log.


Using Behavioral Models • A behavioural model of a design can be used to verify

that design. • Such a model is used when there exists a way to

represent the design's behavior in a significantly simplified manner (e.g. if the objective is to build a very fast adder, the design's behavior could be modeled with a simple "+").

• Typically only the main functionality of the design would be modeled while other parts (like processor interface and RAM interfaces) would be ignored.

• Also in many cases there is no need to model the exact timing relationship as occurs in the design.


Using Behavioral Models• In principle the behavioral model will receive the same

stimulus as the design and produce the same output. • However often the stimulus and response can be

represented in a more abstract format. • For example if the actual design works on data blocks

which are received one byte at a time in four clock cycles, the behavioral model could just operate on a simple hex number.


• Often behavioral models are used to generate expected (golden) log files.

• In this case the behavioral model operates on a stimulus file and creates a result file.

• The design is stimulated with the same input file via a file reader (see Reading from Files) and will protocol it's response into a transaction log (see Using Transaction Logs).

• The transaction log can then be compared with the expected results from the behavioural model (e.g. with Unix' diff utility).


Recommended Directory Structure


Xilinx System Generator v7.1 User Guide

HDL Testbench• Ordinarily, System Generator designs are bit and cycle-

accurate, so Simulink simulation results exactly match those seen in hardware.

• There are, however, times when it is useful to compare Simulink simulation results against those obtained from an HDL simulator.

• In particular, this makes sense when the design contains black boxes. The Create Testbench checkbox in the System Generator block makes this possible.

•



• Suppose the design is named <design>, and a System Generator block is placed at the top of the design.

• Suppose also that in the block the Compilation field is set to HDL Netlist, and the Create Testbench checkbox is selected.

• When the Generate button is pushed, System Generator produces the usual files for the design, and in addition writes the following:



1. A file named <design>_clk_wrapper_testbench.vhd/.v that contains a testbench HDL entity;

2. Various .dat files that contain test vectors for use in an HDL testbench simulation.

3. Scripts vcom.do and vsim.do that can be used in ModelSim to compile and simulate the testbench, comparing Simulink test vectors against those produced in HDL.

• System Generator generates the .dat files by saving the values that pass through gateways.

• In the HDL simulation, input values from the .dat files are stimuli, and output values are expected results.

• The testbench is simply a wrapper that feeds the stimuli to the HDL for the design, then compares HDL results against expected ones.


Challenges• The amount of time spent on verification now exceeds

the amount of time spent on design, comprising up to 70 percent of the total development effort, and the cost of failure continues to increase.

• The key problem: current verification methods cannot deliver the verification effectiveness and efficiencies designers need to keep pace with growing chip complexity, especially for 90 nanometer design and below.


Challenges (cont.)• Today's economy demands that you hit a narrow market

window with the "right product that is designed right." • In other words, the product has to do what the

marketplace needs and wants, and it has to do it correctly.

• This leaves no time to respin the product if you get it wrong.


• Recent papers believe that the key to more effective and efficient verification methodologies is the inclusion of assertions, which establish a more dynamic approach to simulation-based verification.

• The simulation engine must support assertion-based verification (ABV), testbench automation, and coverage-driven verification, since pure testbench driven simulation alone will not detect bugs efficiently and effectively enough to close the verification gap.


• Assertions are formally captured statements about the functional intent or implementation correctness of a design.

• ABV complements traditional simulation by providing a number of benefits: increased design confidence, enhanced observability, and improved debug productivity.

• Assertions not only verify which aspects of the design have been activated, but also determine the correct operation associated with these activations.


• ABV is critical because this methodology allows the designer to discover and diagnose deeply buried design flaws, which impact the ability to deliver products in competitive time-to-market windows.

• The use of assertions enables new verification capabilities, such as static and dynamic formal analysis, structural coverage metrics that truly identify that design functionality has been verified, and coverage-driven verification — all in a single environment.


• To enhance ABV methodologies, the designer needs to adopt a simulation-centric verification environment that supports standards, including SystemC, SystemVerilog, and PSL.

• Standards support is also critical for sustainable design reuse methodologies that allow you to protect your investments in designs, tools, and verification flows.

• The ideal simulation technology supports large capacity verification for system-level design and manages the complexities of integrated digital, analog-mixed signal, software, and hardware-assisted verification.


Verification x Validation• "verification means pre-silicon testing (Verilog/VHDL

simulations) while validation is post-silicon testing (testing silicon on boards in the lab)."


Verification Methodology


Vera Language• Vera® is an industry-leading testbench automation product that

increases design quality by finding simple as well as corner-case bugs, quickly.

• Vera allows engineers to create coverage-driven tests using advanced testbench concepts like constrained-random stimulus generation, real-time data and temporal checking and extensive analysis of functional coverage.

• Vera combines next-generation constraint solving and coverage analysis engines with proven interfaces to leading Verilog and VHDL simulators.

• Vera supports the OpenVera™ hardware verification language, including OpenVera Assertions, and offers a roadmap to the SystemVerilog hardware design and verification language.

• Vera is an integral part of the Synopsys Discovery™ Verification Platform.

CMP238 Projeto e Teste de Sistemas VLSI Verificationfglima/projeto/projeto11.pdf · CMP238 –...

Documents

Transcript of CMP238 Projeto e Teste de Sistemas VLSI Verificationfglima/projeto/projeto11.pdf · CMP238 –...