Re: multiple analog blocks

Ken -
I'm sorry, I'm not seeing the difficulties you suggest.  You may
have to provide me a more detailed example.

My view of the matter is the reverse of yours: you argue we shouldn't
"constrain" the language -- but I'm not advocating adding any 
constraints, I'm saying that we don't need to expand the language
because the compilers can be made smarter.  I believe there are
already at least two commercial simulators that are this smart.

My understanding is that the random number functions are completely
handled by the @initial_step construct, which -- like your proposed
analysis("init") is true only on the first step of an analysis
(LRM 2.2 specified that one can ask for the first tran step or
the first step of other analyses).  One sets the seed in @initial_step
and then the random function takes care of updating the value on
subsequent steps (and the simulator keeps track of whether it's on
an iteration of the same step and thus doesn't need a new value).
Also, of course, the seed initialization is generally a simple
assignment, so there's no optimization to be done anyway ...

(Can you review the arguments to initial_step() and tell me how it
differs from the analysis("init") that you propose?)

I also think Martin's "analog initial block" suffers from the same
problems as @initial_step, in that for different types of sweeps,
one does or does not want the initialization to be re-run.  If one
does a dc sweep of an external supply voltage, then the initial
block can be run once.  If one does a parameter sweep, then the
initial block needs to be re-run for every step.  If one does a
temperature sweep, then the variables that depend only on parameters
can be initialized once but temperature-dependent variables need to
be re-computed for every step.  So, when do you propose that the
analog initial block be run?  (What should the LRM say?)  If the LRM
ultimately ends up saying "the analog initial block is for 
initialization, and the simulator determines whether to run the
statements inside the initialization block depending on the analysis"
then you haven't really made the job of the compiler developer any
easier; you've just provided a security blanket for the Spice model
developers that are accustomed to writing an initialization in C.

-Geoffrey


Ken Kundert wrote:
> 
> 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