implementation of @(initial_step)
rdk
@(initial_step). Specifically, should the code block be executed only
once at the appropriate event, or for each iteration of the step? For
example, for @(initial_step) or @(initial_step("dc")), do we signal
the event only once during DC, and if so when? At the beginning of DC,
or at the end? Or do we signal the event for every iteration of the
DC? Similarly, for transient, is it for every iteration of the first
transient time step? What if the time step fails and is repeated?
(Technically, isn't the first transient step actually the operating
point analysis?)
It would be useful if the LRM offered more detail to resolve this
issue. Compiler writers out there, how have you implemented this?
Alfredo Piazza
Alfredo
Geoffrey Coram
and I stated my objections in the 2004 BMAS paper, so this is
somewhat off-topic for this discussion group.
The code block would need to be executed for every iteration
of the step, but note that variables would be reset on each
iteration, so that
@(initial_step)
x = x + 1;
would not add up for each iteration.
I thought the table on initial_step was reasonably clear on this.
-Geoffrey
Geoffrey Coram
the compiler/simulator should figure out what calculations
can be done before any analysis -- and what calculations
need to be re-done, because eg the length is being swept.
rdk
On Nov 2, 10:31 am, Geoffrey Coram <Geoffrey.Co...@analog.com> wrote:
> I don't think initial_step is appropriate in any compact model,
> and I stated my objections in the 2004 BMAS paper, so this is
> somewhat off-topic for this discussion group.
past month, who have Verilog-A models that use @(initial_step), and
are observing that the behavior in my simulator is not the same as in
a different simulator. Hence the quest for clarification.
Alfredo Piazza
Geoffrey Coram
that should *not* go in an initial_step block, because then a dc
sweep of length will not show any variation!
I hope you are discouraging users from using initial_step.
rdk
On Nov 2, 2:10 pm, Geoffrey Coram <Geoffrey.Co...@analog.com> wrote:
> I hope you are discouraging users from using initial_step.
developer and slap their fingers when they type "initial_step". Yes,
when they ask me I can discourage it. But they often don't ask. Under
these circumstances, models get released, and questions arise
regarding quirky, inconsistent behavior. I would at least like to have
a consistent implementation.
So let's get back to the original question. How should this behave?
Are we all agreed that the related block should be executed at each
iteration of the indicated (operating point, or time or frequency)
step?
Geoffrey Coram
>
> The problem is, I cannot look over the shoulders of every model
> developer and slap their fingers when they type "initial_step".
It's depressing that, 7 years after I wrote that paper, people
are still failing to follow its guidelines.
(Or is it that, 7 years later, users still find that they get
better performance by putting this in, which is depressing
for a different reason.)
> So let's get back to the original question. How should this behave?
>
> Are we all agreed that the related block should be executed at each
> iteration of the indicated (operating point, or time or frequency)
> step?
Yes.
Dan Fitzpatrick
The Accellera AMS-2.3 document is fairly clear on the semantics of the global events (initial_step/final_step):
"If no analysis list is specified, the initial_step global event is active during the solution of the first
point (or initial DC analysis) of every analysis. The final_step global event, without an analysis list, is
only active during the solution of the last point of every analyses."
The key points are "active during the solution" at the first and last points of an analysis - e.g., not at the beginning
of an iteration or at any other iteration other than the solution point. So whatever statement is activated by
the events only happens twice. The @initial_step construct is not a work-around for handling state variables
in a model (e.g., x = x + 1).
These global events came about primarily because of conflict with the semantics of Verilog-D initial/always
blocks. There is no implied ordering between the execution of initial and always, only if they repeat or not.
The objective of the global events was to support state dependent models, test benches and the like. I believe
there were some additional issues related to compatibility to Verilog-D semantics but don't recall at the moment.
Geoffrey has highlighted a lot of valid reasons for not using these in compact models, but these global events
weren't there for initializing compact models. The use of the "_step" suffix has caused untold confusion but
its choice was more a factor of "historical" reasons at the time.
--Dan
________________________________________
From: cmc-ve...@googlegroups.com [cmc-ve...@googlegroups.com] on behalf of Geoffrey Coram [Geoffre...@analog.com]
Sent: Wednesday, November 02, 2011 1:02 PM
To: cmc-ve...@googlegroups.com
Subject: Re: [cmc-verilog-a] Re: implementation of @(initial_step)
Selim, Mohamed
I agree with Geoffry, @initial_step is something to be done only once to
initialize some quantity to its default value.
The concept of having some independent voltage calculation is used by
some developers intended to the ADMS converter where they use markers
like: @initial_model and @initial_instance to define blocks that are to
be calculated either once per model (temperature update for models with
no self heating) or once per instance (geometry related calculations)
Then it is up to the simulator/compiler to use these blocks for
optimization and recall them on proper basis in case of dc sweep for
Length for example.
Regards
Mohamed Selim
Geoffrey Coram
@initial_model and instead uses block names as a hint; this is
permitted by the standard, since identifiers (block names, variable
names, etc.) are chosen at the author's discretion.
begin : initial_model
// once per model calculations
end
I think this is a pretty good solution; it gives the model
developers a good feeling (even though some simulators may
ignore it because they have optimized their dependency tree),
and it gives a small crutch to some simulators.
(It's not perfect, because I could imagine someone changing
a model to make a "model" parameter into an "instance"
parameter and forgetting to move related calculations from
initial_model to initial_instance.)
-Geoffrey
rdk
On Nov 3, 4:28 am, "Selim, Mohamed" <mohamed_se...@mentor.com> wrote:
> I agree with Geoffry, @initial_step is something to be done only once to
> initialize some quantity to its default value.
>> Are we all agreed that the related block should be executed at each
>> iteration of the indicated (operating point, or time or frequency)
>> step?
> Yes.
The indication is that @initial_step is NOT something to be done only
once, in fact it is done as many times as it is necessary to evaluate
the verilog-A module during the step of interest, i.e. at every
iteration.
Similar confusion arises here:
On Nov 2, 6:40 pm, Dan Fitzpatrick <d...@awrcorp.com> wrote:
> The key points are "active during the solution" at the first and last points of an analysis - e.g., not at the beginning
> of an iteration or at any other iteration other than the solution point. So whatever statement is activated by
> the events only happens twice.
solution" means exactly that it should be done for each iteration of
the solution (of the point of interest, be it the first or last
point.)
To me, there is a basic disconnect between the notion of an "event",
and the necessity of iterating to a solution for nonlinear models. If
there is a narrowly defined way in which we are allowed to use the
event, we might get away with signaling the event only once. But there
is not, and it is very possible that state-dependent code is written
within the event block. This code will need to be updated at each
iteration in order to preserve the authors intent.
Take a look at this example from the LRM:
analog begin
@(initial_step or cross(V(smpl)-2.5,+1)) begin
vout = (V(in) > 2.5);
end
V(out) <+ vout;
end
It is not going to behave correctly unless vout gets updated each time
V(in) changes, i.e. at each iteration.
Geoffrey Coram
rdk wrote:
> The indication is that @initial_step is NOT something to be done only
> once, in fact it is done as many times as it is necessary to evaluate
> the verilog-A module during the step of interest, i.e. at every
> iteration.
Correct, and the example from the LRM confirms this:
> analog begin
> @(initial_step or cross(V(smpl)-2.5,+1)) begin
> vout = (V(in) > 2.5);
> end
> V(out) <+ vout;
> end
>
> It is not going to behave correctly unless vout gets updated each time
> V(in) changes, i.e. at each iteration.
> Similar confusion arises here:
>
> On Nov 2, 6:40 pm, Dan Fitzpatrick <d...@awrcorp.com> wrote:
>
>> The key points are "active during the solution" at the first and last points of an analysis - e.g., not at the beginning
>> of an iteration or at any other iteration other than the solution point. So whatever statement is activated by
>> the events only happens twice.
>
> That is not my interpretation at all. To me, "active during the
> solution" means exactly that it should be done for each iteration of
> the solution (of the point of interest, be it the first or last
> point.)
I was also confused by what Dan was trying to say. I suspect, though,
he was thinking about something like
analog begin
@(initial_step) begin
$strobe("Beginning the analysis");
fd = $fopen( "datafile.txt" );
end
@(final_step) begin
$strobe("Done!");
$fclose( fd );
end
end
where the $strobe will only be printed once, and the file will only
be opened once -- not re-opened each iteration.
Dan Fitzpatrick
Just to clarify, please refer to table 5-1 in the Accellera Verilog-AMS LRM version 2.3. If there is
a newer one available, and it differs, I stand corrected. But the table is fairly explicit in showing
that these global events (initial_step and final_step) only occur at the beginning and end of an
analysis, not at the beginning of every iteration of an analysis.
The example used below for supporting the later,
> analog begin
> @(initial_step or cross(V(smpl)-2.5,+1)) begin
> vout = (V(in) > 2.5);
> end
> V(out) <+ vout;
> end
Is in a section illustrating the behavior of the "event or" operator. In other words, the model could
be written as:
> analog begin
> @(initial_step) begin
> vout = (V(in) > 2.5);
> end
> @(cross(V(smpl)-2.5,+1)) begin
> vout = (V(in) > 2.5);
> end
> V(out) <+ vout;
> end
and still exhibit the same behavior.
For those with access to commercial simulators which support VPI for AMS models (especially
those simulators considered standard in their behavior), you should be able to stick some system
tasks inside a block triggered by "@initial_step" and anywhere in the analog block to determine
the behavior.
The example below regarding the use of @initial_step and @final_step is along the lines of the
original intent.
The @initial_step is not meant as a means for a model developer to manage the state behavior
of the model. It is up to the compiler to detect state in the model and support it appropriately
such that the model behaves consistently independent of the system for which it is instantiated.
--Dan
PS: ADMS as of two years ago did not support any of the event constructs, so labeled blocks
were the defacto mechanism for supporting allowing the model developer to give hints to the
compiler for initialization etc. User defined attributes (see section 2.9 in above reference LRM)
are typically used for differentiating model/instance parameters.
________________________________________
From: cmc-ve...@googlegroups.com [cmc-ve...@googlegroups.com] on behalf of Geoffrey Coram [Geoffre...@analog.com]
Sent: Thursday, November 03, 2011 7:19 AM
To: cmc-ve...@googlegroups.com
Subject: Re: [cmc-verilog-a] Re: implementation of @(initial_step)
Geoffrey Coram
We agree that the global event initial_step occurs only at the beginning
of the analysis. However, in an analog (Spice-like) solver, that
"initial step" (time-0 solution or initial dc operating point) may require
several Newton-Raphson iterations. Richard's question was whether the
initial_step was active for all N-R iterations of the first "point"
of the analysis. The answer to that question is yes.
-Geoffrey
Dan Fitzpatrick
Geoffrey,
Then I guess I missed why this even came up as the situation for how to handle
this is as the mechanics are no different than handling any other intermediate point
in an analysis (in which the solution requires iteration).
--Dan
________________________________________
From: cmc-ve...@googlegroups.com [cmc-ve...@googlegroups.com] on behalf of Geoffrey Coram [Geoffre...@analog.com]
Sent: Thursday, November 03, 2011 8:12 AM
To: cmc-ve...@googlegroups.com
Subject: Re: [cmc-verilog-a] Re: implementation of @(initial_step)
Dan -