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

5. 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?

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

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

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

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

12. The e Language (cont ’ d). 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); };

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

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

15. The e Language (cont ’ d). Numbers, identifiers, operators. Syntax: Basic blocks {} Statements ; Method parameters () Etc.

16. 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 ; };

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

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. SpecmanXOR DUT Simulator a,b Output, Clock

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

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

22. 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;

23. 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;

24. Specman. XOR Example (cont ’ d). check that op.result_from_dut == (op.a^op.b); }; stop_run(); }; Extend sys{ verify1: verify; };

25. 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; };

26. Specman. XOR Example (cont ’ d). 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 (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.

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

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

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

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

34. Conclusions (cont ’ d). Provided answers to: How to generate the tests? What tests should be generated? How to verify the results?