Download Specman.

Specman.
Presented By: Yair Miranda
Presentation Topics.


Testing micro controllers.
The specman tool.





Overview.
The e Language.
XOR example.
Application issues.
Conclusions.
Testing Micro Controllers.



Silicon hardware devices.
Micro processors, DSP etc.
Composed of various internal units like:




ALU.
I/O.
On chip cache.
Each unit has a well defined interface.
Testing Micro Controllers





(cont’d)
.
Developed using an EDA tool.
Functionality should match the spec.
Production cycle is long and expensive.
Pre production verification is crucial.
How can we verify a non existing
controller?
Testing Micro Controllers






(cont’d)
Use a simulator for verifying the chip
before production.
EDA tools provide such a simulator.
Verification by series of tests.
How to generate the tests?
What tests should be generated?
How to verify the results?
.
Specman Overview.




Specman is an object oriented programming
language (e), integrated with a constraints
solver.
Generates tests in a deterministic/random
manner fulfilling the constraints.
Interfaces with the simulator for running the
tests and verifying the results.
Functional coverage analysis to find
verification holes.
Specman Overview (cont’d).


Handles a wide range of design
environments:
 Small blocks to ASICs to complete systems.
 Cycle based to event driven simulation
environment.
An open environment:


Integration with third party EDA tools
(Verilog, VHDL).
Links with existing code (C, C++ etc).
Specman Overview (cont’d).

What is needed in order to test a design?
 Describe the signals to applied to DUT.






Generate values for input signals.
Determine values for output checks.
Interface to simulator.
Check for correctness.
Monitor progress.
Measure functional coverage.
The e Language.


An object oriented language.
Supports programming (C,C++..) and
simulation (Verilog, VHDL..)types:
 Struct, methods, inheritance, execution
control, operators etc.
 Simulation time, delays, buses, events,
triggers etc.
 Test generation, verification, coverage etc.
The e Language



(cont’d).
Strongly typed language. User defined and
predefined types.
Predefined: Integers, bytes, bits, Boolean,
strings.
User defined: Enumeration types.
type color: [red=2, green=7, blue=100];

Complex types: Lists, structs.
The e Language





(cont’d).
Lists: dynamic arrays of a given type.
Structs: a basic building block. An object (like
a C++ class).
Object contain fields (member variables) and
methods (member functions).
Objects can be inherited (extended).
Structs are the base for constraints, events,
triggers, results checking, coverage.
The e Language
struct number_bag{
//data fields
len: int;
numbers: list of int;
//methods
fill_numbers() is {
for i from 0 to len-1 do {
numbers.add (i*3);
};
};
};
(cont’d).
The e Language

(cont’d).
Macro and defines.
define offset 2;
define multiply_I_J i*j;

Methods:




Methods are struct member.
Used to perform operations.
Predefined or user defined.
Nesting is valid.
The e Language

(cont’d).
Actions: used to manipulate data and control
program flow within a method:
 Variable definitions and assignments.
 Flow control (loops, calls etc).
 Printing
 Generation and checks.
 Error handling.
 Synchronization (wait etc).
The e Language


(cont’d).
Numbers, identifiers, operators.
Syntax:
 Basic blocks {}
 Statements ;
 Method parameters ()
 Etc.
The e Language

(cont’d).
Constraints:


Struct member used to define relations between data fields
for test generation.
Restrict the range of possible values of struct fields when
generating random test.
Struct house {
X: int;
Y: int;
Z: [small, large, xlarge];
Keep x == y ;
Keep z != large ;
Keep x > 5 ;
};
The e Language




(cont’d).
Packing: used for conversion of complex data
structures to/from bit streams to be sent
to/from the DUT.
Pack() and Unpack() are an integral part of
any struct. The user defines what will and will
not be packed.
Referenced structs will be packed as well.
Bit stream can be manipulated.
Specman. XOR example.





Specman has a built in test generator.
Input is a description of the architecture
elements.
Output are instances of those elements
assigned with “good” values.
No need to develop a generator.
Constraints are the way data relations are
described in e.
Specman. XOR example.

Describe signals to be applied:


a,b. Two bits wide. Any combination of 0,1
is legal.
Clock. Constant periodic waveform from
DUT.
a,b
Specman
Output, Clock
XOR DUT
Simulator
Specman. XOR Example (cont’d).

Defining an e structure for XOR module:
Struct operation {
a: int (bits: 2);
b: int (bits: 2);
results_from_dut: int (bits: 2);
};

Describes inputs/outputs/other meaningful
values together for clarity and reusability.
Specman. XOR Example (cont’d).

Define list of structs to contain values that
will later be applied to the XOR design.
extend sys {
ops: list of operation;
keep ops.size() <20;
};


Specman automatically generates values for
items in sys struct (Sys is a pre-defined top
level struct)
Values can be random with probability.
Specman. XOR Example (cont’d).

Defining a reference model.
check that op.result_from_dut == (op.a ^ op.b);

Creating a Specman event to synchronize to
the simulator clock.
event fall_clk is fall (‘xor_top.clk’)@sim;
Specman. XOR Example (cont’d).

Interfacing to the simulator.
Verilog task ‘xor_top.mon’ ();//referencing a Verilog task
Struct verify {
event fall_clk is fall (‘xor_top.clk’;)@sim;
verify_xor() @fall_clk is{
‘xor_top.mon’(); //calling a verilog task
for each operation (op) in sys.ops{
‘xor_top.a’=op.a;
‘xor_top.b’=op.b;
wait [1] * cycle;
op.result_from_dut=‘xor_top.out’; // sampling
print op;
Specman. XOR Example (cont’d).
check that op.result_from_dut == (op.a^op.b);
};
stop_run();
};
};
Extend sys{
verify1: verify;
};
Specman. XOR Example (cont’d).


Functional coverage shows how well the DUT was
tested.
Coverage of all variations of inputs a and b.
Extend operation{
//extending the operation struct for coverage
event done;
cover done is{
item a;
item b;
cross a, b;
};
};
Specman. XOR Example (cont’d).
Extend global {
//turning on collecting of coverage
setup_test() is also {
set_config(cover, mode, normal);
};
Application issues.




Most of DUT are more complicated then a
XOR function..
There is no way to test it using a high level
functions. The test must be in a resolution of
few controller commands.
There must be a way to write/read a
snapshot of the DUT and get indication of
progress.
Structures can be packed/unpacked.
Application issues



(cont’d).
There is a need to set the line between the
chip designer and specman programmer
responsibilities. There are few models:
The chip designer provides interfaces to its
design and all of it’s internal timing and
events.
The specman programmer interfaces to it in
order to test the DUT.
Application issues




(cont’d).
Advantage: The chip designer doesn’t have to put
more energy for the verification.
Disadvantage. The timing is a specman
responsibility and hence can create problems that
doesn’t really exist.
The chip designer provides interface modules
which are more high level.
The specman controls the test logic but
doesn’t affect the timing.
Application issues


(cont’d).
Advantage: The change of finding bugs that are
due to specman wrong timing is smaller. Each one
is responsible to its bugs.
Disadvantage. The chip designer has to design
additional modules. The specman programmer has
less control over the DUT. It is more difficult to
perform tasks that requires full control like indirect
access.
Conclusions.



Specman is a useful and powerful tool for
chips verification.
Uses e which is an intuitive programming
language. Not clear why is there a need to
re-invent the wheel though (use C++ concept
with new syntax).
e constraints programming is intuitive. Some
say it could be copied almost directly from
the specifications.
Conclusions



(cont’d).
Shorten testing and hence development time.
Reusability. There is a way to use debugged
specman objects that were used in previous
projects.
Since it is a common practice to reuse
internal modules when designing chips, each
module can be reused with its specman ready
module.
Conclusions


(cont’d).
Provides coverage statistics. A graphical
viewer is available.
Operatable in various testing methodologies
(I.e. compare to self generated results,
compare to other verified silicon, link with an
EDA module etc).
Conclusions

(cont’d).
Provided answers to:



How to generate the tests?
What tests should be generated?
How to verify the results?