Synchronization of two different interfaces with two different clock domains in predictor

UVM
,
14

In reply to JA:

Here i present a very simple implementation of a delay. With this example the user can have adelayed copied version of the monitored transaction (A_xfer_delayed_class_var). The user can then call another specific write function where the prediction is done at the correct time.


class predictor_MODULE extends uvm_component;
   `uvm_component_utils(predictor_MODULE)
   
   //declare TLM port _monitor_A_interface
   `uvm_analysis_imp_decl(_monitor_A_interface)
    ....
	
    //DECLARATION
    A_xfer_t    A_xfer_delayed_class_var;
    event A_xfer_delayed_class_var_event;
    longint class_var_time_from_A_to_DUT_reaction_FUNCTION_A_ps;

    virtual function void write_monitor_A_interface(A_xfer_t A_xfer);
      class_var_time_from_A_to_DUT_reaction_FUNCTION_A_ps=A_xfer.interface_clk_period_ps*7+10;//defined 7clock (pipelines) + small 10ps of offset
 
      fork
          A_xfer_t     A_xfer_fork;
          $cast(A_xfer_fork,A_xfer.clone);   //DEEP COPY OF VARIABLE INSIDE THE FORK        
          begin
              #(class_var_time_from_A_to_DUT_reaction_FUNCTION_A_ps*1ps); //delay assignment 
              $cast(A_xfer_delayed_class_var,A_xfer_fork.clone);  //DEEP COPY OF VARIABLE INSIDE THE FORK to CLASS VARIABLE at the correct time
    	      ->A_xfer_delayed_class_var_event;
              write_delayed_custom(A_xfer_delayed_class_var);  //call prediction function at the correct time
          end
      join_none

    endfunction

    virtual function void write_delayed_custom(A_xfer_t A_xfer);
       //implement prediction at the correct time using other interfaces.    
    endfunction

...
endclass

You can also implement this using different input types, instead of “A_xfer_t” you can delay a “bit” signal. In that case you do not need to do clone but just assignments.

I recommend to define class_var_time_from_A_to_DUT_reaction_FUNCTION_A_ps as:

class_var_time_from_A_to_DUT_reaction_FUNCTION_A_ps=A_xfer.interface_clk_period_ps*7+10;

In other words, i recommend to use delays using clock_period variables (A_xfer.interface_clk_period_ps). That is because (normally) those delays or internal pipelines depends on the defined interface clock. So, if the clock period, for that monitored interface, is increased after some time, then you will still have a correct prediction.

Another considerations to take into account is what happen if there is a reset in the XFER. In that case, probably no delay would be needed.