Re: multiple analog blocks

From: Kevin Cameron <kevin_at_.....>
Date: Wed Dec 20 2006 - 16:36:54 PST
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.
>   
Compilers are not necessarily that bright. If you can give them a 
helping hand then the developers can spend their limited time on other 
problems :-)

Does anyone have a problem with saying "initial" blocks run first, I 
don't think that contradicts anything currently in the standard? It's 
fairly easy to work out if all the writes to a variable are limited to 
code sequences that only run at time zero (first delta) - it's harder if 
they are buried in an analog block under an @(initial_step(..)).

If you do that you can set a variable in the digital initial block and 
then clear it in the analog for similar behavior to @initial_step in 
transient e.g.:

  int startup;
  initial begin
    startup = 1;
    // calc run-time consts/initial values here
  end
  analog begin
    ...
    if (startup) then
    begin
       startup = 0;
       ...
    end
    ...
  end

The advantage from a performance point of view is that you can postpone 
code-generation for the analog block to after the first delta by which 
time a lot more things should be constant.

NB: some stuff dates back to the Verilog-A only days and may not make 
sense or is redundant in Verilog-AMS for transient analysis.

Kev.
> -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.
>>     
>
>   
Received on Wed Dec 20 16:36:58 2006

This archive was generated by hypermail 2.1.8 : Wed Dec 20 2006 - 16:37:02 PST