learn-verification

When should you use a 'struct' and when 'unit' in Specman?

2011-12-07T04:09:00.000-08:00

This is the question that I have asked most people in interview (including the engineers who claimed to know about specman). I didnt get satisfactory answer.

If I have to give analogy of a computer, think of 'unit' like a hardware and 'struct' like a software. Unit has to be tied to a physical entity and solely dedicated to that physical entity (like a port) . For example, you will unit to code your BFMs and Collectors. However any item say a 'packet' or 'frame' which you need to generate has to be 'struct'.

'Struct' isn't tied to any physical entity. any component can use the struct. For example, same packet 'struct' is used by many Port (BFMs and Collctors) to process/send/receive the packet or frame.

Lot of people give reasons like they will use 'unit' because they need 'tcm'( or notion of time). However this is only secondary reason behind using unit. Primary reason for using 'unit' should be whether the functionality which you want to implement is tied to physical entity or not.

Beware of conditional constraints!!

2008-12-22T07:14:00.000-08:00

I was impressed by conditional(implied) constraining of specman unit's fields. But that impression didn't last longer. It costed me ONE day and night to realise and convince myself about the issues with implied constraints.

C:\Documents and Settings\bkumar1\Untitled.html


 1  unit xyz_u {

 2

 3    field_A: uint;

 4    keep soft field_A in [1..4];

 5

 6    field_B: uint;

 7    // ************* COMMENTS ***********************

 8    // I wanted here fieldB to have 1 when fieldA =1;

 9    // fieldB = fieldA/2 if fieldA != 1

10    // you know what, it yielded me results 

11    // when filed_A = 4 it gave me field_B = 1

12    // that is becuase when field_A !=1,   

13    // this could be becuase the constraining can

14    // happen both the ways RHS to LHS and vice-versa

15    // and also specman never assures that it will

16    // satisfy both the below conditions. Specman 

17    // only **tries**  to generate the value which

18    // satisfy below equations.

19    // It may not satisfy always. 

20    keep field_A == 1 => field_B == 1;

21    // since this is implied constr. you can't use 'soft'

22    keep filed_A != 1 => field_B == field_A/2;

23    // this is very very dangerous

24  };

25

* what is the Real problem?
Specman doesn't give any hint or information as how it has generated and what conditions(equations) are really satisfied. It keeps the user in *dark* and doesnt really help the user to debug in anyway.

* what is the way out?
1. Look out for ways to avoid the conditional constraints.
2. Try to avoid negative way of implied constraining ( !=), it opens up the space for specman to play with the conditions.
3. Suppose if you can't get rid of the implied constraints. Try to break it up( I am not sure whether it works out well!!!)

All about Garbage collection

2008-10-20T08:57:00.000-07:00

Interview Questions

2008-10-20T08:22:00.000-07:00

Effective utilisation of sequences for constrained random generation

2008-10-20T08:21:00.000-07:00

Order of fields' declaration in specman

2008-10-20T08:17:00.000-07:00

My experiences with HVL

2008-10-18T10:57:00.000-07:00

As today's seminconductor designs are becoming complicated. Complexity in verification of those designs are multiplying. so engineers envisaged High level Verification Languages(HVLs) to attack this problem. HVLs provide modularity, re-usability and extensibility and some of those even provide (aspect-orientedness) to verification infrastructure or commonly known as 'Testbench'. Now verification managers/engineers have variety of HVLs to choose from which is actually tough task because it has to be very custom and very much dependent on nature of design and verification requirements. I will stop here on this topic and I will try to list down the my experiences (which are actually features of HVLs) with specman in particular and HVLs in general.

* Specman basics are easy to pickup for those who are exposed to any kind of Programming Languages but user has to acquainted with this 'thread' business a lot. Basically handling of threads.
* When switched from Verilog based testbenches to Specman based testbenches you kind of feel that you are hands are getting tied because specman demands you to be lot of more disciplined in organising your code.
* Specman (or HVLs) provide this 'extensibility' which provides lot of flexibility to verification engineers. Verificaiton infrastructure can be expanded/upgraded/degraded very easily because of this.
* Sequences is another powerful construct provided in specman which gives user to create 'unthinkable' scenarios and helps to get to the 'coverage goal' far more quickly than otherwise.
* Another important thing is that we can actually build some kind of inter-communicating infrastructure of specman agents to streamline the functioning of the various verification components. Like inheritance is very affective in creating agents which has common baseline.

coming to limitations of specman tool
* memory management or popularly known as 'garbage collection' . Lot of times tool crashes becuase of this screwups in garbage collection for right and wrong reasons. I say wrong reasons here because the way the test/testbench is written also will sometimes create garbage collection issues.

I will write more on this in my coming blogs. stay tuned

Mindset of Verification Engineer

2008-10-14T10:26:00.000-07:00

I was initially not so concerned about this topic, but as I travelled enough as ASIC verification engineer, I started realising that this(mindset of verification engineer) means a lot.

Why is it so important? If verification guy can't, there is a high chance that nobody will reach that bug's territory. verification is the right guy because he has the right arsenal to go and attack it.

Verification Engineer should have following traits
1. Attention to design details
2. Double checking on checkers' implementation
3. Always aware of simulation performance
4. Not getting biased by Designer's colorful talks
5. Express Doubt every bit of design.
6. Ask questions like how do I improve my verification environment