ΗΜΥ 664 ΨΗΦΙΑΚΟΣ ΣΧΕΔΙΑΣΜΟΣ ΜΕ FPGAs …largely synchronous Synchronous...

ΗΜΥ 664ΨΗΦΙΑΚΟΣ ΣΧΕΔΙΑΣΜΟΣ ΜΕ FPGAsΧειμερινό Εξάμηνο 2010

ΔΙΑΛΕΞΗ 4:Simulation and Verification of your Design

ΧΑΡΗΣ ΘΕΟΧΑΡΙΔΗΣ([email protected])

Presenter

Presentation Notes

Other handouts To handout next time

ΗΜΥ664 Δ4 Simulation/Verification.2 © Θεοχαρίδης, ΗΜΥ, 2010

“Beware of bugs in the above code; I have only proved it correct, not tried it.”

- Donald Knuth

Author of “The Art of Computer Programming”, Professor Emeritus, Stanford University, on his delivery of the LaTex Compiler…


Unfortunate Realities I can’t prove UFOs don’t exist

Testbench can’t prove that your design is correct Give me a UFO, however,

and I’ll prove that UFOs do exist


Today… Verifying your design…

Why testing is important

Basics of test benching

Writing Test benches for simulation

Lab time It’s one of those things where the only way to learn is through

the labs…


RTL Design

Verilog or VHDL input Multi-level Simulation Languages

Not synthesis specifications Subsets are Synthesizable

Testbenches Do not need to be synthesizable

Verilog

SynthesizableVerilog


Depiction of Design Verification Environment


Verification Taxonomy

Principle of Reconvergence

Design Rep 1 Design Rep 2

Transformation /Refinement

Verification


Sometimes this isn’t quite so clear

RTL Coding

Verification

Concept

Rules


Functional Verification

Not Equivalent Checking: only one RTL

Can do some forms of model checking, but not formally

Not “formal” but “empirical” Did something bad happen when I ran the simulation?

Ad-hoc, but discipline is improving

Spec RTL


Conventional Design FlowFunct. Spec

Logic Synth.

Gate-level Net.

RTL

Layout

Floorplanning

Place & Route

Front-end

Back-end

Behav. Simul.

Gate-Lev. Sim.

Stat. Wire Model

Parasitic Extrac.


Verification at different levels of abstraction

Goal: Ensure the design meets its functional and timing requirements at each of these levels of abstraction

In general this process consists of the followingconceptual steps:

1. Creating the design at a higher level of abstraction2. Verifying the design at that level of abstraction3. Translating the design to a lower level of abstraction4. Verifying the consistency between steps 1 and 35. Steps 2, 3, and 4 are repeated until tapeout


Verification at different levels of abstraction

BehavioralHDL

System Simulators

HDL Simulators

Code Coverage

Gate-level Simulators

Static Timing Analysis

Layout vs Schematic (LVS)

RTL

Gate-level

PhysicalDomain Ve

rific

atio

n


Classification of Simulators

Logic Simulators

Emulator-based Schematic-basedHDL-based

Event-driven Cycle-based Gate System


Classification of Simulators HDL-based: Design and testbench described using HDL

Event-driven Cycle-based

Schematic-based: Design is entered graphically using a schematic editor

Emulators: Design is mapped into FPGA hardware for prototype simulation. Used to perform hardware/software co-simulation.


Event-driven Simulation Event: change in logic value at a node, at a certain instant of

time → (V,T)

Event-driven: only considers active nodes Efficient

Performs both timing and functional verification All nodes are visible Glitches are detected

Most heavily used and well-suited for all types of designs


Event-driven Simulation

Event: change in logic value, at a certain instant of time → (V,T)

10

1

0

1

0

1

D=2a

b

cEvents:•Input: b(1)=1•Output: none

10

1

0

1

0

1

D=2a

b

cEvents:•Input: b(1)=1•Output: c(3)=03



Uses a timewheel to manage the relationship between components

Timewheel = list of all events not processed yet, sorted in time (complete ordering)

When event is generated, it is put in the appropriate point in the timewheel to ensure causality



b(1)=1d(5)=1

D=1

10

1

0

1

D=2a

b

c

d(5)=1

d5

0

1

e

0

1

3

c(3)=0d(5)=1

0

1

4

d(5)=1

e(4)=0

6

e(6)=1


Cycle-based Simulation

Take advantage of the fact that most digital designs are largely synchronous

Synchronous circuit: state elements change value on active edge of clock

Only boundary nodes are evaluated

Internal Node

Boundary NodeLatches

Latches


Cycle-based Simulation

Compute steady-state response of the circuit at each clock cycle at each boundary node

Latches

Latches

Internal Node


Cycle-based versus Event-driven

Cycle-based: Only boundary nodes No delay information

Event-driven: Each internal node Need scheduling and

functions may be evaluated multiple times

Cycle-based is 10x-100x faster than event-driven (and less memory usage)

Cycle-based does not detect glitches and setup/hold time violations, while event-driven does


Simulation: Performance vs Abstraction

.001x

SPICE

Event-drivenSimulator

Cycle-basedSimulator

1x 10xPerformance and Capacity

Abs

tract

ion


Simulation Testplan

Simulation Write test vectors Run simulation Inspect results

Test vectors HDL code coverage


Verification - Simulation

Consistency: same testbench at each level of abstraction

Behavioral

Gate-level Design(Post-layout)

Gate-level Design(Pre-layout)

RTL Design

Testbench Simulation


Formal Verification Can be used to verify a design against a reference design as it

progresses through the different levels of abstraction

Verifies functionality without test vectors

Three main categories: Model Checking: compare a design to an existing set of logical

properties (that are a direct representation of the specifications of the design). Properties have to be specified by the user (far from a “push-button” methodology)

Theorem Proving: requires that the design is represented using a “formal” specification language. Present-day HDL are not suitable for this purpose.

Equivalence Checking: it is the most widely used. It performs an exhaustive check on the two designs to ensure they behave identically under all possible conditions.



Suitable for synchronous design

Verify timing without test vectors

Conservative with respect to dynamic timing analysis

Latches LatchesCombinationalLogic


Static Timing Analysis Inputs:

Netlist, library models of the cells and constraints (clock period, skew, setup and hold time…)

Outputs: Delay through the combinational logic

Basic concepts: Look for the longest topological path Discard it if it is false


Conventional Simulation Methodology Limitations

Increase in size of design significantly impact the verification methodology in general Simulation requires a very large number of test

vectors for reasonable coverage of functionality Test vector generation is a significant effort Simulation run-time starts becoming a bottleneck

New techniques: Static Timing Analysis Cycle-based simulation Formal Verification


New Verification Paradigm Functional: cycle-based simulation and/or formal verification

Timing: Static Timing Analysis

Gate-level netlist

RTL

TestbenchLogic Synthesis

Cycle-based Sim.

Event-driven Sim.


Formal Verification


Summary

Conventional design and verification flow review

Verification Techniques Simulation

Behavioral, RTL, Gate-level, Switch-level, Transistor-level Formal Verification Static Timing Analysis

Emerging verification paradigm Functional: cycle-based, formal verification Timing: Static Timing Analysis


Test Bench

Entity declarations of test bench modules have no input and output ports.

Test bench is a module that is used for testing thefunctionality of a design module.

d3d2d1d0

q0q1

q2

q3enclk

REG_4

TestBench


Test Bench Testing a design by simulation

Using a test bench model an architecture body that includes an instance

of the design under test applies sequences of test values to inputs monitors values on output signals

either using simulatoror with a process that verifies correct

operation


Why testbench? Suppose you want to predict the behavior of

something that meets the design’s spec What kind of signal diagram could we expect? What latencies? What throughput?

You are an excellent, flawless engineer The guy in the next cubicle is not Much easier to test everyone’s code, and prevent

singling-out the bad engineers A single mistake will cost the company millions of

dollars Verification consumes more than 50% of budgeted

time


What is a testbench?

CUT

Testbench

in outout in

The purpose of a testbench circuit is to evaluate whether or not the circuit-under-test (CUT) meets specifications properly

Unlike normal circuits, a testbench’s outputs are on the ‘left’ side, while the inputs are on the ‘right’ side


How the test bench works It must independently and automatically generate a

stream of output that acts as valid input for the CUT

The testbench must also examine the output of the CUT, and determine if the CUT is performing according to specification You’re the one who generated the input, so it should

be easy, right? There are many ways of doing this


Designing test benches isn’t a quick process Supposing you write a testbench, how are you sure it is

correct? You wrote it very carefully You test it on someone else’s interpretation of the spec

Some very large problems can happen if you let one designer do both testing and CUT design What if the designer is interpreting the spec differently than

everyone else? What happens if Valid goes low (from high) while ready is low?

Did the data just vanish? Does a stream end at 24 words by specification, or must you

force it to end by dropping ready?

Don’t worry about the area or timing of a test bench You’ll never have to synthesize or fabricate it Feel free to go ‘crazy’ with nested if’s and large case

statements


Quick and Dirty Testing ‘Proper’ verification is a complex task, requiring

well-specified I/O and other such things

Simple quick and dirty testbench design will generate inputs according to a pattern, and test the outputs according to a similar pattern

To make testing simple, designers often use ‘special case’ input Corner Cases


Advances on that basic concept What if you’re accidentally testing an “up-by-one counter”?

You won’t even notice a problem

Are you testing reset?

What about asserting/dropping the ‘valid’ signal for handshake operations (in memories)? Don’t assume data will always be available

Adding stochastic/random elements to the test helps force out coincidence Why not send $random(1)}%BITWIDTH instead of just 1? Resulting data stream much less likely to show up by chance Why not make handshake signals also function on some

randomized function? Use parameters to easily adjust performance of your testbench


Black/White Box testing There are two primary types of test benching –

White Box – Assumes you know what’s going on inside the CUT Black Box – Tests only the interface specification – Things at the

‘edge’ of the CUT

White Box testing is what most people code without realizing it Your testbench might assume that the Cdata comes out one cycle

after the input port receives the data This isn’t always the case. What if the interleaver has an 8 word

memory buffer, and only outputs data when the buffer is full? Still meets spec!

Black Box testing is more general, and safer Doing black box on subcomponents, then components, then even

higher levels of abstraction is a version of white box testing – but a good one.


Black and White Box Testing

Black Box: Testbench knows nothing about CUT Advantages:

success means real functionality to external interface Testbench is re-usable on different implementations

External interface is all outside world ever sees anyway Problems:

Sometimes errors can exist without being evident on outside Or may be detected earlier if you can look inside Sometimes it is difficult to really think in terms of black box behavior

White Box: Advantages:

Efficiency, speed, possible with less definite interfaces Disadvantages:

Very implementation specific


Testbench application Heirarchical

A “System” is the component that contains the current design

“System” = whole chip (cell phone) “design” = chip block (DSP block)

“System” = chip block (DSP) “design” = sub-block (memory engine)

Can and SHOULD do top level, but hierarchical verification improves the quality and re-usability of the design


White-box, Black-box, Hierarchical

Designs are hierarchical Black box tests the interface on the external component System doesn’t care about the hierarchy inside

Hierarchical Black Box == White Box


Test Bench Example

entity test_bench isend entity test_bench;

architecture test_reg4 of test_bench issignal d0, d1, d2, d3, en, clk, q0, q1, q2, q3 : bit;

begindut : entity work.reg4(behav)

port map ( d0, d1, d2, d3, en, clk, q0, q1, q2, q3 );stimulus : process isbegin

d0 <= ’1’; d1 <= ’1’; d2 <= ’1’; d3 <= ’1’; wait for 20 ns; en <= ’0’; clk <= ’0’; wait for 20 ns;en <= ’1’; wait for 20 ns;clk <= ’1’; wait for 20 ns;d0 <= ’0’; d1 <= ’0’; d2 <= ’0’; d3 <= ’0’; wait for 20 ns;en <= ’0’; wait for 20 ns;…wait;

end process stimulus;end architecture test_reg4;

No I/O Ports


Regression Testing

Test that a refinement of a design is correct that lower-level structural model does the same as a behavioral

model

Test bench includes two instances of design under test behavioral and lower-level structural stimulates both with same inputs compares outputs for equality

Need to take account of timing differences Will be addressed as we go along


Testbench example

entity testand2 is

end testand2;

architecture io of testand2 is

component and2

port (X, Y : in std_logic; Z: out std_logic);

end component;

signal A,B,C : std_logic;

begin

G1: and2 port map (X=>A, Y=>B, Z=>C);

A<= '0', ‘0’ after 100 ns, '1' after 200 ns, ‘1’ after 300 ns;

B<= '0', ‘1’ after 100 ns, ‘0' after 200 ns, ‘1’ after 300 ns;

wait;

end io;

•No inputs, outputs for the testbench

•Component declaration and instantiation

•A<=‘0’,’1’ after 100 ns

•Simulation waveform


Testbench example (2)

entity testand2 is

end testand2;

architecture io of testand2 is

component and2

port (X, Y : in std_logic; Z: out std_logic);

end component;

signal A,B,C : std_logic;

begin

G1: and2 port map (X=>A, Y=>B, Z=>C);

A<=‘0’; B<=‘0’; wait for 50 ns;

A<=‘0’; B<=‘1’; wait for 50 ns;

A<=‘1’; B<=‘0’; wait for 50 ns;

A<=‘1’; B<=‘1’; wait for 50 ns;

wait;

end io;

Stimulus inputs different formats:


And2 testbench Simulation waveform


On the FPGA Architectures… Design Flow

Good engineering practice requires that design exercises should follow a defined procedure

User’s specification This is your starting point It may take several forms

1. Informal requirements given to you by your user / client / …2. Formal written requirements

–All functional and non-functional requirements are precisely stated–Sometimes resulting in a very large (and dull) document!

3. Something in between–Your tutorial assignment was in this category–Mostly formal, but with some gaps you would need to fill in–Using research / further discussion with client / … etc


Step 1 - Analysis

Design Step 1 – Analyze specification Identify suitable circuit modules by carefully reading specification Start at top level – identify major components first

In particular, identify interfaces between environment and device that you’re designing

– Washing machine example:• Inputs - User buttons, dials, sensors, …• Outputs – Motors, indicator lights, audio, …

From these, specify the top-level entity

ENTITY wm ISstart, lid, stop : IN std_logic_vector;audio : OUT audio_sample;…

END ENTITY wm;


Step 1 - Analysis

Design Step 1 – Analyze specification

Note that you may defer implementation details! In this case, you don’t want to bother with the details of the audio

output stream yet, so just specify a type audio_sample without filling in details for it yet.

Checking your design A VHDL compiler (usually the simulator’s compiler) should be used

to check completeness and consistency of a design from the early stages!


END ENTITY wm;


Step 1a – Analysis : Checking the Design

Design Step 1 – Analyze specification Checking your design

A VHDL compiler (usually the simulator’s compiler) should be used to check completeness and consistency of a design from the early stages!

Even though many details are missing– Initially you may have no architecture blocks at all!

A compiler will warn you of missing, incomplete or inconsistent specifications

Thus although diagrams (and other informal modeling tools – like pencil and eraser!) are very useful,you should be generating formal (checkable) design specifications at a very early stage.

– These may be abstract• High level• Missing implementation details

but they are vital for detecting design errors!



Design Step 1 – Analyze specification Checking your design

In this example, you have deliberately deferred a decision about the exact form of audio_sample. You will need to provide a definition of it for the compiler, but you

can substitute anything that the compiler will accept at this stage! Make a package


END ENTITY wm;

PACKAGE audio ISTYPE audio_sample IS integer RANGE 0 TO 255;

END PACKAGE audio;



Design Step 1 – Analyze specification Deferred detail ...

Many possibilities exist for the deferred detail …

or

or

PACKAGE audio ISTYPE audio_sample IS std_logic_vector(0 TO 7);

END PACKAGE audio;

PACKAGE audio ISTYPE audio_sample IS std_logic_vector(sample_size);

END PACKAGE audio;

PACKAGE audio ISTYPE audio_sample IS …; -- Your own idea!

END PACKAGE audio;

Key idea:Use the compiler to check your design as much as possible!These deferred definitions are necessary to avoid messages like ‘xxx is undefined’which prevent the compiler from checking the rest of the design!


Step 2 - Refining the design

Once you have a formal VHDL specification for the high level entity for your design

Step 2 is to refine the design

wm (washing controller)

startlid

motor

stopvalves

audio



Step 2 is to refine the design Determine the internal structure of your component

What entities do we need to implement the requirements?– Counters, timers, …– State machines, … (overall control)– Device controllers

eg PWM for motors, display controllers, … Write formal models (VHDL entities) for each internal component

ENTITY count_down_timer ISPORT( clk, reset : IN std_logic;

cycles : IN std_logic_vector;complete : OUT std_logic );

END ENTITY count_down_timer;

ENTITY speech_synth ISPORT( … );

END ENTITY speech_synth;

ENTITY motor_control ISPORT( … );

END ENTITY motor_control;



Step 2 is to refine the design Determine the internal structure of your component Write formal models (VHDL entities) for each internal component Determine how these models are connected


startlid

motorstopvalves

audio

main_fsm

speech_synth

c_d_timer


Step 3 – Assemble the system

Step 3 – Build a model which includes all the componentsof the system you are buildingie write the ARCHITECTURE block

Generally this will be a structural VHDL model VHDL models may be mixed, so this is not a hard rule!

startlid motorstop valves


audio

main_fsm

speech_synth

c_d_timer

ARCHITECTURE a OF wm ISCOMPONENT main_fsm PORT( … );COMPONENT speech_synth PORT( … );COMPONENT c_d_timer PORT( … );SIGNAL …BEGINfsm: main_fsm PORT MAP( … );t1: c_d_timer PORT MAP( … );

END ARCHITECTURE a;


Step 3a – Check the design Use the compiler (simulator or synthesizer) to check the design

Check for Completeness

– All required modules are present– All required signals are present

Consistency– All signals are connected to signals of matching types eg

• No std_logic connected to std_logic_vector• std_logic_vector sizes are compatible

(no 8-bit busses connected to 16-bit ones!) etc

For example, checking the models sketched in the last few slides would reveal that there was no clock to feed the timer! So one would be added …

Repeat steps 1 – 5 until no errors are reported Even though some types (eg audio_sample) are not in their final form!


Step 4 – Complete the details

Fill in all architectures You only need top-level structural architectures to check the

design! Now you need to complete them all!

Decide on all deferred types Any design decision that you deferred …

Add assertions! Don’t forget to try to make your design check itself


Step 5 - Simulation

Now we’re going to check the design using the simulator

We built a model of the device we’re going to place in an FPGA (or ASIC or …)


audio

main_fsm

speech_synth

c_d_timer

motor valves

start lid

pause

clock

Note that the clockhas been added now!(We discovered that it

was missing in design check!)

Did we forget something???


Step 5 - Simulation

Build any additional models needed Clock model Models to simulate external devices

eg camera, printer, keyboard, … Special models for generating

test dataeg random data

generators wm (washing controller)

audio

main_fsm

speech_synth

c_d_timer

motor valves

start lid

pause

clock clock


Step 5a - Build a test bench Wrap all the models in a test bench

A test bench isusually an ENTITYwith no ports!

The ARCHITECTURE of the test bench normally consists of a structural part a process block to generate test data


audio

main_fsm

speech_synth

c_d_timer

motor valves

start lid

pause

clock clock

test_bench

ENTITY test_bench ISEND test_bench;


Test bench The test bench

ARCHITECTUREnormally consists of a structural part a process block to

generate test data


audio

main_fsm

speech_synth

c_d_timer

motor valves

start lid

pause

clock clock

test_bench


ARCHITECTURE s OF test_bench ISCOMPONENT clock PORT( clk: OUT std_logic ); END COMPONENT;COMPONENT wm PORT( clk, start, lid, pause: IN std_logic;

……); END COMPONENT;SIGNAL clk, start, lid, pause : std_logic_vector;BEGINc : clock PORT MAP( clk => clk );f : wm PORT MAP( clk => clk, start => start, lid => lid, … );p : PROCESS

BEGIN … END PROCESS;END ARCHITECTURE s;


Test bench

Driving the signals of the component under test For a simple component,

a data flow model with waveform signal assignments may suffice For our washing machine, we need to check

– Starting, stopping, pausing, opening the lid, …– So for basic operations, waveforms applied to the control

inputs will do:

start <= ‘0’, ‘1’ after 1 sec, ‘0’ after 50 ms -- check starting

‘1’ after 10 sec, -- 2nd start should not do anything

‘0’ after 50 ms,‘1’ after 1000 sec, -- start another test……

lid <= ‘1’, -- start with lid closed

‘0’ after 5 sec, -- open lid after start

‘1’ after 10 sec, -- close again to resume

…


Test bench

Driving the signals of the component under test For a more complex component

(or more complex tests applied to a simple component!) we’ll generally need to write some loops in PROCESS blocks

PROCESSBEGINFOR j IN 0 TO 9 LOOP – Perform 10 tests

start <= ‘0’; lid <= ‘1’; pause <= ‘0’;WAIT FOR 1 sec;-- Now change the control inputs according to some-- tablestart <= s(J); lid <= l(j); pause <= p(j);WAIT FOR t(J);-- Check result

END LOOP;END PROCESS;

Assumes thatwe’ve generated

some tables,s(0 TO 9), l(0 TO 9),p(0 TO 9), t(0 TO 9)

containing test data


Step 6 - Verifying the Design

You can check the design by examining simulator waveforms

start

valve

motor

drain


audio

main_fsm

speech_synth

c_d_timer

motor valve (water in)

start lid

pause

clock

drain (water out)

Note that for this example, we have specifically listed 3 outputsmotor - turns the motor onvalve - opens the water inletdrain - opens the water outlet

Pulsing the start input should start a washing cyclePulsing it again should not stop the cycle

Cycle starts by opening the inlet valve

After it closes, the motor should start

The motor should stop and the drain openDrain closes, inlet opens ….


Step 6 - Verifying the Design

You can check the design by examining simulator waveforms

start

valve

motor

drain


audio

main_fsm

speech_synth

c_d_timer


start lid

pause

clock

drain (water out)

We could check everythingby visually examining thistrace ...

painful,manual,error prone in a large design ...

We can do much better!!


State machine outlineENTITY wm ISPORT( clk, start: IN std_logic;motor, valve, drain: OUT std_logic;… );

END ENTITY wm;

ARCHITECTURE a OF wm ISTYPE wm_states IS (off, w_in1, wash, w_out1, w_in2, rinse, .. );COMPONENT …SIGNAL s : wm_states;BEGINPROCESS( clk )BEGINIF clk’EVENT AND clk = ‘1’ THENCASE s ISWHEN off =>IF start = ‘1’ THENvalve <= ‘1’; -- Open the valve

-- More detail on next slide!! END PROCESS;

END ARCHITECTURE wm;

Details not relevant tothis example omitted!


State machine outlineARCHITECTURE a OF wm ISTYPE wm_states IS (off, w_in1, wash, w_out1, w_in2, rinse, .. );COMPONENT …SIGNAL s : wm_states;BEGINPROCESS( clk )BEGINIF clk’EVENT AND clk = ‘1’ THENCASE s ISWHEN off =>IF start = ‘1’ THENvalve <= ‘1’; -- Open the valves <= w_in1;… -- start the timer

END IF;WHEN w_in1 =>IF timer_complete THENvalve <= ‘0’; -- close the valves <= wash;motor <= ‘1’;… -- start the timer

END IF;WHEN wash =>… -- and a lot more follows!

END CASE; END PROCESS;


To keep it simple:A lot of detail ismissing from this model!


Verifying the Design

Looking at thewaveforms again,what things can youobserve that are (should!!)always be true??

start

valve

motor

drain


audio

main_fsm

speech_synth

c_d_timer


start lid

pause

clock

drain (water out)



Looking at thewaveforms again,what things can youobserve that are (should!!)always be true??

start

valve

motor

drain


audio

main_fsm

speech_synth

c_d_timer


start lid

pause

clock

drain (water out)

Only one of valve, motor or drain is ‘1’ at any time!

So we can add an ASSERT to the model!

ASSERT ((valve OR motor OR drain) = ‘0’) OR(valve=‘1’ AND motor=‘0’ AND drain=‘0’) OR… REPORT “Two outputs ON” SEVERITY warning;



These are not the only assertionsthat can be madeabout this design! What are some

others?Hint: Look at someof the other signals!

start

valve

motor

drain


audio

main_fsm

speech_synth

c_d_timer


start lid

pause

clock

drain (water out)


Adding the assertionsARCHITECTURE a OF wm ISTYPE wm_states IS (off, w_in1, wash, w_out1, w_in2, rinse, .. );COMPONENT …SIGNAL s : wm_states;BEGINPROCESS( clk )BEGINIF clk’EVENT AND clk = ‘1’ THENCASE s ISWHEN off =>IF start = ‘1’ THENvalve <= ‘1’; -- Open the valves <= w_in1;… -- start the timer

END IF;WHEN w_in1 =>… -- and a lot more follows!

END CASE; END PROCESS;ASSERT ((motor=‘0’) OR (valve=‘0’) OR (drain=‘0’)) OR … REPORT … SEVERITY …;ASSERT ((lid=‘0’) AND (motor=‘0’)) REPORT … SEVERITY …;


Unfortunately, the compiler willreject this assertion if you write itjust like this!

motor, valve and drain are declaredOUT and strictly cannot be ‘read’ here!

A simple `work-around’ solves this problem


Adding the assertionsARCHITECTURE a OF wm ISTYPE wm_states IS (off, w_in1, wash, w_out1, w_in2, rinse, .. );COMPONENT …SIGNAL s : wm_states;SIGNAL motor_i, valve_i, drain_i : std_logic;BEGINPROCESS( clk )BEGINIF clk’EVENT AND clk = ‘1’ THENCASE s ISWHEN off =>IF start = ‘1’ THENvalve_i <= ‘1’; -- Open the valves <= w_in1;… -- start the timer

END IF;WHEN w_in1 =>… -- and a lot more follows!

END CASE; END PROCESS;ASSERT ((motor_i=‘0’) OR (valve_i=‘0’) OR (drain_i=‘0’)) OR … REPORT … SEVERITY …;ASSERT ((lid=‘0’) AND (motor_i=‘0’)) REPORT … SEVERITY …;motor <= motor_i; valve <= valve_i; drain <= drain_i;


Add internal signals, which are set bythe state machine …As internal signals, they can be read

Assign them to the actual outputsin the body of the architecture!


Adding the assertions

Because of this minor complication,some might prefer to add the ASSERT’s to the test bench The outputs of the module under test can be read in the test bench! I would prefer to add them to the module itself -

This ensures that they are active in ALL test benches We might write several test benches to test various aspects of a design!

but, this is a personal preference

The important thing is to have them somewhere!! They make your model self-checking Automatic checking is more robust than manual checking!


Alternative verification strategies

When the outputs are complex functions of the inputs, assertions may become either incredibly complex

and thus difficult to code (and get right!) impossible

because of the complex logic required

PROCESS blocks may always be added to the test bench to check that the outputs are correct They can contain arbitrarily complex code -

and can thus check complex conditions Automated checking of models VHDL is just like a programming language

Test benches can write log files, dump data to disc files, etc These files can be checked mechanically by other programs

Use the test bench to automate testing!! Use ASSERT or algorithmic code in PROCESS blocks Automatic checking is more robust than manual checking!

You can also writeVHDL functions

to simplify ASSERT conditions!


Summary Cannot stress enough how important is to verify design

Cannot stress enough how important is to verify design

Cannot stress enough how important is to verify design

Use simulation

Attack corner cases

Test/Verify based on specs, not on what you think it should do.

Hierarchical Verification – Reuseability. If an adder has been verified and works, reuse it and “assume”

it will work forever


Conclusion Remember – if you haven’t test it, it

doesn’t work.

ΗΜΥ 664 ΨΗΦΙΑΚΟΣ ΣΧΕΔΙΑΣΜΟΣ ΜΕ FPGAs …largely synchronous Synchronous...

Documents

Transcript of ΗΜΥ 664 ΨΗΦΙΑΚΟΣ ΣΧΕΔΙΑΣΜΟΣ ΜΕ FPGAs …largely synchronous Synchronous...