Re: multiple analog blocks

Geoffrey,
    While I am sympathetic to you desire to see compilers improve, I
don't think we should constrain the language in order to encourage it.
There are times when an analog initialization construct would be very
helpful, particular because Verilog-A/MS does not support initialization
of variables when they are defined. However, even if it did it would not
satisfy all needs because sometimes initialization requires more than
can be accomplished in a single expression.

Your idea that initialization would be performed by code that produces
constants, and the code would be recognized and bypassed after the
initial solve is also too constraining, because sometimes what is being
initialized is not a constant. A common example of this is when one uses
a random number function with a seed. The seed needs to be initialized
once, at the beginning, and then the seed would change on every step. So
we need the ability to conditionally execute code based on whether we
are in an initialization phase. This is what the analysis() function
provides. But presumably this is problematic as it confuses
initialization and analysis. So
    if (analysis("dc"))
        initialization code;
would result in the initialization code being executed on every step of
a DC sweep. We could provide a new `analysis` called "init" that would
result in analysis("init") evaluating to true on the first step of any
analysis, or perhaps the first iteration is sufficient.

Martin's suggestion of an analog initial block seems better to me
because it identifies code that would be run before any analysis began.
This seems more natural to me than using an analysis() function embedded
in an analog block. And it is nice having it a separate block because it
can have its own syntax rules, which could be used to forbid nonsensical
operations, such as contribution.

Kevin's suggestion of using an initial block to perform initialization
seems problematic to me for several reasons. First, it is my
understanding that in Verilog, both initial and always blocks are
started at the same time. Kevin's suggestion acts to constrain the
simulation cycle in a way that may be undesirable. Second, if a variable
was assigned a value in an initial block, then it would be owned by the
digital kernal and so could not be modified in the analog block. This
would prevent initialization of variables that are updated in the analog
block. Finally, Verilog-A does not support initial blocks, and so
Kevin's solution would not help Verilog-A, even though the need there is
just as strong.

-Ken

Geoffrey.Coram wrote:
> Kevin -
> There are a few problems with @initial_step:
> 
> 1) it's a *bad* idea to use it for a dc sweep -- if you put the
> temperature-update equations in there (setting aside self-heating,
> the "ambient" temperature is used to set internal variables which
> are constant for a transient analysis) then these variables are
> not updated when sweeping temperature
> 
> 2) an analog solver has to run the @initial_step block on every
> iteration of the first step of a transient analysis
> 
> On the other hand, the compiler can -- and thus should -- determine
> which variables depend only on the parameters (and perhaps
> temperature -- and the compiler/simulator will also know when
> temperature is fixed or not).  It can do this simply by analyzing
> the dependency tree.  It does not need any further assistance
> from the model writer.
> 
> -Geoffrey
> 
> 
> Kevin Cameron wrote:
>> Seems to me that it would be good to give the simulator the opportunity
>> to evaluate internal variables from parameters post-elaboration and
>> prior to actual transient simulation (if they are going to be constant
>> for transient). If @initial_step doesn't do that (and it doesn't seem
>> to), can we make it that digital initial blocks run before any analog
>> processes starts, so that a "smart" compiler can work out what will be
>> constant?
>>
>> Kev.