Synchronizing DUT and reference model

UVM
1

I have a signal(A) from the DUT.
This signal(A) reacts to events happening in the DUT. It is pulled LOW when an event happens.Once the event is released it is held low for a configured time and then released HIGH.
I also have a reference model for REF_signal(A) which reacts to events from the transactions.
My checker looks at any change in DUT_signal(A) , REF_SIGNAL(A) and compares them.

There are sync delays(1-10 system clock cycles) in the DUT for the event to be synchronized. Hence the DUT_signal(A) goes low after the sync delay,whereas the REF_signal(A) reacts immediately to the event.
Is it better to
A) use a hard coded delay in my checker?
or
B) delay the event in my reference model and not use any delays in the checker ?
or
C) is there a better way of syncing the DUT and reference model?

2

In reply to Shyamsunder:
It’s hard to giver you an answer without more specific details about how your design works.

Generally, it’s a good idea to keep delay information away from your testbench/checkers, especially when the delay is an implementation artifact, and not a requirement. Once your testbench is at a transaction level of abstraction, clock cycle should no longer matter.

3

In reply to dave_59:

Thanks for the reply Dave. I am trying to implement an assertion for above situation and not use delays in my scoreboard.

I have the following assertion:


always @(posedge A)
       begin
            A= 1'b0;
            assert_property (signal_check) 
       end

property signal_check;
 @(posedge clk) ##[1:10] B === C;
endproperty

The assertion starts at posedge of A and then checks if C takes B’s value in 1 to 10 clock cycles.
My question is:
What happens to the assertion after it passes. Say C took B’s value in 2 cycles. Does the assertion stop and start again when there is a posedge on A ?

4

In reply to Shyam_093:

Do you believe your property is a good one? You are checking on each rising edge of clk if B is equal to C this might cause a lot of fails.
What is missing in your property is a pre-condition after that the checking starts.

5

In reply to chr_sue:

The property is asserted only at posedge of signal A. The pre-condition is signal A in this case.