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.