Specman.

1
Specman.

• Presented By Yair Miranda

2
Presentation Topics.

• Testing micro controllers.
• The specman tool.
• Overview.
• The e Language.
• XOR example.
• Application issues.
• Conclusions.

3
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.

4
Testing Micro Controllers (contd).

• 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?

5
Testing Micro Controllers (contd).

• 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?

6
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.

7
Specman Overview (contd).

• 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).

8
Specman Overview (contd).

• 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.

9
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.

10
The e Language (contd).

• Strongly typed language. User defined and
  predefined types.
• Predefined Integers, bytes, bits, Boolean,
  strings.
• User defined Enumeration types.
• type color red2, green7, blue100
• Complex types Lists, structs.

11
The e Language (contd).

• 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.

12
The e Language (contd).

• 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 (i3)

13
The e Language (contd).

• Macro and defines.
• define offset 2
• define multiply_I_J ij
• Methods
• Methods are struct member.
• Used to perform operations.
• Predefined or user defined.
• Nesting is valid.

14
The e Language (contd).

• 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).

15
The e Language (contd).

• Numbers, identifiers, operators.
• Syntax
• Basic blocks
• Statements
• Method parameters ()
• Etc.

16
The e Language (contd).

• 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 gt 5

17
The e Language (contd).

• 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.

18
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.

19
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.

Specman
XOR DUT Simulator
a,b
Output, Clock
20
Specman. XOR Example (contd).

• 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.

21
Specman. XOR Example (contd).

• 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() lt20
• Specman automatically generates values for items
  in sys struct (Sys is a pre-defined top level
  struct)
• Values can be random with probability.

22
Specman. XOR Example (contd).

• 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)_at_sim

23
Specman. XOR Example (contd).

• Interfacing to the simulator.
• Verilog task xor_top.mon ()//referencing a
  Verilog task
• Struct verify
• event fall_clk is fall (xor_top.clk)_at_sim
• verify_xor() _at_fall_clk is
• xor_top.mon() //calling a verilog task
• for each operation (op) in sys.ops
• xor_top.aop.a
• xor_top.bop.b
• wait 1 cycle
• op.result_from_dutxor_top.out // sampling
• print op

24
Specman. XOR Example (contd).

• check that op.result_from_dut (op.aop.b)
• stop_run()
• Extend sys
• verify1 verify

25
Specman. XOR Example (contd).

• 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

26
Specman. XOR Example (contd).

• Extend global
• //turning on collecting of coverage
• setup_test() is also
• set_config(cover, mode, normal)

27
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.

28
Application issues (contd).

• 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 its internal timing and
  events.
• The specman programmer interfaces to it in order
  to test the DUT.

29
Application issues (contd).

• Advantage The chip designer doesnt have to put
  more energy for the verification.
• Disadvantage. The timing is a specman
  responsibility and hence can create problems that
  doesnt really exist.
• The chip designer provides interface modules
  which are more high level.
• The specman controls the test logic but doesnt
  affect the timing.

30
Application issues (contd).

• 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.

31
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.

32
Conclusions (contd).

• 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.

33
Conclusions (contd).

• 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).

34
Conclusions (contd).

• Provided answers to
• How to generate the tests?
• What tests should be generated?
• How to verify the results?