My purpose is always to learn. The thoughts I represent below originate from my own thinking. Obviously there is no guarantee of correctness. I would be grateful if you point out to something that is incorrect, as that will definitely enlighten me. Also, any comments that help me as well as other readers to learn are most welcome
ASIC verification is the most time and effort consuming activity in the entire ASIC cycle. We used to discudd a lot on what essential functionality a verification environment should have.What follows is just thinking aloud regarding this topic.
To verify/test any module, one needs stimulus, an expected reference output that the DUT is supposed to produce, mechanism to read the actual DUT output and a mechanism to determine if the DUT output is correct or as expected. This is a broad level picture. If there are 3 inputs, say, one can have 8 combinations, 8 predicted outputs, 8 DuT outputs, 8 comparisons, and the test suite is done! Life with complex ASICs is of course not that simple. (Had it been, there would be no verification engineers! ;) )
The number of conditions for which the DUT needs to be tested are millions. The number of test cases can blow up enormously, so much so that it becomes unmanageable.
It is important to clearly define features and action-response in the specification, and categorize the features cleanly. This facilitates modeling te DUT behavior precisely and accurately. Use of automated checkers for functionality that is repititive, common or driven by standard can be effective. For example, if it is expected that there should be a minimum of 300ns of interval between two frames, then the environment should have a built in checker for this feature. For every test case run, it does not make sense to check this explicitly
The stimulus generation also can be modular. The generation of stimulus of a certain category should be independent of generation of stimulus of other categories.
To put it in the words of my good friend Nitin Kulkarni, a verification environment should effectively represent an instrument where iy provides the users with knobs, which the user can just tweak to generate test cases. He had stated this during a training of specman he had given us. It kind of lit the bulb immediately in my head :). (Understanding the idea behind something very clearly teaches you much much more than thousand pages of tutorials and ppts.)
Languages like e and SV and methodologies like eRM and OVM/VMM make life much easier for us with the support for randomisation and object oriented approach. One only needs to understand the need, the requirement and then choose and learn implementation methods that comply with the need.
My two cents..
ReplyDelete1. All these methodologies are meant for REUSE of most of verification components. This help to churn out different configurations of verification environment quickly. I think this is most important thing when time to market is shrinking which is also reducing ASIC lifecyle time.
2. Also randomization achieved using these HVLs is very useful to verify complex Chips. It will be really tough to write directed test cases or even think of all scenarios without help of HVLs
3. EDA companies are now a days promoting lot of tools which will help verification engineer to link their specification -> coverage plan -> actual coverage. There is also effort to automate some part of test case generation by looking at functional coverage holes
Sagar,
ReplyDeleteThank you very much for putting this down.
Reuse is indeed a very important aspect.
on this note, let me quickly mention that reuse has 2 aspects, one is reuse within the modules/stages for the same ASIC and reuse across ASICs.