Re: multiple analog blocks

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.
>
I see no undesirable constraint. Given that a digital simulation starts 
of with a lot of X's it's desirable to clear as many as possible before 
starting into the analog simulation so that D2As are more likely to be 
set up, so running the initial (and always) blocks first makes sense, 
and making that part of the standard will make simulation more 
reproducible. The reason for focussing on the initial blocks is that 
they are easily recognized and unlike the always (and analog) blocks can 
terminate, so are easier to analyze for optimization opportunities.

> 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.
>
I see you're still stuck with the idea that analog or digital owns 
something rather than it being shared.

> 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.
>  
>
I didn't think Verilog-A was a proper language now that Verilog-AMS is 
out, and any half decent simulator should be able to read a bunch of 
variable assignment statements in a simple  initial-begin-end block even 
if it can't do the rest of the digital stuff.

Still trying to get your head round the concept of a single kernel mixed 
signal simulator?

Kev.

>-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.
>>>      
>>>