How to coordinate sequence and test objection

#1 raise& drop should be in pre+post body because those functions are ONLY called when the sequence is "started" (aka a root sequence). a subsequence doesnt call pre/post body and therefore doesnt work change the objection count. so as a rule of thumb you would have as much objections as you would have active root sequences. (reactive) sequences such as for slaves and background functionality do not need objections.

#2 if your sequences are non-blocking you got some options:

- first you could wait for the responses to appear after the final sequences have been send

- second you could use a drain time to let your simulation complete after all objections have been dropped

- you could also have the scoreboard, the monitor or driver raising objections to prevent your simulation to stop too early

#3 driver+monitor could have objections too, i see no issue in that some "component" says "please do not stop now"

#4 this is more work to add raise+drop to every sequence body it is simpler to do something like:

virtual class uvm_active_sequence #(type A,type B=A) extends uvm_sequence#(A,;
    // ctor
    function pre_body(); uvm_test_done.raise_objection(...); endfunction
    functionpost_body(); uvm_test_done.drop_objection(); endfunction
endclass

AXI Protocol

 Exclusive access process
:- The basic process for an exclusive access is: 1. A master performs an exclusive read from an address location. 2. At some later time, the master attempts to complete the exclusive operation by performing an exclusive write to the same address location. 3. The exclusive write access of the master is signalled as: • Successful if no other master has written to that location between the read and write accesses. • Failed if another master has written to that location between the read and write accesses. In this case the address location is not updated. Note A master might not complete the write portion of an exclusive operation. The exclusive access monitoring hardware must monitor only one address per transaction ID. Therefore, if a master does not complete the write portion of an exclusive operation, a subsequent exclusive read changes the address that is being monitored for exclusivity.


At some time after the exclusive read, the master tries an exclusive write to the same location. If the location has not changed since the exclusive read, the exclusive write operation succeeds. The slave returns the EXOKAY response, and the exclusive write updates the memory location. If the address location has changed since the exclusive read, the exclusive write attempt fails, and the slave returns the OKAY response instea

The exclusive access monitor records the address and ARID value of any exclusive read operation. Then it monitors that location until either a write occurs to that location or until another exclusive read with the same ARID value resets the monitor to a different address. When an exclusive write occurs with a given AWID value then the monitor checks to see if that address is being monitored for exclusivity. If it is, then this implies that no write has occurred to that location, and the exclusive write proceeds, completing the exclusive access. The slave returns the EXOKAY response to the master. If the address is no longer being monitored at the time of an exclusive write, this implies one of the following: • the location has been updated since the exclusive read • the monitor has been reset to another location. In both cases the exclusive write must not update the address location, and the slave must return the OKAY response instead of the EXOKAY response.



SLVERR Slave error is used when the access has reached the slave successfully, but the slave wishes to return an error condition to the originating master.

DECERR Decode error is generated typically by an interconnect component to indicate that there is no slave at the transaction address.

Write Interleaving :-
when multiple masters are connected, suppose master1 and master2 wants to perform a write transaction to the same slave then
Master1 with burst of 4 and Master2 with a burst 8

Master1 Master1 Master2 Master2 Master2 .. . Master1 Master1

which means that as the both the masters are accessing the same slave, when Master1 is in idle state during the transaction then interconnect will perform the Master2 transaction.

The write data interleaving depth is the number of different addresses that are currently pending in the slave interface for which write data can be supplied. For example, a slave with a write data interleaving depth of two that has four different addresses, all with different AWID values, pending can accept data for either of the first two pending addresses. The order in which a slave receives the first data item of each transaction must be the same as the order in which it receives the addresses for the transactions. Write data interleaving can prevent stalling when the interconnect combines multiple streams of write data destined for the same slave. The interconnect might combine one write data stream from a slow source and another write data stream from a fast source. By interleaving the two write data streams, the interconnect can improve system performance.


OUT of order transfer:-

"Out-of-order" is a term usually referring to slaves, not masters. Slaves can return read data in a different order to that the addresses were received (if the IDs are different), or they can return BRESP write responses at the end of the write data transfers, again in a different order to that of the addresses, if the IDs are different.

Masters can interleave write data to the 2 different slaves (where IDs are unique), but this would be done because the master has that data available, not because it knows a specific slave can accept that data. If this particular data happens to be for your slower slave, WREADY will be driven low from that slave to stall the master until the slave is able to accept that data, and this will stall all data transfers from that master.

However when designing the interconnect logic linking your master to the 2 slaves, and if you knew slave #2 was slow, you could implement some sort of write data buffer on the interconnect output port driving slave #2 so that the buffer fills up quickly with the master data, and then slowly empties at the slave's data rate, thus not impacting on the master..


Locked transfer and exclusive transfer :- 

UVM interview questions and answers

How many phases UVM has explain each :-

1. We call run_test (if you don’t remember, see the line 17 of the top module in Tasting), which in turn calls the run_test task of the uvm_root class.
2. The uvm_root calls the m_run_phases task of the uvm_phase class.
3. For each phase, the execute_phase task is called.
4. If the phase is a top-down or bottom-up phase, exec_func is called for each component.
5. For example, the exec_func calls the build_phase function of each component.
6. If the phase is a task phase, exec_task is called for each component.
7. For example, the exec_task calls the main_phase task of each component.
8. The uvm_phase checks if any objections are raised by the components. The phase_done is the uvm_objection object that the uvm_phase keeps track of the number of objections with. When we called phase.raise_objection() from inside the run_phase of the jelly_bean_test class (see the line 27 of the jelly_bean_test class in Tasting), phase_done.raise_objection() is called in the uvm_phase under the hood.
9. If no objection is raised, all the processes started by the exec_task are killed. In other words, unless an objection is raised, the phase is immediately killed!
10. The steps 3 to 9 repeat until all phases are executed.

Why Final_phase is toptodown();

The final_phase() exists in UVM only for arrangements which run multiple loops around run..extract..check..report phases in a loop and then jump back to run() for the next iteration of multiple concatenated tests. Support for this is only partially defined or implemented in UVM today and is unlikely to be widely used in the industry (I would not recommend it for any use model that I am aware of).
However if this technique is used, there is a need for a final_phase() which is guaranteed to be the last phase before simulation exits, unlike report_phase() which may loop back. Why top-down? If one used this looped multiple test arrangement, final_phase() would be used for any cleanup required outside the loop, and hence it is top down, to ensure control from the topmost level of your test environment of that multiple test loop

Why build phase and connect phase is top to down and bottom to up ?

The build_phase has to be top-down because the parent component creates the child components (not the other way around). It also allows the parent component to configure the child components. On the other hand, the connect_phase, for example, is bottom-up. It allows the parent component to verify that the child components are connected properly.

http://cluelogic.com/2014/08/uvm-tutorial-for-candy-lovers-phasing/

How objection mechanism works 

How virtual sequence and virtual sequencer works ?

What is new,create ,build ?

• The new function creates an object of jelly_bean_agent. It also creates the handles for uvm_analysis_port, jelly_bean_sequencer, jelly_bean_driver, and jelly_bean_monitor. However, these handles are null because we have not created the objects for them yet.
• The build_phase function creates the components mentioned above. We called new to create an object of uvm_analysis_port. However, we called create to create the other components in case we want to override the component type later.
• The create function asks the UVM factory to create an object. The UVM factory knows which component to create even if the component type is overridden. The factory (or to be precise, uvm_component_registry) will call new on behalf of you.

How TLM works ?