Monday, December 22, 2008

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.



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

Saturday, October 18, 2008

My experiences with HVL

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

Tuesday, October 14, 2008

Mindset of Verification Engineer

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