Scribd
Upload
80 views

Atomic Stimulus Generation Vs

The document discusses different techniques for generating stimulus sequences for verification: 1) Atomic stimulus generation generates individual transactions randomly but may not mimic real-world scenarios. 2) An atomic generator can base random values on previous transactions to create a related stream, but has trouble generating long sequences. 3) Randsequence allows describing transaction grammars procedurally but code is separate from transaction classes. 4) Randomizing an array of transaction objects allows constraints across the whole sequence and extracting global information before sending transactions. 5) Combining multiple predefined sequences can create more realistic overall stimulus flows.

Uploaded by

Sanjay Gowda
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
80 views

Atomic Stimulus Generation Vs

The document discusses different techniques for generating stimulus sequences for verification: 1) Atomic stimulus generation generates individual transactions randomly but may not mimic real-world scenarios. 2) An atomic generator can base random values on previous transactions to create a related stream, but has trouble generating long sequences. 3) Randsequence allows describing transaction grammars procedurally but code is separate from transaction classes. 4) Randomizing an array of transaction objects allows constraints across the whole sequence and extracting global information before sending transactions. 5) Combining multiple predefined sequences can create more realistic overall stimulus flows.

Uploaded by

Sanjay Gowda
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 8

Atomic Stimulus Generation

vs. Scenario Generation


Atomic Stimulus Generation vs. Scenario Generation

• We have learned how to make a single random bus transaction, a single


network packet, or a single processor instruction.
• But our job is to verify that the design works with real-world stimuli. A bus
may have long sequences of transactions such as DMA transfers or cache
fills.
• Network traffic consists of extended sequences of packets as you
simultaneously read e-mail, browse a web page, and download music from
the net, all in parallel.
• Processors have deep pipelines that are filled with the code for routine calls,
for loops, and interrupt handlers. Generating transactions one at a time is
unlikely to mimic any of these scenarios.
An atomic generator with history
• The easiest way to create a stream of related transactions is to have an atomic
generator base some of its random values on ones from previous transactions.
• The class might constrain a bus transaction to repeat the previous
command, such as a write, 80% of the time, and also use the previous destination
address plus an increment.
• You can use the post_randomize function to make a copy of the generated
transaction for use by the next call to randomize.
• This scheme works well for smaller cases but gets into trouble when you need
information about the entire sequence ahead of time. For example, the DUT may
need to know the length of a sequence of network transactions before it starts.
Randsequence
• The next way to generate a sequence of transactions is by using the randsequence
construct in SystemVerilog. With randsequence you describe the grammar of the
transaction, using a syntax similar to BNF (Backus-Naur Form).
• initial begin
• for (int i=0; i<15; i++) begin
• randsequence (stream)
• stream : cfg_read := 1 |
• io_read := 2 |
• mem_read := 5;
• cfg_read : { cfg_read_task; } |
• { cfg_read_task; } cfg_read;
• mem_read : { mem_read_task; } |
• { mem_read_task; } mem_read;
• io_read : { io_read_task; } |
• { io_read_task; } io_read;
• endsequence
• end // for
• end
• task cfg_read_task;
• ...
• endtask
• Example generates a sequence called stream. A stream can be either cfg_read,
io_read, or mem_read. The random sequence engine randomly picks one.
• The cfg_read label has a weight of 1, while io_read is twice as likely to be
chosen and mem_read is most likely to be chosen, with aweight of 5.
• A cfg_read can be either a single call to the cfg_read_task, or a call
to the task followed by another cfg_read. As a result, the task is always called at
least once, and possibly many times.
• One big advantage of randsequence is that it is procedural code and you can
debug it by stepping though the execution, or adding $display
state_x0002_ments. When you call randomize for an object, it either all works
or all fails,but you can’t see the steps taken to get to a result.
• There are several problems with using randsequence. The code to
generate the sequence is separate and a very different style from the
classes with data and constraints used by the sequence.
• So if we use both randomize() and randsequence, you have to master
two different forms of randomization. More seriously, if you want to
modify a sequence, perhaps to add a new branch or action, you have to
modify the original sequence code. You can’t just make an extension.
Random array of objects
• The last form of generating random sequences is to randomize an
entire array of objects.
• You can create constraints that refer to the previous and next objects in the
array, and the SystemVerilog solver solves all constraints simultaneously.
• Since the entire sequence is generated at once, you can then extract
information such as the total number of transactions or a checksum of all data
values before the first transaction is sent.
Combining sequences
• You can combine multiple sequences together to make a more realistic flow of
transactions.
• For example, for a network device, you could make one sequence that
resembles downloading e-mail, a second that is viewing a web page, and a
third that is entering single characters into web-based form.

You might also like