Strategy to monitor single signals

UVM
, ,
1

Hi,
Let`s say we have some interrupt signal that changes without any rules (no protocol).
This signal should be compared with the reference signal in the SB.
What is the correct way to monitor it ?

  1. every clock? using @(posedge clk) ?
    This way I feel I`m writing to much unnecessary transactions to SB.
  2. every change in the signal? using @(signal_x)
    This way seems to be unsafe.

Thanks

2

In reply to mago1991:

this is actually a good point. Generally speaking interrupts are managed using some EN register which are the cleared by HW. irrespective of this they are all clocked operation anyway. One solution could be:


  if(register.enable.value == '1) begin
    $display("interrupt enalble waiting for being served")
    fork
      begin: intwait
        served = 0;
    	wait(register.enable.value == 0); // Do not use empty function here
        served = 1;
      end
      begin: timeout
        // your timeout based on clk
        served = 0;
      end
    join_any
    
    // Exit
    if(!served) disable intwait;
    else 		disable timeout;
  end

Frankly in this solution you should carefully set up the timeout to a reasonable value.

alternatively an interrupt signal has a positive and negative edge so you could use:



wait(your_signal == 1);
$display("interrupt enable");
wait(your_signal == 0);
$display("Interrupt served");

or again simply use the:

  always @(posedge interrupt) begin
    @(negedge interrupt )
    // ...

a task into an interface will be useful as well. Regards

3

In reply to Rsignori92:

Hi Rsignori92, thanks for your response. What if we are not talking specifically about “interrupt” signal ?
let`s say we have some signal_x that change according to (in the DUT):
assign signal_x = (signal_y && signal_z);
while signal_y and signal_z change absolutely randomly.
What would be the preferred method of sampling and transmitting the signal to SB from monitor?

Thanks

4

In reply to mago1991:

Hi,
Let`s say we have some interrupt signal that changes without any rules (no protocol).
This signal should be compared with the reference signal in the SB.
What is the correct way to monitor it ?

  1. every clock? using @(posedge clk) ?
    This way I feel I`m writing to much unnecessary transactions to SB.
  2. every change in the signal? using @(signal_x)
    This way seems to be unsafe.
    Thanks

I believe it is useless to compare an interrupt signal in a scoreboard. If an interrupt has been detected you should start your interrupt routine to clear this interrupt. And also an iterrupt follows a certain protocol. But we might not be able predict the exact appearance time.

If you are looking to the change of single signals you can simply use SV assertions.
In general functional interfaces like buses etc. do not contain only exactly 1 signal. They have more and you have to evaluate all of them in the right way.

5

In reply to mago1991:

Such specific signals sometimes have kind of special behaviour. Let’s say boot signals which usually notifies you that the entire boot is accomplished properly. In this case your SCBD could implement a model which might do the same and then compare. Anyways I’m barely talking about special single signals.

For general purpose bits of a general data bus for instance i would suggest you using assertions to check if the behaviour matches. Usually if in the SCBD it means you are about to use it for checking (interrupts, special signals, or others) in a kind of model.

My approach is more about how crucial is that signal and how is gonna be consumed by the HW is input/output or reg. If output assetions might be enough if not really crucial. Regards

6

In reply to Rsignori92:

If you are using the factory registration macros uvm_component_utils (for uvm_components) and uvm_object_utils (for seq_items, sequences) you are making entries in the factory and you can retrieve the right objects from there. The factory also provides a mechanism to check if the component/object you are retrieving is the right one.

7

In reply to chr_sue:

Agree