Pages

Friday 26 April 2013

Some more Q&A on UVM from Doulos Webinar ,posted here in case anyone missed it
As mentioned earlier, this is a small repo from the interviews /seminars/training sessions/webinars  attended




Q: what is basic use of uvm
A: To capture best practice in verification IP reuse. UVM lets you build reusable verification components.


Q: why we use create method instead of new() in buitd_phase? can you tell the difference b/w them?
A: This is a factory method. It allows you to override the type of the object being created, whereas the type of the object created by "new" is determined at compile-time.

Q: Is the start_item() and finish_item() code embedded in the `uvm_do() and `uvm_do_with()?
A: Yes, that's right.


Q: what is ovm_test?
A: uvm_test is the base class used when creating user-defined tests in UVM


Q: is req is predefined object handle?
A: req is a variable defined in the base classes uvm_sequence and uvm_driver. It is just for convenience. You could use any variable.

Q: uvm support which language ?
A: UVM is written in SystemVerilog, but is intended to support mixed-language environments. You can mix SV with SystemC or e.



Q: Do we always need to create child sequence inside repeat loop?
A: No. This is just a simple example.


Q: what is this p_sequecer?
A: A pointer (reference) to the sequencer on which the sequence is running.

Q: what is the purpose of factory?
A: The type of the object created by the constructor "new" is fixed at compile-time. The point of the "factory pattern" (type_id::create()) is to let you override the type of the object being created at run-time.


Q: why we write if(starting_phase!=null) in pre_body??
A: Because the starting_phase property is not set by default, so we need to test it is non-null before dereferencing it (otherwise simulation will crash)


Q: What happens if 2 priorities are the same? Like seq3 with prio 2 and seq 2 also with prio 2?
A: Depends on the arbitration mode.


Q: Can I have one sequence running with different two sequencer at a same time ?
A: One sequence instance runs on one sequencer. You could have two different instances of the same sequence type running on two different sequencers (or the same sequencer)

Q: what is use of config_db?
A: To parameterize the UVM verification environment. In other words, to pass a set of resources into the UVM verification environment, usually in a top-down fashion.


Q: What is the use if uvm_declare_p_sequencer macro ?
A: It declares the p_sequencer variable, which gives a sequence access to the sequencer object on which it is currently running.

Q: In what scenarios a virtual sequence useful?
A: In order to co-ordinate the behavior of multiple sequencers in multiple agents connected to multiple DUT interfaces.

Q: can we instantiate child sequencers in the virtual sequencer and directly run child sequences on seqr0.seqr1 in the virtual sequence?
A: A virtual sequence instantiates child sequences, and then runs those child sequences, typically on some other sequencer.


Q: what is `uvm_rand_send?
A: Just a macro that randomizes a transaction object and sends it to a driver. (In effect, it does start_item...randomize...finish_item)

Q: How to use `uvm_do to run sequences inside the virtual sequences
A: would strongly advise you NOT to use `uvm_do until you are really sure what it is doing.

Q: So virtual sequencer is just a place holder for sequences?
A: You don't need a sequencer to run a virtual sequence, but you might choose to use a virtual sequencer if you want to associate other user-defined properties (variables) with the sequencer object.

Q: what happen if we don't use raise and drop objection while implementing sequence ?
A: The point is that the current UVM run phase will end when there are no objections raised. So the idea is that any UVM component or sequence that is "busy" will keep an objection raised until it is finished. Otherwise, the phase (and thus the test) may end prematurely.


Q: difference between start() method vs `uvm_do macros to start sequences?
A: I suggest you avoid `uvm_do until you understand what start() is doing. The `uvm_do macros can save you some typing, but at the risk of hiding what is really going on and making debug harder.

Q: why we use virtual sequence?
A: A virtual sequence co-ordinates the behavior of multiple sequencers in multiple agents

Q: what is background traffic
A: The ordinary stimulus being generated by a particular agent. A virtual sequence could then come along and interrupt what the agent is currently doing and start some other sequence.

Q: what is pre_do,mid_do and post_do explain me?
A: These are callbacks built into every sequence that can be overridden to change its behavior without needing to modify the source code of the sequence itself (for better reuse)



Q: can i write functionality of DUT in sequence?
A: Think of the sequence as generating stimulus, not as describing the expected behavior of the DUT

Q: what happen when sequencer already processing any sequence and virtual sequencer called lock?
A: lock stops the sequence items already being processed until the sequencer is unlocked


Q: what happened if a sequencer is already executing a transaction and we try to do a lock on that from the virt sequence
A: That's the point of lock! The currently executing transaction are suspended until the sequencer is unlocked.


Q: can multiple driver use 1 sequencer ? how?
A: Probably a bad idea. You want to start with one driver connected to one sequencer. If you want to split or merge transaction streams, you would probably use layered sequencers.

Q: so if virtual sequences don't run transactions, then what goes through virtual sequences? and why to use them?
A: Virtual sequences run sequences on other sequencers in order to coordinate the behaviour of those sequencers.

Q: what if there are 2 seq that use the grab?
A: That is exactly what was described in the webinar. The most recent grab goes to the front of the queue, the most recent lock goes to the back of the queue.

Q: why pre_body and post_body is not called in child class?
A: pre/post_body are not explicitly called in user-defined code. They are callbacks that can be overridden by the user. UVM calls pre_start - pre_body - body - post_body - post_start.

Q: the most recent lock has priority? shouldn't it be the oldest lock that has priority?
A: Yeah. That's how UVM works ;-) The most recent grab comes first, then the previous grab... then the oldest lock, then the next-oldest lock, and finally the most recent lock.

Q: If I want to connect a driver directly to the monitor, without using an interface, can it be done?
A: Sure, they are just objects in a SystemVerilog program, but connecting the driver to the monitor directly is usually considered bad practice (because you want the monitor to monitor what ACTUALLY happened, not what you THOUGHT the driver was doing)


Q: what is better to create different test sequence or different tests?
A: Whatever you want. In practice you would always have multiple tests, which could run the same or different sequences.


Q: Where is this code goes(creating library of sequences)?
A: Either in the run_phase method (or a sub-phase) of any uvm_component, or in the body method of any sequence.

Q: all the sequences in the uvm_sequence_library have to be running on same sequencer?
A: Yes, in effect, because a sequence library IS a sequence running on one sequencer.

Q: how do we suspend a sequence if and intruppt is generated and again resume the sequence from the same point after ISR
A: Any existing traffic (sequence items) will be suspended while the sequencer is locked, and resumed when it is unlocked. It is up to you to make it all work properly and consistently. UVM has no built-in machinery that understands the concept of an ISR.

Q: how do we suspend a sequence if and intruppt is generated and again resume the sequence from the same point after ISR
A: Any existing traffic (sequence items) will be suspended while the sequencer is locked, and resumed when it is unlocked. It is up to you to make it all work properly and consistently. UVM has no built-in machinery that understands the concept of an ISR.

Q: What is sequence layering in UVM?
A: Having multiple sequencers layered one above the other.

Q: How different is UVM from its parent OVM?
A: The first version of UVM was OVM with the characters "ovm" replaced by "uvm". Since then, UVM has been diverging from OVM with many new features added and existing features deprecated.

Q: in the examples that ship with UVM, the feedback to the sequencer is done via a TLM peek port, would recommend using the RSP item instead?
A: Good question. There are several ways to build the interface between sequencer and driver. We are focusing here on the req/rsp mechanism, but not strongly recommending it as the best or only solution. This is still a point of discussion in the UVM community.

Q: what is difference between pull driver and push driver? when they are used?
A: just use the pull driver.

Q: what does 'finish_item' do?
A: The second part of the handshake between sequence and driver.

Q: how do we suspend a sequence if and interrupt is generated and again resume the sequence from the same point after ISR

A: Any existing traffic (sequence items) will be suspended while the sequencer is locked, and resumed when it is unlocked. It is up to you to make it all work properly and consistently. UVM has no built-in machinery that understands the concept of an ISR.

Q: what does start_item actually do?
A: Waits for the driver to call get or get_next_item, then returns.

Q: How to form nested packets(nested packet is one packet is part of another packet) in transaction class?
A: Either with nested sequences (parent and child sequences as we showed in the early slides) or layered sequences (as we are showing now)
Audience Question

Q: Response that we get back from the driver to sequencer is the same response which is responded by DUT ?
A: Yes and no. The interface between the DUT and the driver is at the pin level, representing the hardware interface to the DUT. The interface between the driver and sequencer is transaction-level, but in theory should represent the same information (abstracted) as the pin-level interface


Q: If you were to implement a "slave" protocol witht he REQ/RSP mechanism, would you need to send a "ready" req, which essentially sits at the driver until a read fromt he master occurs on the interface? the RSP then goes back, and triggers a data item from the appropriate sequence?

A: That sounds reasonable. I guess the point is that the driver can only send the response object when it has all the information it needs to populate the object.
Audience Question

Q: What are some scenarios to use responses in sequences?
A: Any protocol in which there is a response, e.g. the data passed back from a read command, or status information passed back from any command. The alternatives would be to overwrite fields in the request object or use the path through the monitor component.

Q: if there are layered monitors or drivers,there is same generation of req and res?
A: The req/rsp mechanism is only built into the transaction-level interface between the driver and sequencer.

Q: why do you call req.randomize() after start_item? shouldn't req be ready when the driver gets it?
A: You need to understand the concept of late randomization. The whole point of the start/finish_item handshake is to delay the randomization of the transaction object until the last possible moment before releasing it to the driver.

Q: I just want to ask is there any method which we can call depending on some set of events .. as i dont want to change my sequence i just wasnt to pause it and after somtime resume it... but not by fixing delay but dependent on set of events

A: There are all sorts of ways in UVM of making components or sequences dependent on events. The point I am trying to make is that there is no clean, build-in solution to deal with the ISR scenario.

Q: through sequence library can we able  to generate multiple irun.log files for different sequences being executed?
A: No, the two concepts are unrelated.



Q: Am not too sure if sequences can be blocking...?
A: Sequences are inherently blocking: they consume time.


Q: what is need of objection mechanism
A: In order to co-ordinate the end of the test. The test should only end when each and every verification component has finished whatever it was doing.


Q: difference between sequence randomization and transaction randomization?
A: Sequence randomization randomizes the rand fields of the sequence object, transaction randomization does the same thing for the transaction object


Q: what is use of UVM_config_db?
A: To parameterize the UVM verification environment. In other words, to pass a set of resources into the UVM verification environment, usually in a top-down fashion

Q: in a layered stack what would be ideal functional call used in translator sequence and driver
A: Just the regular calls, nothing special. I suggest you download and study the examples.

Q: what if we do randomize both sequence and transaction randomize?
A: Then you randomize both the properties of the sequence objects and the properties of the transaction objects. Sequences generate sequences of transactions.


Q: i.e for driver should we use get() or get_next_item or try_next_item()
A: Depends on all sorts of issues within the verification env you are creating. Any or all may be appropriate. get() blocks, try_*() does not block.


Q: wht is the purpose of `vm_object_utils
A: To register the class with the factory. Always, always use `uvm_component_utils or `uvm_object_utils for components, transaction, and sequences respectively.

Q: How are virt sequences and sequence library different?
    What are the use cases where they are used?
A: A virtual sequence is used to co-ordinate the behavior of multiple agents driving multiple DUT interfaces. A sequence library selects from a set of sequences to run on a single sequencer (which could be virtual or not)

Q: How are virt sequences and sequence library different? What are the use cases where they could be used?
A: A virtual sequence is used to co-ordinate the behavior of multiple agents driving multiple DUT interfaces. A sequence library selects from a set of sequences to run on a single sequencer (which could be virtual or not)


Q: In the UVM phases what is this top_down & bottom_up execution? can throw some light onit?
A: Sure. Certain phases (e.g. build_phase) are executed top-down (starting at the top of the component hierarchy). Other phases (most of them) are executed bottom-up starting from the components at the bottom of the component hierarchy.


Q: how the virtual sequencer/virtual sequences be useful ina layered protocol?
A: You would usually start thinking of layered sequences in the context of a layered protocol, not virtual sequences


Q: why do we use run_phase(uvm_phase phase);here need of uvm_phase phase
A: That's just the way the UVM class library has evolved. The phase argument is used to raise and drop objections.


Q: in a layered stack e.g tcp -ip stack. I was confused whether there is need of any layered monitors to pass info back or even of anlaysis. I was thinking will be good to pass application data to from application layer to scoreboard as stimulus using sequence or shud be passed all the way to the pins and monitor read it and its passes all the way up to the stack again in reverse order through layered monitors and then to scoreboard
A: Great question! The UVM community are still discussing the best way to do this. Layered monitors make perfect sense. When layering agents, you may need to use the UVM factory to replace individual drivers or monitors in higher layer agents






No comments:

Post a Comment