Templates in e

Haven't you still used templates to create your Testbench infrastructure or Framework? I would suggest start using it.

I thought of writing a small blog on Templates and then found this article at Cadence's specman website, which is quite good in explaining the basics of Template and how it is better than Macros in terms of the ease of creation and usage.

There is also another good article which illustrates the power of templates using the Generic Scoreboard as example. I say 'generic' because the basic code for Scoreboard doesn't need to have the what transaction type scoreboard will act on. 'Transaction type' is added when you are 'extend'ing the scoreboard in your individual testbenches. This is great way to build your Testbench framework which in turn can be used to build the individual testbenches.

Macros in Vi:-

Macros in VI editor are very handy when it comes to quick modifications to a givenin a repititive fashion. Imagine you have a file which has a word "Loading" at the begining of every line in your fileand you want to move this word "Loading" to the end of each line in the file.
Then you can use 'map' command to create macros to get this done quick/smart way.In the VI command line just use

: map z /Loading^M^[yw$^[p

The above macro searches for "Loading" and then copies that word(yw) and goes to end of the line ($) and paste the word there using 'p' command and once the macro 'z' is created you can simply use this as a command in normal mode of the VI and each 'z' command will do this for a line.
To carry out this repetitively for n number of lines another macro called "rep' can be created

:map rep zzzzzzzzzzzzzzzzzzz

To execute macro for only the 'n'th line

: map ten 10z

More VI tricks next time...until then enjoy this VI trick

Design Engineer, Verification Engineer and the Gap

Its often said that there is generally a 'gap' between Design Engineer(DE) and Verification Engineer(VE). Initially I always thought that Verification Engineer's knowledge about the design is limited and that's what is called as 'gap'. However, later I came to know that this gap is not all that bad and could have be both positive as well as negative shades.

By positive, I mean that VE can have his doubts about the design implementation or in some cases design(w.r.t Specification) itself and hence he won't be under the influence of the DE. This could really work out in favour of VE in most cases. Just to support my viewpoint, other day when I was talking to a DE, he told me that there is a *new* VE in his team who is able to find good number of bugs to his surprise and he also said this was possible because that VE doesnt know much about the protocol or design and he is able to hit the cases which were thought as invalid or illegal(though they are not). This new VE unknowingly brought the paradigm shift in the way verification was done.

The ability to question the 'status-quo' in this case is quite predominant because the new VE is not biased by the Designer's viewpoint or perspective.

This 'gap' also has negative shades since this curtails the VE's decision making progress in the course of verificaiton especially during debug. Generally VE starts on a 'debug journey' whenever a Testbench reports error; once its confirmed that its not a TB issue, then VE's thought/debug processes branches out in multiple directions and in the process he ends up making a decisions based on his previous experience or knowledge about the design. The path he takes could lead him to a bug or nowhere depending on how good the decission is. In order to make a good decision, depth of understanding of RTL/design will help in a big way. However, the real quality/ingenuity of the VE will be tested and how much unbiased/independentness he shows in making that decision will decide the fate of debug.

Generally in these cases, I have observed that VE being 'tenacious' can make a huge difference at the end. VE can be easily overriden by hugely experienced DEs( not necessarily good DEs) and this is where Management's role come into picture. If the issues is such that its neither concluded a design bug nor an issue which can be ignored, then management should always back the VE and ask DE to help out in debug till its root-caused.

Asking right questions to DE could be one of the ways through which VE can gain confidence. Some of the questions could be like these:-

1. I found this in specifications/standard and I see that this is not taken care ..what's your take on this?

2. I found that one block(A) in the design supports this functionality whereas same functionality is broken in other block(B). How can this be?

3. I happen to hit upon a illegal case but I didn't find in the documentation that after this illegal condition what is the intended behaviour by design ?

4. This implementaiton is well within what is specified by standards, However, I see that its not inline with the design intent based on design documentation. Is this correct?

This list can be really long and I am deciding to stop here. In my next blog, I would like to share what kind of questions a VE can ask himself ( about the Verificaiton Infrastructure).

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

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!!

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.

 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

Interview Questions