yes we can but complexity would be nlogn where this solution is O(n)

there are multiple reasons, the first as you mentioned providing a arbitration for sequence request and grand. second, sequencer provide a hierarchical component for sequence, if you wanna pass some config setting, sequence can retrieve the seqr handler to config your transaction in running time. Then if you are trying to implement some complicate sequence like layer sequences, sequencer offer a convenient way to implement that.

@@kuangquan08 1. what do you mean by layer sequences? 2. I don't see why configuration idea is good unless that is runtime driver specific configuration (there are better uvm ways, imo for other configurations). Then, again, why don't use driver for that type of configuration? I believe arbitration argument is good other arguments not so much convincing.

yes "integer" data type has 4 states, where as "int" has 2 states.

Yes, it is possible to set the config db in a lower level and obtain it in a higher hierarchy. One way to prevent issues is to do config db set in an earlier phase in the lower level hierarchy and get it from config db in later phase.

Glad you liked it!

Yes, similar to UVM.

More to come! :)

Thanks

Glad it was helpful!

Hi Naseem, 1) Item done take a ref of the sequence item that has finished running. 2) Item done is typically called without an argument, when you call it from within the sequence item itself and is called with an argument when called from outside the seq item

More to come:)

Yes, it is a blocking call as it blocks the calling thread of execution until the test finishes.

It comes down to the diff between uvm components (drivers, scb, monitors, etc.) and uvm objects (transactions, seq items, etc). Uvm transaction / seq items are dynamic , transients and as thus their constructors only has name as an arguments whereas, components are static and exist throughout the simulation and their constructor has both name and hierarchy.

Glad it was helpful!

To put it simply, a P-sequencer (port-sequencer) is to drive transaction to a specific port interface on the DUT.

This exploit polymorphism, which are of uvm_sequencer_base class.

m sequencer does have any other handle(cannot add) and if you want some handle you need to go with p_sequencer pointer.

To put it simply, a P-sequencer (port-sequencer) is to drive transaction to a specific port interface on the DUT.

The end_of_elab phase is called after all of the TB components have been instantiated and connected, but before any simulation activity has begun, whereas, start_of_sim mark the start of the simulation activity like resetting, registers, DUT, etc

Virtual_seqeuncers add complexity to the TB, as you need to implement and connect both a virtual sequencer and a p_sequencer, also it has a little harder to debug because there is an extra layer of abstraction.

Early Randomization can result in the object being configured or connected in an inconsistent or invalid state. Take a testbench with a driver and monitor as an example. Both of these components have a configuration parameter that sets the largest transaction size they can support. The driver might be configured with a bigger maximum transaction size than the monitor if the driver and monitor are both produced at random with early randomization, which would prevent the monitor from correctly processing the transactions from the driver.

Keep watching

My pleasure

When a UVM class is created, its build phase is invoked after all of its fields have been initialized but before any simulation work has started. When ::type_id::create is invoked in a test the build_phase of the environment class will be called automatically as part of the process of instantiating the environment class.

Yes because response is from the DUT with update fields.

Yes , I have read it that its top down!!

It is a top-down phase

Hi Majji, the build phase is part of a series of phases like run, end of elab etc which helps in segregating instanton of tb components (typically in build)phase, the connection happen in connect phase, and so on. Whereas new() is used to construct an object without using the UVM factory. In UVM we typically use create() so that we can leverage factory. In conclusion, build is just a task which groups instantiations of various tb components/objects, whereas, new() or create() commands are used for instantiation. Check out the diff b/w new & create here --> kzbin.info/www/bejne/l3SQe2yHqrV_iaM.