Hi All,
I am trying to write a SVA for property_expression : $fell( siga_ ) |-> ##[dyn1:dyn2] seq_exp; // where dyn1 = 3 and dyn2 = 5
Here is my attempt
The seq_exp is checked thrice . Once at time:35 ( after ##dyn1 ) , second at time:45 ( after ##(dyn1+1) ) and 3rd attempt at time:55 ( after ##dyn2 )
However the assertion doesn’t fail at T:55 ( after ##dyn2 ), it rather fails at next clock at T:65 ( due to expression: (vdiff >= 0) being false )
If I were to write $fell( siga_ ) |-> ##[3:5] seq_exp; the assertion fails at T:55 as per expectation.
Any thoughts / suggestions on how the results could match ?
Note: The same issue exists when dyn1 and dyn2 are both 0. The assertion fails at time:15 instead of time:5
Considering that the query is clear to the specific person to whom the question was meant for, I would say I have provided sufficient info.
The edalink provides flexibility to add code as per requirement so you are free to do that.
Ben ,
I believe the expression ( vdiff >= 0 ) is required for scenarios where dyn1 == dyn2.
Due to (vdiff >= 0) the subsequent sequence is evaluated at same time as dynamic_delay(dyn1) completes.
In your edalink using ( vdiff>0 ), if I were to provide stimulus as :
Instead of assertion pass at T:5 the assertion fails due to (vdiff>0) being false
Whereas if we use (vdiff>=0) the assertion passes at T:5 as per expectations
One possible solution which works as per intention ( for 6 scenarios that I tested ) : edalink
However the code has a limitation ( lack of sufficient clock ticks for RHS of ‘within’ to match ) as observed for +define+M7.
For +define+M7 even if there are sufficient clock ticks the assertion passes at time:55 instead of the expectation at time:35.
Using ‘within’ in consequent the code only works if I write RHS sequence of ‘within’ as 1[*(dyn1+1):(dyn2+1)] ( Tested for all 7 scenarios )
Now the challenge is to code RHS sequence which is dynamic repeat range: 1[*(dyn1+1):(dyn2+1)]
For : seq1 |-> ##[dyn1:dyn2] seq2; // where dyn1 = 0 , dyn2 = 1
The new code doesn’t evaluate seq2 for 2nd time at time:15 since expression (vdiff>0) is false for ( vdiff > 0 , vdiff-- )[*2:$]
So a solution would be to manually evaluate ‘seq2’ at next clock only if vdiff is 0 after decrement operation i.e LHS sequence of ‘or’ operator should be :
For dyn1 = 0 and dyn2 = 1 , seq2 must be evaluated twice. Once after dynamic_delay(0) matches and for 2nd time at next clock after that.
Using the new code ‘vdiff’ is decremented to 0 at same clock that dynamic_delay(0) matches.
Due to repetition range[*1:$] at next clock (vdiff>0) would be false.
With the additional logic ‘seq2’ is evaluated at next clock only if vdiff is 0 for current iteration
In reply to Have_A_Doubt:
Thanks for pointing it the error. How about this instead?
sequence dynamic_delay_lohi_sq(d1, d2, sq);
int v1, vdiff;
dynamic_delay(d1)##0
(sq or
(1, vdiff=d2-d1) ##0 (vdiff>0, vdiff=vdiff - 1)[*1:$] ##1 sq);
endsequence
for d1==0, d2=2
you delay for d1 cycles, then you evaluate
(sq or
if diff>0 (2 in this case) you get ##1 sq (vdiff==1), then ##1 sq (vdiff==0)
you end up with
##d1 (sq or ##1 sq ##1 sq
Works as per expectation for all 11 scenarios.
One last question :
For the 4 dynamic scenarios ( delay/delay range/repetition/repetition range) is it assumed that the dynamic variables remain constant for a SVA attempt OR can they change during an ongoing attempt ?
To model these dynamic cases wouldn’t the best approach be to capture the dynamic variables during the start of an attempt itself ?
Ben,
As we discussed at the top of this thread, sequence ‘dynamic_delay_lohi_sq’ has a limitation when sub-sequent sequence doesn’t match even after ##(dyn_max). The assertion fails at next clock rather than
##(dyn_max)'th clock.
Refer edalink +define+M4.
Instead of failure at T:55 the assertion fails at T:65 due to repeat sequence ending.
Your later suggested the following ::
sequence dynamic_delay_lohi_sq(d1, d2, sq);
int v1, vdiff;
dynamic_delay(d1)##0
(sq or
(1, vdiff=d2-d1) ##0 (vdiff>0, vdiff=vdiff - 1)[*1:$] ##1 sq);
endsequence
which works for all scenarios.
The same was updated in sva-package-for-dynamic-delays in Nov 2023 but that update has been lost ever since the forum upgrade.