Re: Verilog-AMS Committee Meeting Minutes - Dec 22 2006

Marq Kole wrote:

> Marq Kole - NXP Semiconductor
> David Miller - Freescale Semiconductor
> Patrick O'Halloran - Tiburon
> Martin O'Leary - Cadence
>
> The call started off with a question on who all is able to upload 
> documents to the Verilog-AMS public documents area. Would it be 
> possible to give some more people access, or do we want to keep that 
> centralized?
>
> The document posted by Marq last week containing an update of section 
> 7 (merged_hier.pdf) contained some changes that now have been largely 
> overtaken by the discussions on the reflector. The updates on paramset 
> (section 7.3.2) need to be reworked anyway, and also the discussion on 
> this item wasn't closed at the time of the call. The updates on the 
> elaboration section are now overtaken by the discussions on the 
> reflector and will have to be redone anyway.
>
> An update still needs to be made to section 7.6 (Hierarchical names) 
> that will allow hierarchical name referencing from within an analog 
> block that will also allow access to parameters (currently forbidden). 
> We did not see any need for this restriction.
>
> The issue of multiple analog blocks has topped the discussion charts 
> in the past week, so in the call we were trying to give it some follow 
> up.
>
> The current approach seems to focus on allowing both concurrent analog 
> blocks and concatenation of analog blocks by means of a continued 
> sequential block. For the continued sequential block there are 
> currently to proposals,
> 1) add "continue" as an optional first keyword before the name of a 
> named analog block.
>
>    analog
>      begin : continue active
>      end
>
> 2) use "continue" instead of "begin" as the start of a continued 
> analog block.
>
>    analog
>      continue : active
>      end
>
> It is recognized that in both cases there is overlap with the 
> "continue" keyword in SV, but neither in a way that is incompatible 
> with its use there. It was agreed that the second way is syntactically 
> cleaner. The continued analog sequential block is restricted to the 
> top-level in an analog construct. This needs to be documented in 
> section 6.

While 2 might be neater, I don't think there is any other syntax where a 
"end" is not matched with a "begin", so I'll
propose a third option: allow labeling the "analog" itself e.g.:

    analog : active
        begin
            // some initial stuff
        end
   ...
   analog : continue active
        X <+ Y;  // a single statement
   ...
   analog : continue active
        begin
            ... // multiple statements
        end

>
> The need for the continued analog sequential blocks stems from the use 
> of named analog blocks in loop generate constructs where it otherwise 
> would not be possible to access block-local variables from within the 
> loop.
>

> The second discussion item is how to handle concurrency among analog 
> blocks. The parallel with digital always blocks is a flawed one 
> because the blocking options that govern the operations of always 
> blocks do not have a parallel in analog blocks.

> Instead, every analog block is executed at every time step.

I don't think there is anything in the LRM that forces that (and there 
shouldn't be).

> The only possible option here is that each analog block can be guarded 
> to execute "as needed". A proposal that popped out of the discussion 
> was similar to the way Geoffrey modelled the various activities in the 
> MOS11 model: an analog block executes only when any of the variables 
> or contributions it uses as inputs changes. This also keeps open the 
> door for multirate simulation where various parts of the circuit or 
> model execute at different time-step rates. On the other hand, in the 
> case of multirate if there are any OOMR contributions to a branch 
> assigned to in an analog block then that will slightly complicate 
> matters for execution "as needed", but in the worst case situation the 
> blocks that contain contributions will execute every time step: it 
> does not affect simulation results.

OOMR contributions aren't semantically any different to those made 
through ports, and an analog block doesn't have any way of looking into 
what the other contributions to it's shared nodes are doing either.

As I remember it: for many models it's the solver that is working out 
the time-steps and what to re-evaluate. Models can schedule their own 
re-evaluation if they want, but the solver can preempt that. So things 
are largly executed "as needed" anyway.

The solver I worked with would run the model code multiple times to work 
out partial derivatives, so we would buffer the model's data so that 
shared and persistent data would not be propagated/saved until the 
time-step was fully evaluated (and the final run of the code would do 
it). I.e. any shared data update between analog blocks is effectively 
delta-cycle delayed, so the race conditions for analog blocks would be 
pretty much the same as those for digital. I presume other peoples 
solvers are working in much the same way.

What concurency issue are you actually worried about?

> Another suggestion was that a sequence of analog blocks when they 
> execute they will execute in the order they are defined in in the 
> input. In the issue of interactions between multiple blocks it was 
> determined to disallow contributions to switch branches in more than 
> one analog block. On the other hand, for contributions in multiple 
> analog blocks to the same voltage or current branch (based on value 
> retention) no restrictions should be made.

Can you give an example of the issue with switch branches?

Kev.

> Ownership of module-level variables to particular analog blocks is 
> probably not necessary, as compilers can generally determine when 
> possible race conditions occur. There was a suggestion to add a 
> qualifier to variable declarations to mark them as being used/assigned 
> to in multiple modules. However, it was felt that model writers should 
> not be bothered to provide information that the compiler can determine 
> by itself.
>
> The bottom line should be that whether a block is executed at each 
> time-step or at fewer time-steps should not have any impact on the 
> simulation results. What we need is that an analog model is guaranteed 
> to provide the same results independent of whether all model code is 
> in a single analog block or is divided over multiple (concurrent) 
> analog blocks.
>
> There was no discussion (yet) on the analog initialization block. 
> Also, the issues around port connections and paramsets were not 
> discussed.
>
> Marq proposed to write an outline of the multiple analog blocks 
> proposal in a separate document before incorporating this extension 
> into the LRM sections.
>
> Next 2 weeks there will be no conference call because of the Christmas 
> holidays, the next conference call will be on January 11, 2007, at 9 
> PM Pacific.
>
> Midnight Eastern = 5:00 AM GMT
> Adelaide:      3:30 PM
> India:        10:30 AM
> Eindhoven:     6:00 AM
> Eastern:       midnight
> Central:      11:00 PM
> Pacific:       9:00 PM
>
> Open actions:
> * Marq to post formatting guidelines for Verilog-AMS code examples.
> * Sri to create an overview of the work that is now finished for LRM 
> 2.3 and what still needs to be done.
> * Marq to write a multiple analog blocks proposal.
>
> Let me finish with best wishes to you all: A Merry Christmas and a 
> Happy New Year!
>
> Thanks,
> Marq