RE: multiple $bound_step calls

" I think you're getting out of the realm of a hardware description language
and into trying to specify how a simulator operates"

...doesn't $bound_step itself specify how the simulator should operate? ;-) wink.

But seriously, if the definition becomes that any given $bound_step() call is 'valid' only for the *unique occurrence* of the module that made the call (and doesn't apply outside of that), then actually its good enough as that will naturally scope it's effect to its own partition in the case of multi-rate simulators. Using this scoping definition, Multiple $bound_steps within the *same* module would then have the smallest one win for that module. And that's as far as the definition of 'smallest one wins' should really go, i.e. they shouldn't affect other modules (which may be in other partitions that run at different rates). Which is all fine and well for the purposes of modeling but may introduce significant back compatibility issues if that type of per-unique-occurrence scoping was not applied in the past i.e. $bound_step() calls were treated 'globally'.

Also, what if
(a) one wants to use $bound_step() for other reasons entirely other than required by a model (e.g. a user trying to debug convergence issues by forcing partitions to go in lock-step to see if his model still works/breaks, or ensuring a regular .strobe type of output gets generated regardless of partition, or ....).

There can be reasons (beyond the immediate realm of modeling) for wanting/needing the force the entire simulator to have breakpoints at the same time, (even across all partitions if the simulator is multi-rate). One could argue that some external vendor-specific mechanism should be provided to force this behavior, but even with this said I think the issue of back-compatibility remains.

I suspect multi-rate may not have been thought about when the original proposal was made (Ken, please feel free to correct me) and so global behavior by default was fine at least for a while. But there remains some ambiguity in the face of multi-rate, which the soft-hard proposal would address while also allowing a user to get complete back compatibility and more flexibility.

It's certainly an interesting problem...reminds me of the 'law of leaky abstractions' but where the simulator itself begins to leak through. http://www.joelonsoftware.com/articles/LeakyAbstractions.html

--
Don O'Riordan
Sr Architect, Custom IC and Sign-off R&D
mailto:riordan@cadence.com      (408) 428 5794
 
-----Original Message-----
From: Geoffrey Coram [mailto:Geoffrey.Coram@analog.com] 
Sent: Thursday, June 14, 2012 1:29 PM
To: Don O'Riordan
Cc: Ken Kundert; Marq Kole; verilog-ams
Subject: Re: multiple $bound_step calls
I think you're getting out of the realm of a hardware description language
and into trying to specify how a simulator operates.
I think if you've got a multi-rate simulator, then you take care of deciding
what elements see what time steps, and $bound_step would only control the
time step seen by the particular module that made the call.  It is, as always,
the job of the simulator author to determine how the time steps seen by one
element affect what's seen by others.
Don O'Riordan wrote:
> What happens in a multi-rate simulator? It seems a bit harsh (from a performance aspect) to 'punish' a module with large bound steps in a low-frequency partition with the smaller bound steps of a different module (in a high frequency partition) for example...?
> 
> Not sure that the standard should mandate the small bound step applies everywhere. Maybe there is a need to introduce a soft-bound-step and a hard-bound-step concept? 
> 
> With this, a low-frequency partition within simulator could be free to ignore any soft-bound-step values specified in a separate high frequency partition? It would however honor any soft-bound-step calls made within its own partition. Any hard-bound-step values operate 'globally' with the smallest value winning.
> 
> Or, stated differently (and more succinctly), soft-bound-steps are applied within a partition. Hard-bound-steps are applied globally across all partitions.
> 
> This could be done with a new optional argument to $bound_step itself, which specifies the soft/hard component. If left unspecified, its treated as hard, which gives full back compatability with Kens original definition?
> 
> 
> 
> --
> Don O'Riordan
> Sr Architect, Custom IC and Sign-off R&D
> mailto:riordan@cadence.com      (408) 428 5794
>  
> 
> 
> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Geoffrey Coram
> Sent: Thursday, June 14, 2012 1:03 PM
> To: Ken Kundert
> Cc: Marq Kole; verilog-ams
> Subject: Re: multiple $bound_step calls
> 
> Indeed, "the smallest wins" is the only way to have the results not depend
> on something arbitrary like the order in which different modules are
> evaluated (which would be bad).
> 
> If the simulator takes a step that is larger than the smallest argument
> supplied to any $bound_step call, then that step has not been appropriately
> bounded according to the definition of $bound_step.
> 
> 
> 
> Ken Kundert wrote:
>> Marq,
>>     I don't believe it is ambiguous. I interpret it in that there need not be 
>> just one bound on the time step. Instead, all active bounds are applied with the 
>> smallest winning of course. This is certainly what I intended when I wrote it.
>>
>> -Ken
>>     
>> On Thu, Jun 14, 2012 at 09:27:59PM +0200, Marq Kole wrote:
>>> Hi All,
>>>
>>> What should happen when the $bound_step system task is called multiple times? The LRM does not say anything about it so this leaves room for ambiguity. There are a couple of options, but I think the most appropriate is that the smallest argument of all activated $bound_step calls takes precedence. This will make sure that the part of the model that requires the smallest maximum time step gets its way. The parts of the model that can do with larger maximum time steps should also be able to live with a smaller time step.
>>>
>>> I will make a Mantis item for this issue. If you have alternative views on this matter I would be interested to hear.
>>>
>>> Cheers,
>>> Marq
>>>
>>>
>>> Marq Kole
>>> Senior Architect AMSRF Simulation
>>> NXP Semiconductors / Central R&D / Foundation Technology
>>>
>>>
>>> -- 
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
> 
> 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.