Transcript Lysbilde 1 - Bitvis AS

Making a
Simple, Structured and Efficient Testbench
Step-by-step
Making a simple, structured and efficient Testbench,
Step-by-step
Espen Tallaksen
www.bitvis.no
1
About Bitvis
 Leading Vendor Independent Design Centre in Norway





FPGA and Embedded SW services for customers
From specification to final product – or any phase in between
Good overview of pitfalls, time wasters and risks
Focus on methodology, quality, efficiency and customers
Located in Asker outside Oslo
Making a simple, structured and efficient Testbench,
Step-by-step
2
Products and courses from Bitvis
 Products from Bitvis
 'Bitvis Utility Library' (Free and Open source, Directly downloadable)
- Currently being used world wide
 'UVVM' (Universal VHDL Verification Methodology) (UVL for VHDL)
To be released 2014, Q4
 'RegisterWizard',
For generation of SW, Doc. and VHDL (bus IF, regs, etc.)
To be released 2014, Q4
 Courses from Bitvis
 'FPGA Development Best Practices' - A two day course
- A pragmatic approach to improving quality and efficiency.
- So far Denmark, Sweden and Norway. May be held anywhere on request
 See our website for more offers
http://bitvis.no/services/fpga-courses/
Making a simple, structured and efficient Testbench,
Step-by-step
3
Why Testbenches and Simulation
 Far more control and observability
Design stage
Spec.
Ease of
correction &
debugging
 Far faster iterations
 May have a structured bottom-up
verification.
 Detect bugs that cannot or most
probably will not be detected in a
lab-test
 Most bugs can be found with short
simulations.
Volum/
Field
Cost of
corrections
Making a simple, structured and efficient Testbench,
Step-by-step
4
Verification:
State of the FPGA community
 Even for quite simple modules
(e.g. IRQC, SPI, I2C, UART):
 Average verification workload: 3 days to 3 weeks
 Often inadequate coverage
 Multiple Design, Synthesis, P&R iterations on full FPGA
 A low quality testbench




Hopeless to understand for anyone else
Difficult to extend
Terrible to modify
Tedious debugging
Why?
How can we improve?
Making a simple, structured and efficient Testbench,
Step-by-step
5
The Verification Paradox
 For proper simulation of FPGAs:
 More lines of verification code than for design source
 More time consuming than design
 Yet - a far lower effort is spent on verification
 Lower effort on partitioning
 Lower effort on structuring
 Lower effort on documentation
A good TB is key to success:
- Simple 500 MH project:
Saves 50-100 MH
- Complex 5000 MH project:
Saves 500-1500 MH
- Significantly improves TTM, LCC, Quality
Making a simple, structured and efficient Testbench,
Step-by-step
6
Different TB requirements (1)
 The required level of verification differs a lot
 Low verification complexity
» single data path FPGA with some additional functionality
» modules with no or very simple corner cases
E.g. GPIO, simple IRQC, CRC, FEC, decoder...
 Higher verification complexity:
 Still needs basic infrastructure – as a platform
 Need more advanced verification solutions on top
Low verification complexity  Simple Testbench
But – how simple?
Making a simple, structured and efficient Testbench,
Step-by-step
7
How simple should a TB be?
 Understanding somebody’s design module is often very hard
 Understanding somebody’s testbench is normally impossible
 And modifying it… ?
Testbench Issues:
 Purpose: To verify DUT requirements
 Focus: Sufficient functional coverage with a minimum effort
 Test Sequencer Requirements:
 Simple to write
 Simple to understand and modify - by anyone
 Simple to execute, debug and understand reports & results
Making a simple, structured and efficient Testbench,
Step-by-step
8
The development stages
 Ideally:
- Specify  Design  Simulate  Synthesize  Test
- Verification should start as early as possible
 But: Specification changes all the time…
 Design must be extended or modified
 Testbench or test cases must be extended or modified
 Simulations must be re-executed
 and the result must be checked again
 TB Readability, Flexibility and Extendibility is important
 Simulation result checking and readability is important
Making a simple, structured and efficient Testbench,
Step-by-step
9
Verification stages
- Will go through, stage-by-stage
1. Make a verification specification
– but avoid overhead and aim for single source
2. Define your TB architecture and concept
- but consider what is already available
3. Implement TB architecture
If available – start TB implementation from a template
4. Implement test cases
- In sensible steps and starting ASAP
But also focus on:
-
Simulation execution, Reporting, Debugging, Results
-
Iterations
Making a simple, structured and efficient Testbench,
Step-by-step
10
IRQC
The IRQC
clk
arst
bus interface
/
n
irq_source(n)
irq2cpu_ack
irq2cpu
IRQC
IRR(0)
irq_source(0)
clk
arst
Bus
interface
S
R
ITR(0)
bus interface
ICR(0)/
irq_source(n)
n
IPR(0)
Q
IPR(1..n)
igr
irq2cpu
(to CPU)
irq2cpu
irq2cpu_ack IER(0)
(Handling of one
single irq_source.
To be repeated for
all sources.)
D Q
Note: Uppercase names indicate software
accessible registers (or dummy registers)
Making a simple, structured and efficient Testbench,
Step-by-step
IRQ2CPU_ENA
D
irq2cpu_ack (from CPU)
R
11
Q
IRQ2CPU_ALLOWED
1: Make a verification specification
 A verification specification is always needed, but
 The verification spec. should not be too extensive/detailed
 Required details could be added in a later spec. iteration
 A separate verification spec. document is normally not
needed
irq_source(n)
IRR(n)
Verification specification IPR(n)
IRQC: igr
•
•
•
•
•
•
Check
Check
Check
Check
Check
Check
ITR(n)
S
Q
R
irq2
cpu
defaults on output ports
ICR(n)
register defaults
and access (write + read)
IER(0)
register trigger/clear mechanism
interrupt sources,
IER, IPR and irq2cpu
IRQ2CPU_ENA
autonomy for all irq2cpu_ack
interruptsIRQ2CPU_
ALLOWED
irq acknowledge and re-enable
Making a simple, structured and efficient Testbench,
Step-by-step
D Q
D Q
R
12
2: Define your TB architecture
 Two main categories for almost all modules
- Defined by degree of interaction on interfaces
1. Basic TB infrastructure only
2. TB for simultaneous handling of multiple interfaces
 IRQC has very simple interfaces
 Very little and no critical interaction
 No contention issues
 Still – A bad design may always fail for corner cases
 Hence IRQC TB
 Simple Verification
 Simple TB arch./concept
 Basic TB infrastructure
Making a simple, structured and efficient Testbench,
Step-by-step
13
Simple TB architecture
 Avoid all complex issues
 No support for handling simultaneous interfaces
 No queuing of commands
 Use a single, simple, understandable test sequencer
 Required support
TB_IRQC
 Logging
 Alert handling & reports
 Continuous actions
Test
sequencer
» Actions not handled by sequencer
» Min. interaction with sequencer
 Repeated actions
» Avoid unstructured copying
» Provide more info for multi-usage
Making a simple, structured and efficient Testbench,
Step-by-step
14
Support
processes
DUT
(IRQC)
Support
procedures & functions
3: Implement TB architecture
Ready to implement the first tests
TB is
workload
so far: 10-30 min.
Assuming no template
available…
------------------------------------------------
*** Inside TB architecture:
-- Main process and test sequencer
-----------------------------------------------p_main: process
begin  Push-button in several tools (MsD,
log(ID_LOG_HDR, "Start simulation TB_IRQC");
clock_ena <= true;
-- start clock generator
 Generate TB entity with DUT instantiated
Emacs, etc.)
 Add support process for clock generation
***  Allow enable/disable from seq.
*** Actual test sequence. To be filled in
***
 Add test sequencer process
TB_IRQC
Test
sequencer
DUT
 Main process in TB
--==========================================================
(IRQC)
log(ID_LOG_HDR,
COMPLETED");
 Controls "SIMULATION
everything!
Support
clock_ena <= false;
-- to gracefully stop the simulation
» From TB initialization
processes
assert false
report» "End
of simulation.
(***Ignore this provoked failure.)"
To termination
of simulation
severity failure;
Support
wait; -- to stop completely
procedures & functions
end process p_main;
Making a simple, structured and efficient Testbench,
Step-by-step
15
4a: Implement First tests
Inside p_main process
test sequencer process)
set_inputs_passive(VOID);
apply_reset(VOID);
 First tests are important
 To verify
compilation
and
elaboration
log(ID_LOG_HDR,
"Check
defaults on
output
ports"); OK
-------------------------------------------------------------- To see that '0',
our ERROR,
Testbench
is up
running
check_value(irq2cpu,
"irq2cpu
mustand
be default
inactive");
check_value(dout,
x"00",
ERROR,
be of
default
inactive");
 To actually
verify
our“dout
first must
tests
the DUT
 First test: Output defaults
TB_IRQC
The abovecode
resulttest
in the following log/transcript: Test
Verywill
simple
sequencer
DUT
AllowsAll
module
to be
integrated
BV: 0 ns 
irqc_tb
inputs set
passive
(IRQC)
BV: 60 ns irqc_tb Pulsed reset-signal - active for 10T
Support
 First example on active support
BV:
processes
Progress information
BV: 60 ns irqc_tb
Check
defaults
on output ports
» Using
support
procedures
BV:---------------------------------------------------------------------BV: 60 ns irqc_tb check_value(sl 0)=> OK. irq2cpu must be default inactive
Support
BV: 60 ns irqc_tb check_value(slv x00)=> OK. dout must be default inactive
procedures & functions
Detailed progress information. Only interesting initially and for debug…
Making a simple, structured and efficient Testbench,
Step-by-step
16
Verbosity control
 Method to control amount of information
 To allow only selected groups of messages
 Allows reduction/increase of information – without
modifying the code (comment/uncomment)
 Makes it possible to get a different set of messages
depending on current simulation focus - e.g.:
»
»
»
»
Debugging testcase or verification component
Debugging a specific interface on DUT
Debugging a data flow through DUT
General simulation progress report.
 E.g. Modelsim vsim options:
-version
-quiet
+sdf_verbose
Print the version of the simulator
Do not report 'Loading...' messages
Display SDF annotator status messages
 verbosity switches turning on or off
a given set of messages
Making a simple, structured and efficient Testbench,
Step-by-step
17
Priority based verbosity control
 Every message has a given priority.
 Typically 1 for a high priority message and 6 for a low priority
message.
 Every possible message from any part of the testbench has a
given priority - normally defined when writing the message.
E.g. log(2, "Packet header received”)
 Verbosity level will determine which messages to show
 E.g. a verbosity level of 2 means
- Only priority 1 and priority 2 messages are let through
(i.e. shown in the transcript or log);
- whereas all other messages are blocked.
 Messages could be defined anywhere
 In Sequencer, BFMs, verification components, other
processes, etc..
 SystemVerilog’s verbosity control is basically priority based
Making a simple, structured and efficient Testbench,
Step-by-step
18
ID based verbosity control
 ID based verbosity allows log messages with different
IDs to be shown or blocked depending on whether a
given ID is enabled or disabled.
 Every message has a given ID
 Could be a string, a number, an enumerated, etc….
 There are no priorities
E.g. ID=58 and ID=216 are not prioritised in any way
 Example: log(216, "Packet header received”)
 Verbosity control will determine which messages to
show
 Test sequencer may enable or disable message IDs dynamically
depending on which messages are of interest.
 SystemC’s verbosity control is ID based
Making a simple, structured and efficient Testbench,
Step-by-step
19
Verbosity Control – Using Enumerated
 ID based verbosity control.
 Enumerated IDs
 A set of predefined IDs. E.g. ID_LOG_HDR or ID_BFM
 Example: log(ID_BFM, "UART byte received")
 Verbosity control
 Enable an ID using enable_log_msg(ID_BFM)
 Disable an ID using disable_log_msg(ID_BFM)
 Only enable or disable from the test sequencer!
Making a simple, structured and efficient Testbench,
Step-by-step
20
Why ID based verbosity
 Far more flexible and controllable
 Real priorities are dependent on the situation
 application
 development stage
 problem at hand
 ID’s allows full control of verbosity
 May still define numeric priorities locally
 E.g. to indicate your assumed priorities
 May then choose to use numeric priority or ID
 ID-based verbosity is a superset of priority-based.
Making a simple, structured and efficient Testbench,
Step-by-step
21
The need for verbosity control
Verbosity control is not required for the simplest TBs, but...
 Provides an advantage - even for most really simple TBs
 More efficient to use the same methodology for simple,
medium and advanced TBs
 Most TBs normally end up more advanced than assumed
 Yields no overhead in even the simplest test sequencer
Now – back to simple TB
Making a simple, structured and efficient Testbench,
Step-by-step
22
Back to TB: Do not waste time
 Most designers are unstructured wrt. verification





Do
Do
Do
Do
Do
not
not
not
not
not
wait with your testbench and verification
dive into your first test case with no structure
use stupid testbench generators
write stimuli sequences by pure assignments
check results by checking outputs in the wave view
 Identify the need for subprograms – ASAP
 Immediately write subprogram when detecting repeated code
 Write a “self checking” testbench
 Requires good check subprograms
 Good Comments/documentation is NEVER wasted
 Provide in sequencer and in log/transcript
Making a simple, structured and efficient Testbench,
Step-by-step
23
Identify the need for subprograms
*** Inside p_main process (test sequencer process)
 Obvious subprogram candidates for IRQC
log_hdr(“Reset");

Register Access
--------------------------------------------------------------set_inputs_passive(VOID);

Signal checkers
Local procedure – dedicated to inputs
apply_reset(VOID);
 Interrupt source pulsing?
whether
this should
be
 Evaluate
Interrupt
acknowledge
pulsing?
a common, slightly more general procedure…
 (Report/log method)
Common procedures.
 (Alert-handling)
Logging
IRR(n)and checking is
irq_source(n)
IPR(n)
required in all
testbenches.
 (reset, set_passive, …)
S
Q
igr
log_hdr("Check defaults on output ports"); ITR(n)
--------------------------------------------------------------Split
in two categories
check_value(irq2cpu, '0', ERROR, "irq2cpu must
be default inactive");
ICR(n)

Local
–
IRQC-dedicated
check_value(pif_irqc_dout, X"00", ERROR,
D Q
IER(0)
» “pif_irqc_dout
Declare locally must be default inactive");
R

irq2
cpu
 Common – non dedicated
» Declare in common package
» Share with others
Making a simple, structured and efficient Testbench,
Step-by-step
IRQ2CPU_ENA
irq2cpu_ack
24
D Q
R
IRQ2CPU_
ALLOWED
4b: Next test: Register Access
 First check register defaults
 Then general access (Write + Read)
 Provide Check-procedure – using Read
 Make dedicated procedures
 Will be common for many register interfaces
 Bus access procedures are used to set up
signal sequences to access internal registers
 BFM : Bus Functional Model
Making a simple, structured and efficient Testbench,
Step-by-step
25
BFM / TLM Purpose
 Handle transactions at a high level
 E.g. Read, Write, Send packet, Config, etc
 More understandable for anyone
Example:
BFMcode
for a&CPU
access tooverview
a module's register
 Simpler
Improved
write
Uniform
style, method,
result 0x22 (“100010”)
E.g.
0xF0 (“11110000”)
into asequence,
register at address
 Easy to add several very useful features
cs
<= ’1’;
we
<= ’1’;
addr
<= ”00100010”;
data
<= ”11110000”;
wait until rising_edge(clk);
wait until falling_edge(clk);
cs
<= ’0’;
we
<= ’0’;
Making a simple, structured and efficient Testbench,
Step-by-step
Replaced by
write(x”22”, x”F0”);
26
Major BFM quality differences
 Inside a ”normal” BFM
» Pure Read, Write or Check transaction
 Additionally - Inside some BFMs
» Syncronization of access to the relevant clock
 Additionally - Inside good BFMs
»
»
»
»
»
»
Normalisation of inputs
Sanity-check on inputs
Configuration of behaviour
Logging of all accesses – with parameters and result
Severity control and alert handling
Verbosity control to potentially suppress log
Making a simple, structured and efficient Testbench,
Step-by-step
27
Making common, general BFMs
function normalise(
*** parameters (incl. implicitly constrained vectors)
) is
***
Constantsuse
and unconstrained
Variables
 Hence
input vector for addr & data
begin
But unconstrained
vectors
do not define direction/range
***checks
for legal constrained
ranges
e.gif constant
: in std_logic_vector;
*** check
(restrictiondata_exp
= ALLOW_WIDER_SOURCE)
then
check_value(***Complex check and reporting***);
*** corresponding checks for ALLOW_SHORTER_SOURCE, etc.
*** Adapt value to target signal range and return
end;  Comparisons, Bit-manipulation, etc…
 Value and Signal widths are initially unknown
 Unconstrained data must often be “interpreted”
 Must Normalise
 Must Check for sanity – for early problem detection
Making a simple, structured and efficient Testbench,
Step-by-step
28
Make and run first BFM - Summary
As soon as register interface is implemented:
 Make BFMs for write, read, check – in a common package
 Then
make simplified
BFMs
procedure
sbi_write
(
constant
addr defaults,
: inand unsigned;

First
check
then write followed by check
procedure
write (
constant data_in
: in
std_logic_vector;
write(x"1",
x"0F", "IER");
constant
: in
unsigned;
signal
cs addr
: inout
std_logic;
check(x"1",
x"0F", error,
readback");
signal
addr
: inout
unsigned;
constant
data_in
: "Pure
in
std_logic_vector;
signal
wr msg
: inout
std_logic;
Only
allowed
by verbosity
constant
:if in
string
:= "" control
std_logic;x00000F) completed. IER
SBI write(x1,
if ) signal
isBV: 172rdns. irqc_tb : inout
std_logic_vector;
BV: 192din
ns. irqc_tb : inout
SBI check(x1,
==> x00000F) completed.
check begin
oksignal
signal
rdy
: inPure std_logic;
BV:
readback
sbi_write(addr,
data_in,
pif_irqc_cs,
pif_addr, pif_wr, pif_rd,
signal
clk
: in
std_logic;
pif_din,
clk,
C_T_CLK, x00000F)
msg , C_SCOPE,
constant
time;
BV:
172clk_period
ns. pif_rdy,
irqc_tb : in
SBI write(x1,
completed.***more***);
IER
if
end;
constant
msg
:
in
string;
BV:
check
scope
: in
string;
BV:==============================================================
not ok constant
***BV:
more
***
Not
(or counted)
if setlimit
to ignore
Error
Will shown
break simulation
if stop
is reached
ERROR:
) is
BV: 192 ns. irqc_tb
begin BV:
value was: 'x00000E'. expected 'x00000F'.
normalise,
sanity
adapt, synch,
write,
wait?, alert?, log?
BV:
(Fromcheck,
SBI check(x1,
x0F, Pure
readback))
end; BV:==============================================================
Making a simple, structured and efficient Testbench,
Step-by-step
29
TB: Workload so far?
Note: Assuming a TB infrastructure for log/alert/checks
Otherwise only slightly more, but far less log/report/debug)
Initial architecture
10-30 min
First tests: Incl. simple local procedures
10-30 min
Simple BFM set for a known protocol
- More for protocol-oriented BFMs
1-4 h
Overhead for Good BFM (Normalise, Log, Checks, etc.)
- Given a good BFM template
30-60 min
Reg. access tests and reg. interaction
10-30 min
Total so far:
2-7 h
Making a simple, structured and efficient Testbench,
Step-by-step
30
4c: Continuing with TB for IRQC
log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE);
-----------------------------------------------------------write(C_ADDR_ITR, x"AA", "ITR : Set interrupts");
 Just a series of Write and Check procedures
check(C_ADDR_IRR, x"AA", ERROR, "IRR");
write(C_ADDR_ITR, x"55", "ITR : Set more interrupts");
check(C_ADDR_IRR, x"FF", ERROR, "IRR");
write(C_ADDR_ICR,
x"71",
Clear interrupts");
 E.g. interrupt
to"ICR
CPU: stable
on or off
check(C_ADDR_IRR, x"8E", ERROR, "IRR");
x"85",
"ICR
: which
Clear the
interrupts");
*** write(C_ADDR_ICR,
time_tmp is set at
a time
from
interrupt should be stable
check(C_ADDR_IRR, x"0A", ERROR, "IRR");
 E.g. interrupt
occur
wrt.
activated
source
write(C_ADDR_ITR,
x"55",
: Set
more
interrupts");
check_stable(irq2cpu,
(nowto
- "ITR
time_tmp),
error,
"No previous
active irq2cpu");
check(C_ADDR_IRR, x"5F", ERROR, "IRR");
await_value(irq2cpu,
'1', 0 "ICR
ns, C_T_CLK,
ERROR, "IRQ2CPU expected by now");
write(C_ADDR_ICR, x"5F",
: Clear interrupts");
check(C_ADDR_IRR, x"00", ERROR, "IRR");
***Etc…
 Checking register interactions
 Checking signal stability
 Waiting for an event- inside a “window”
Making a simple, structured and efficient Testbench,
Step-by-step
31
Making local procedures
 Local
procedures
bethis
made
for any
Then
evaluateshould
whether
should
be
actions
formore
which
a common
(central)
arepeated
common,
slightly
general
procedure…
procedure does not make sense
addition to the actual signal toggling
 pulse_irq2cpu_ack(
E.g. pulsing the interrupt In
acknowledge:
procedure
– several tasks should be added.
constant dummy : in
t_void
) is
variable initial_value : std_logic := irq2cpu_ack;
Check that ack is not already active
begin
check_value(std_match(irq2cpu_ack, '0'), tb_warning, “Test seq.”,
"irq2cpu_ack='1' when pulse_irq2cpu_ack() called");
wait until falling_edge(clk);
irq2cpu_ack <= '1';
Synchronise pulse on and off
wait until rising_edge(clk);
wait for (C_T_CLK / 4);
Report the pulse to the log
irq2cpu_ack <= '0';
log(ID_SEQUENCER_SUB, “Test seq.”, "Pulsed irq2cpu_ack from 0 to 1 to 0");
end;
Dedicated msg ID
Making a simple, structured and efficient Testbench,
Step-by-step
32
4d: Completing the Test case
 Add missing sections acc. to verif. spec.
 Fill inn all sections
 Section headers  Log headers
 Details inside sections  Std. log messages
 End simulation by reporting all alerts
Making a simple, structured and efficient Testbench,
Step-by-step
33
Report summaries
 report_alert_counters()
 Reports all alert counters
===========================================================================
BV: *** SUMMARY OF ALL ALERTS ***
BV: ======================================================================
BV:
REGARDED
EXPECTED IGNORED
Comment?
BV:
NOTE
:
0
0
0
ok
BV:
TB_NOTE
:
0
0
0
ok
BV:
WARNING
:
0
0
0
ok
BV:
TB_WARNING
:
0
0
0
ok
BV:
MANUAL_CHECK :
0
0
0
ok
BV:
ERROR
:
0
0
0
ok
BV:
TB_ERROR
:
0
0
0
ok
BV:
FAILURE
:
0
0
0
ok
BV:
TB_FAILURE
:
0
0
0
ok
BV: ======================================================================
BV: >> No mismatch between counted and expected serious alerts
BV: ======================================================================
Making a simple, structured and efficient Testbench,
Step-by-step
34
Verbosity control – revisited
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
Bitvis:
etc……
0.0 ns TB seq.
Start Simulation of TB for IRQC
--------------------------------------------------------------------------
 Log-result
for Check
TB for
IRQC
110.0 ns TB seq.
defaults on output
ports
--------------------------------------------------------------------------
 Only ID_LOG_HDR enabled:
110.0
seq.
Check register defaults and access (write + read)
» ns
32 TB
lines
--------------------------------------------------------------------------
» Log headers only
217.5 ns TB seq.
Check register trigger/clear mechanism
--------------------------------------------------------------------------
 All IDs enabled:
» ns
500TBlines
337.5
seq.
Check interrupt sources, IER, IPR and irq2cpu
-------------------------------------------------------------------------» All details
637.5 ns TB seq.
Check autonomy for all interrupts
--------------------------------------------------------------------------
 IRQC is an extremely simple module…
2167.5 ns TB seq.
Check irq acknowledge and re-enable
-------------------------------------------------------------------------2367.5 ns TB seq.
Check Reset
-------------------------------------------------------------------------=====================================================================
*** SUMMARY OF ALL ALERTS ***
Making a simple, structured and efficient Testbench,
Step-by-step
35
Reduced design time
 Early structured TB & test cases improve efficiency
 Forces you to think about the spec. in a different way
 Avoids wasting time on “simple/stupid” simulations
» Do NOT make initial “force/check” verification
 Yields a good TB & Test case structure - right away
» and provides a “shell” for filling in tests as needed
 Early verification of selected issues is useful
» May add verification tasks as IRQC is being designed
» No time wasted – as all verification is useful
 Continuous TB update on spec/design-changes
 Late changes are far simpler to handle
Making a simple, structured and efficient Testbench,
Step-by-step
36
Reduced debug time
 Far better simulation debug support
 Logging sequences and every single action
» Possibility to reduce amount of logging
 Good alert messages with mismatch report
» And preceeding progress report
 Far better quality on lab-releases
 Minimised need for lab debug
 Easier to make new test cases to trace lab
problems
Making a simple, structured and efficient Testbench,
Step-by-step
37
Documentation
Required doc++
Examples from IRQC testbench
Verification specification
Check register trigger/clear mechanism
1
Code sectioning for multiple test
areas
Check register trigger/clear mechanism
2
Code commenting
ITR should set IRR
Simulation status when completed
(No alerts reported)
4
Intermediate progress report
“Check register trigger/clear mechanism”
3
Alerts
“ERROR: ITR should set IRR”
Check-reports
“Checked: ITR should set IRR”
Debug support
“ERROR: ITR should set IRR;
Was ‘00110011’, expected ‘11111111’”
Progress report and debug support
“pif_write(x3, x00A5A5) completed. ITR”
 Single
all documentation/commenting
 May
easilysource
extractfor
required
documentation
Making a simple, structured and efficient Testbench,
Step-by-step
38
Bitvis Utility Library
 Open source VHDL library – Released April 2013
 Initial version VHDL 2002/08 compliant only
 VHDL '93 version released August 2013
 Important features




Logging and Verbosity control
Alert handling and reporting
Simple randomisation
Basic testbench checking and await procedures
 Simplicity is key
 Strong focus on allowing real simple infrastructure usage
 Project adaptable behaviour and log layout
 Quick Reference for all methods is provided
 Advanced method versions allow added complexity
Making a simple, structured and efficient Testbench,
Step-by-step
39
Verification effort
for a single module/FPGA
Coverage
100%
Total of 4 hours for complete TB for IRQC...
Structured approach
using an already available infrastructure
Approved
Structured approach
Typical Project
Time (MH)
Making a simple, structured and efficient Testbench,
Step-by-step
40
Conclusions for my TB for IRQC
 A uniform and structured methodology
 More compact and understandable code
 Single source for spec, code comments and logging
 Far easier to write, read, modify and extend a test case
 Easy to execute and understand output/status
 Debugging is much faster with a good progress report
 Total of 4 hours for complete TB for IRQC
 Very efficient TB implementation and design debug
Making a simple, structured and efficient Testbench,
Step-by-step
41
Making a
Simple, Structured and
Efficient Testbench
Step-by-step
The end.
Making a simple, structured and efficient Testbench,
Step-by-step
42