Here I am going to blog about the practical as well as theoritical issues that today's ASIC verification engineer faces.
Monday, October 20, 2008
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
* 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
Labels:
ASIC,
extensibility,
High Level Verification,
HVL,
Languages,
modularity,
specman
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
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
Subscribe to:
Posts (Atom)