assert property (@(posedge clk) disable iff(reset) a |-> ##[0:50000] b);
As you can see the interval on which b can occur is very big, and I even get warnings from the simulator(s) but this is the timing defined in the specification, I was wondering if there are other ways of work around this, maybe some helper logic but I’m not entire sure how to rewrite the assertion and the how the helper logic would need to look like.
[0:$] would actually be easier to handle than the case where you have an upper bound. It would just mean counting up for a and counting down for b. With a fixed bound, the tool also needs to manage the “timeouts”.
In reply to ben@SystemVerilog.us: [0:$] would actually be easier to handle than the case where you have an upper bound. It would just mean counting up for a and counting down for b. With a fixed bound, the tool also needs to manage the “timeouts”.
|-> ##[1:50000] b ##3 c
The consequent is multi-threaded
(##1 b ##3 c) or (##2 b ##3 c) or...
This get really messy in terms of multi-threading
|-> ##[1:50000] b ##[1:10] d
(##1 b ##1 d) or (##1 b ##2 d) or (##1 b ##3 d) or.
...
(##1 b ##1 d) or (##2 b ##1 d) or (##3 b ##1 d) or..
(##1 b ##2 d) or (##1 b ##3 d) or (##1 b ##3 d) or..
.... Lots of threads...
..
(##50000 b ##1 d) or (##50000 b ##2 d) or (##50000 b ##3 d) or
The simulator operates on threads. With the 50k and 10 ranges you have 500k threads.
There is optimization by the tool, maybe something like dynamically created threads depending on dynamic results on clock basis. I am not a tool builder. However, fundamentally, each range creates that many threads and when you compute the combinations, that’s quite a large number.
Ben systemverilog.us