Dinamycally changing errpreset/reltol based on rising edge of a given signal

To answer your questions:

1. Yes. Use the dynamic parameters option on the tran analysis form, and set the time to be "@(assert1)" (with quotes) or @assert1 (with or without quotes). The assert itself should be included via a definition file/model file
2. No, this is not possible. Because spectre supports multiple analyses of each type (you just need to name them differently), there's no merging of options from duplicate analyses with the same name (note, by "name" I mean the first word on the analysis line preceding the type of analysis (tran in this case).
3. Yes, you could do that. Do Simulation->Netlist->Create and then copy the lines from there (then disable the tran analysis). However, this seems a bit pointless since you can do 1.

Andrew

Thank you. I am now using option 1.

When it comes to use a bit less basic triggers than a bigger/lesser than condition, see that unfortunately the calculator syntax is not the correct one. For instance, I would like to get an assert at the 5th rising edge of a given signal, the following line will produce an error:

assert2 assert expr="cross(v("i_top.clk") 0.8*vdd 5 "rising" nil nil  nil )"

here in the specific case I am not even sure whether the issue is the syntax, or the cross function not being read as a false/true statement?

How should I write it in the specific case to get an assert at Nth rising edge of a signal?

And more in general, which syntax has to be used here? Where can I find some documentation to refer to, when more complicated trigger conditions might arise?

Thank you

Best regards

Any expressions for asserts are in Spectre MDL (Measurement Description Language) rather than SKILL (which is what the calculator uses). This is covered in the <SPECTREinstDir>/doc/mdlref/mdlref.pdf .

There is a cross() function in MDL - here's what. you want:

assert2 assert expr="cross(V(ip),'rise,5,0.5)" max=0

Andrew

Thank you.

I have tried to implement this:

content of included file:

assert1 assert expr="v(test_signal)>vdd/2"
assert2 assert expr="cross(sig=v(i_top.clk),dir='rise,n=5,thresh=0.5)" max=0

However I think the second assert does not get triggered, because while I do get in the simulator log a line stating: "The value of parameter 'reltol' was set to 0.01 at time 9.19285e-09 s. The effective value of 'reltol' is now 0.01" which corresponds to the assert1, there is never a similar line for reltol at 1e-5.

(clearly I did check that signal i_top.clk crosses the 0.5V threshold for at least 5 times during the simulation)

Plus it seems that the assert2 is properly recognized as the following statement appears: " WARNING (SPECTRE-17003): Assert `assert2' contains an expression that needs to be evaluated by MDL. Using this assert frequently may lead to performance issues because the MDL evaluator is slower than the native assert evaluator. Support for evaluating assert expressions using MDL will be discontinued in future releases."

Is it possible that the log does not mention the new change in reltol and the assert is still taking place, or the fact that I do not see it means it is not effective? And if so, did I make any mistake? 

Also from the documentation, there is nothing obvious to me why this would not work (except I read cross function to be defined as crosses somewhere, but even with changing that, I get the same result)

There seem to be a couple of problems with using cross in an MDL-based assert that I found:

1. The assertions don't get saved into the SQL database (so if you look at the Checks/Asserts view in ADE, they don't show up). They are actually triggering though. I found a very recent CCR on this (2825621) which was fixed in the last couple of days. I am checking with R&D whether it will fix my example - the root cause is that those using the older MDL flow for asserts are not saved to the SQL database.
2. The same asserts do not trigger dynamic parameters either (sorry, I didn't notice that when I checked - I only saw the assert message and didn't realise it wasn't changing the errpreset/reltol that I was altering). This might be for the same root reason - I have filed CCR 2850319 for this.

Andrew

Thank you for coming back with this.

So is there any other way to do what I was trying to do (varying reltol and/or errpreset based on cross events during the simulation?)

And if not, will this actually get fixed soon, as you mentioned in your point 1?

Best regards

It seems that the fix for CCR 2825621 does indeed fix this, provided that you use the pass-by-order syntax (that I used in my example above) for the cross-function rather than than the pass-by-name syntax that you used. In other words, if you use:

assert2 assert expr="cross(V(ip),'rise,5,0.5)" max=0

then this should work. SPECTRE21.1 ISR21 (which contains the fix) is due out around 17th August.

If you can't wait that long, another approach is to use a Verilog-A module instead to check. I just wrote this:

`include "disciplines.vams"

module dynassert(trigger);
input trigger;
electrical trigger;

parameter real thresh=1.0;
parameter integer direction=1;
parameter integer crossnum=1;
integer crosscount;
integer assert;

analog 
  @(cross(V(trigger)-thresh,direction)) begin
    crosscount=crosscount+1;
    if(crosscount==crossnum) begin
      $display("Triggered crossing at time ",$abstime);
      assert=1;
    end
  end

endmodule

then you'd instantiate this in your design connected to the signal you're monitoring and set thresh, crossnum and direction parameters appropriately (direction=1 means rising). Then use "@(DA1:assert)" (in quotes) with DA1 being the instance name of the monitoring component as the dynamic parameter event trigger. 

I tested this - it works fine for me.

Andrew

It seems that the fix for CCR 2825621 does indeed fix this, provided that you use the pass-by-order syntax (that I used in my example above) for the cross-function rather than than the pass-by-name syntax that you used. In other words, if you use:

assert2 assert expr="cross(V(ip),'rise,5,0.5)" max=0

then this should work. SPECTRE21.1 ISR21 (which contains the fix) is due out around 17th August.

If you can't wait that long, another approach is to use a Verilog-A module instead to check. I just wrote this:

`include "disciplines.vams"

module dynassert(trigger);
input trigger;
electrical trigger;

parameter real thresh=1.0;
parameter integer direction=1;
parameter integer crossnum=1;
integer crosscount;
integer assert;

analog 
  @(cross(V(trigger)-thresh,direction)) begin
    crosscount=crosscount+1;
    if(crosscount==crossnum) begin
      $display("Triggered crossing at time ",$abstime);
      assert=1;
    end
  end

endmodule

then you'd instantiate this in your design connected to the signal you're monitoring and set thresh, crossnum and direction parameters appropriately (direction=1 means rising). Then use "@(DA1:assert)" (in quotes) with DA1 being the instance name of the monitoring component as the dynamic parameter event trigger. 

I tested this - it works fine for me.

Andrew