Verilog-AMS Committee Meeting Minutes - Dec 22 2006

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.

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

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.

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