VERIFICATION METHODOLOGY

[ankit12345]

reference verification methodology

What are the advantages and disadvantages of queueing the input and then sending them one by one???

EX: In a Serial protocol.....
By generating the required num of packets with required feauters and then storing them in a queue.
the driver will take each packet and then it will send one by one.
this generation and queing is done in 0 time i think??????driving is specific to protocol.

The other methos is...........when ever a driver wants to send a packet ...................
it can generate the packet in 0 time and send it to dut according to protocol.

Which is the best one????
any other methodology for the driver part??????

 

[Zeng Jie-jun]

smart queue in vera

I don't think it's a methodology question.
The first case, memory space is required to store the data. but for second, not needed.
For verification protocol, these two are ok.

 

[anant]

disadvantages of rvm over vmm

you can also use mixed approach, method 1 + 2.

 

[viv_1005]

by queuing the input, you are storing the input for your reference. So, after the output is generated, you can use this input for verifying the result. You might require these inputs at various levels of execution, especially if you are doing white box testing.

 

[shahal]

I dont know much about queues. But there is a paper on "bits through queues." Its kind of a hard paper to understand, I am still working on understanding it for the past few months. Anyways, the paper talks about bits through queues and how you can have a capacity more than the channel capacity by spacing out the bits and your information is relayed in the time between the bits. Using this as an argument, you can see that the first option would be better than the second option.

By the way, any one interested in discussing bits through queues with me, I would really appreciate it. I can use all the help I can get to understand this paper. ITs available freely on the internet, just type "bits through queues" in google. I forgot the authors name, I think it venkant or something like that.

 

[mssajwan]

queues provides flexiblity due to their dynamic nature.
1. you can store data in them,
2. use them as you refernce data store
3. push data from front or back
4. pop data from front or back(it will delete the location)
5. get data according to index (it will not delete the location)

rest its on application where you can efficiently use it.

-Manmohan

 

[flypig]

but if the input is so big. the required memory is extra big. and which will reduce the compiler & simulation speed. you have to care about it for a verification methodology.

 

[gold_kiss]

Dear All,

What we normally do is have a seed fed to our testbench, and based on which we generate packets or stimulus using $random system function. The entire generation is done on the fly, we save on memory overhead but there is an overhead to generate on the fly.

Thanks,
Gold_kiss

 

[calm]

use mixed approach of key 1 and 2.

 

[vlsichipdesigner]

In the article, various verification methodologies are discussed.
https://www.vlsichipdesign.com/murphyslaw-coverageanalysis

 

[rama_unv]

ADV OF QUEUEING : By queueing the input, we can reduce the complexity of the driver.In this case driver can just work as per the driving protocol.
DISADV : For verification, I dont find any disadvantage in queueing trechnique.

 

[funzero]

you should build a flexible environment for verification and reuse

 

[polu]

Does anybody knew any link that educates on different verification methodologies and comparision by taking a core generic architecture as DUT.

 

[calm]

what is rvm and vmm?

 

[ankit12345]

these r methodologies frm SNPS.rvm for vera ans vmm for sv

 

[phoenixfeng]

it depends on you design spec.
if the design is slave ,so use methord 1
when it is master, use methord 2

 

[Ramesh Reddy]

Hi,

In Reference Verification Methodology (RVM) Which Uses VERA as language has Smart Queues which can be resized at any pint of time

Some times In such a situation, size() is likely to be a large integer value which creates a very large random SmartQ that will require a lot of simulation time to generate.

Thanks,

Bngaram.

 

[pintuinvlsi]

Method 2 is better and it will consume less memory and more randomize so simulation will be faster.

 

[anant]

method 2 is better. if it simulates back to back packet/frames.
other way is restrict the packet generation to small number say 50. This way packets will always be available to driver also will not consume much memory.

 

[skyfaye]

Using a queue to store your packets and let the driver drains them out is normally not an efficient, and also more complicated, then just driving the packets directly.

Here are the disadvantages of using queues to store packets
1) larger memory consumption
This means there is a finite number of packets you can store in your queue
you have to drain th out and release the memory occupied by those packets.
You will have to know the total memory available for your simulation, which will
vary, from simulation to simulation, because your total memory are shared by
other jobs, either on your own machine or a server farm machine. I guess you
can calculate the worst case number. If you run out of memory, you will get a
simulation run-time error.

2) increase testbench complexity
Now you have to put the packet in the queue first and let the driver drain it out.
You can just drive the packet directly onto the interface.

3) increase time before first packet comes out
Even though all the packets are created in 0 cycle, it still takes time.
Depending on your design size, packet size, and many other things, putting
100 jumbo packets in your queue can take minutes. Now if there's a
problem (testbench or design) that is revealed by the first packet, you
unnecessarily waited minutes to see the result. Typically, it will take at least
a few simulation runs to debug and fix the issue, which means you might
unnecessary wasting hours.

Advantages of using queue to store packets.
1) Easier to support preemption
Preemption is when you have multiple priority traffic and you need to preempt
a lower priority traffic, in the MIDDLE of the packet transfer, and transmit a
higher priority packet. Once all the higher priority packets are transmitted,
then continue where you left off with the low priority packets, this may be in
middle of the packet. There would be a discrete signal, for example, to
indicate what priority packet this is.

So to support preemption, you would have 2 queues, for example, for LO
priority packets, and a HI queue for high priority packets. You fill them up
with their corresponding type of packets, say at time 0. Your design may, for
example, normally gives higher priority to HI priority packets. So your driver
start draining the HI priority packets out from the queue. In the middle of the
HI priority packet, let's say, the DUT, wants to preempt the HI priority traffic
and now gives higher priority to LO priority traffic, then your driver should
stop draining from the HI priority queue, in the middle of the packet, and drain
from the LO priority queue. As you see, this is fairly easy to do.