hi,
i have a interface with two signals 1 is clock and another is a 60bit wide bus both of these signals are connected to dut through assign statement.bus value changes at posedge of clock always but when i am sampling the value at posedge its taking value just before posedge not the new value. can anyone suggest whats the solution for that.
thanks
In reply to pawan:
See my reply at
https://verificationacademy.com/forums/systemverilog/sva-evaluation
In general, you do want the signals to be sampled in the Preponed region.
If you want the current value, see my comment #2 in that link
*If within the sequence-matched-item, I update my property local variable with the return of a function call, like (1, w=getq()), that call is made in the Observed region, past the Active and NBA regions. Thus, in this model (below) w gets the updated value of q. 390 sampled q= 25, current q= 25, past q= 8, var w= 31
*
I suggest you reevaluate your needs and review the evaluations regions.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr
In reply to ben@SystemVerilog.us:
You can use clocking blocks on the interface and give delay offset on those signals.
In reply to prashanthiyer90:
In reply to ben@SystemVerilog.us:
You can use clocking blocks on the interface and give delay offset on those signals.
how still it samples in prepone region. basically for my design bus value is x and it changes on the posedge i want my testbench to get same value.
In reply to pawan:
The reason the sampling is in the Prepone region is because this is when all the signals are steady, just before being clocked.
Consider a posedge of clk at time t, and a 10ns clock.
Question: When do you want to do you verification? at time t+delta time, or t+1ns? or t+ 6ns?
The answer is NO, you want to do your tests JUST BEFORE the clocking event , in the Prepone region.
Another example: You go to a restaurant. You want a steak (the Prepone region).
What do you want to test as to what gets selected for the next transaction? The steak or the fish? It’s the steak, of course, because that decision gets modified in the next time frame. The assertion for this would be
ap: assert property(@(posedge clk) steak |=> fish);
It’s the decision of the “steak” that causes the logic for the next stage (what gets cooked) to be the fish.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr
In reply to ben@SystemVerilog.us:
the signal is steady just at the edge of clock not before that since this is RTL there is no delay here. issue is i am not able to sample it just at the edge its taking a value delta before edge i want value delta after edge or just at the edge.
In reply to pawan:
In reply to ben@SystemVerilog.us:
the signal is steady just at the edge of clock not before that since this is RTL there is no delay here.
Sorry, but you are incorrect here. The signals are steady just before the clocking event.
After the clocking event, you have all these regions (like active, NBA)when the signal change values. There are many cases when, because the evaluation of logic is sequential in a computer, you would have zero time glitches in the Active region; in fact, this is why you have deferred assertions. Thus, your statement that the signal is steady just at the edge of clock not before is incorrect. How could it be unsteady “before”, but “steady” after?
After the clock, the signals change, and are steady in the Posponed Region. So, in which Region do you want to do your tests? Active, Inactive, Observed, NBAor Posponed?
If you can identify which Region you want to use, how would you write this? you can’t.
In the initial states, you may have Xs, and after the clock edge, it is steady. Your tests should start on a steady reset design.
issue is I am not able to sample it just at the edge it’s taking a value delta before edge I want value delta after edge or just at the edge.
Again, this is exactly what you want, the sampling in the Prepone region, just before the clock edge, and not a delta time after the clock edge. If you are worried about the Xs, your test should start on a steady reset system. You have assertion controls to turn you assertions ON/OF. Turn them ON on a steady system.
RTL simulation is designed to emulate real designs with delays and setup and hold requirements, even though you can run it with gates and FF with 0 delays. This is why you have the evaluation regions, don’t make up your own regions, you’re setting up for failure.
Think real designs. Review and understand the regions.
SVA evaluation - SystemVerilog - Verification Academy
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr
In reply to ben@SystemVerilog.us:
In reply to pawan:
Sorry, but you are incorrect here. The signals are steady just before the clocking event.
After the clocking event, you have all these regions (like active, NBA)when the signal change values. There are many cases when, because the evaluation of logic is sequential in a computer, you would have zero time glitches in the Active region; in fact, this is why you have deferred assertions. Thus, your statement that the signal is steady just at the edge of clock not before is incorrect. How could it be unsteady “before”, but “steady” after?
After the clock, the signals change, and are steady in the Posponed Region. So, in which Region do you want to do your tests? Active, Inactive, Observed, NBAor Posponed?
If you can identify which Region you want to use, how would you write this? you can’t.
In the initial states, you may have Xs, and after the clock edge, it is steady. Your tests should start on a steady reset design.
Again, this is exactly what you want, the sampling in the Prepone region, just before the clock edge, and not a delta time after the clock edge. If you are worried about the Xs, your test should start on a steady reset system. You have assertion controls to turn you assertions ON/OF. Turn them ON on a steady system.
RTL simulation is designed to emulate real designs with delays and setup and hold requirements, even though you can run it with gates and FF with 0 delays. This is why you have the evaluation regions, don’t make up your own regions, you’re setting up for failure.
Think real designs. Review and understand the regions.
SVA evaluation - SystemVerilog - Verification Academy
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr
There is nothing right or wrong here I am telling u how my design is behaving and wanted to know if there is a sophisticated solution for the same
In reply to pawan:
If you have issues in the setup and hold, and when signals are sampled, consider using clocking blocks. From my SVA Handbook 4th Edition
SystemVerilog also allows for the specification of input and output skews. Input (or inout) signals are sampled at the designated clock event. If an input skew is specified then the signal is sampled at skew setup time units before the clock event. Similarly, output (or inout) signals are driven skew hold simulation time units after the corresponding clock event. An example of a skew definition is shown below:
In reply to ben@SystemVerilog.us:
problem with clocking block here is as follows.
here is my interface
interface chkr_if();
bit clk;
logic valid;
logic [31:0] result;
endinterface
these 3 signals are connected to RTL using a assign statement.
at a clock edge if valid goes from 0->1 result goes from xxxxxxxx->correct_value.
my TB also calculates this correct_value and compares with the RTL. so for correct comparison i need to sample RTL value at posedge or just delta time after coz i dont want to sample xxxxxxxx. clocking block will help here ??
In reply to pawan:
Several points:
these 3 interface signals are connected to RTL using a assign statement.
Are you saying that withing the RTL you are doing this?
module top;
logic clk=1'b1, a=0;
logic [31:0] rsl=7, exp;
chkr_if ch_if() ;
assign ch_if.clk=clk;
assign ch_if.result=rsl;
assign ch_if.valid=a;
Typically, interfaces are connected to RTL as follows:
interface counter_if (input logic clk);
import counter_pkg::*;
logic[3:0] data_in;
logic ld;
logic[3:0] counter;
logic rst_n;
ct_scen_e kind_cp; // for debug only
clocking driver_cb @ (posedge clk);
output rst_n, data_in, ld, kind_cp;
input counter;
endclocking : driver_cb
clocking mon_cb @ (posedge clk);
input rst_n, data_in, ld, kind_cp;
input counter;
endclocking : mon_cb
modport drvr_if_mp (clocking driver_cb);
modport mon_if_mp (clocking mon_cb);
endinterface : counter_if
module top();
counter_if if0(.clk (clk) ); //instantiate ovc interface
// counter_max #(.MAX_COUNT(MAX_COUNT_TB), .MIN_COUNT(MIN_COUNT_TB))
// counter_max1(
counter_max counter_max1(
.data_in(if0.data_in),
.ld(if0.ld),
.counter(if0.counter),
.clk(clk),
.rst_n(if0.rst_n));
so for correct comparison, i need to sample RTL value at posedge or just delta time after coz i dont want to sample xxxxxxxx
Your XXXX change after the clok edge, and the evaluation of an assertion (SVA or other checks) is done when ALL THE SIGNALS settle. That time can be the Preponed region of the next clocking event, or the negedge of the clk (if the signals settle by them).
You keep on repeating and repeating the need to check just after the clock edge in the Active Region, and that is incorrect. If you are worried about the XXXX propagating, your checks should be done when things settle (no XXX0, LIKE after a reset). Really, you need to thoroughly understand this. Read my previous message, I explained that, even with the restaurant model. You cannot do checks just after the clocking event as the values are unstable at that time.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr