UVM test, sequences, drivers ? where else can we raise objections, and what is the right place?
Another Question:
What is a pipelined and non-pipelined UVM driver?
In reply to n347:
All UVM components can raise and drop objection. In my training classes, I say “if the component is going to do something important, then it should raise an objection. After completing the important task, the component can drop the objection”. Having said that, it makes sense to have at least the test and the scoreboard raise objections.
Pipelined drivers: Take the example of AHB… At each clock there are multiple things are going on , the HADDR signal holds the address of the current transaction, the HWDATA holds the data from the previous transaction and HRESP may hold the response of an even earlier transaction.
If you are building this driver, you will have to manage the pipeline of transactions carefully in the driver so that you can drive different parts of these pipelined transactions onto the AHB interface.
In reply to n347:
UVM test, sequences, drivers ? where else can we raise objections, and what is the right place?
Another Question:
What is a pipelined and non-pipelined UVM driver?
You should raise/drop objection is in uvm-test, try to avoid raising/dropping objection in other components such as sequences, dirvers, etc as much as possible because your testbench may be uncontrollable.
For pipleline/non-pipepline, you can check the cookbook: Pipelined Protocols | UVM Cookbook
In reply to cuonghle:
I do not fully agree with your opinion. My project experience shows there might be scaenarios to use the objections in the sequence, but then only in the sequence.
The common approach is indeed to implement the objections only in the test.