|
SystemVerilog emerged a few years ago and has gained phenomenal popularity ever since. Today this language seems to be ubiquitous and all 3 big EDA vendors keep pushing it forward. Whether this is good or bad is an interesting question, but one thing is certain - if you consider yourself a modern verifier, you'd better get familiar with SystemVerilog unless you want to stay in the dark.
|
|
|
VMM ships with some pretty useful built-in components and applications. VMM''s Atomic Generator is probably one of the most powerful ones, yet it''s pretty basic. It can definitely help you generate a flow of random items but it was not intended for generation of sequences. A sequence (a.k.a scenario) is a set of items that have some sort of correlation between them. For example - a set of 10 transactions with incremental addresses, or a set of 3 packets where the first one is always short and the last one is always long.
|
|
Here's a short tutorial on how to implement a default behavior for your BFM using VMM.
Some protocols require constant activity on their interface even when you don't have any data to transmit. This means you must have a mechanism that drives idle packets or dummy data items as long as the generator doesn't produce items for its BFM. In VMM, Generators are connected to BFMs using vmm_channels and we''re just about to show you how to take advantage of that for our needs.
|
|
|
Everybody likes atomic generators. If you have a vmm_data class, all you have to do is add a quick macro line and you get a free VMM-compliant generator that you only need to instantiate in your environment. An atomic generator is a simple yet powerful means to create a continuous flow of random data items to your DUT (more accurately “ to your BFM). Once everything is hooked up, all you have to do in your test program is set the number of items you want to generate, or let it run endlessly.
|
|
Constraints are our best friends when it comes to random generation. They allow us to limit the range of possible scenarios/values as much as we like, from the level of "everything is allowed" down to the level of such heavy constraints that really imply a very directed scenario. In most cases what we want to is to have a set of default constraints that give us a nice distribution of scenarios and values. We will then need to override the default set in some of our test cases by applying additional constraints, or reshaping the distribution or even removing previous constraints. SystemVerilog does not support advanced manipulation of constraints as much as e does (for example look up soft constraints and reset_soft() in e) but combined with some simple tricks that we''re going to show you here, you can get most of the things done quite easily:
|
|
|
|
|
|
|
Page 1 of 4 |
Tutorials
