Re: minutes Verilog-AMS Committee Meeting - 12 April 2007 - feedback

Marq Kole wrote:
>
> All,
>
> Here are the meeting minutes of the Verilog-AMS Committee Meeting of 
> 12 April 2007
>
> present:
> Martin O'Leary - Cadence
> Patrick O'Halloran - Tiburon
> Geoffrey Coram - Analog Devices
> Sri CHandra - Freescale
> Marq Kole - NXP
>
> agenda:
> - Continuation on the review of analog block proposal from last week
>
> minutes:
> An update (version 3) of the Multiple Analog Blcoks document was 
> posted on the Verilog-AMS website a few hours prior to the conference 
> call, containing updates to the previous version as discussed during 
> last weeks conference call, and emails from Ken Kundert and Kevin 
> Cameron.
>
> - regarding multirate/latency, based on the feedback from Ken it was 
> decided that latency is not considered a driver for multiple analog 
> blocks. This means that the diode example from section 2.3 will be 
> removed as well as all text relating to it. The main conclusion in the 
> final paragraph of 2.3 will be maintained.
>
> - multiple analog blocks should be less restrictive then suggested by 
> Ken in his email. It should be possible to share variables, something 
> that is not allowed for multiple instances as OOMR access to variables 
> is not possible, neither in digital nor in analog. If sharing of 
> variables is not used, multiple analog blocks will act as though they 
> were multiple instances.
>
> - the initial suggestion to just concatenate all analog blocks in a 
> single one was discussed again. It was considered that the parallel to 
> multiple instances (which operate concurrently) as well as the 
> parallel to digital always and initial blocks is valid and usefull, so 
> the default behaviour of multiple analog blocks will be that they are 
> concurrent.
>
> - In the text of section 2.3 dependency graphs are mentioned. Martin 
> mentioned that sensitivity lists as used in the digital context are 
> much more appropriate as these are instrinsically dynamic (event 
> driven), while dependency graphs are intrinsically static (determined 
> at compile time). In that sense sensitivity lists make more sense. The 
> text for section 2.3  will be updated to reflect this.
>
> - multirate, parallelism or latency should not be made explicit in the 
> language. Rather, if a tool supports it, it is up to the underlying 
> implementation to make optimal use of it and not have the model writer 
> or simulation user worry about this. There are sufficient reasons to 
> believe that user interaction for support of multirate, parallelism 
> and/or latancy is not needed.
It needs to be clear which operations are atomic, e.g. if things are 
evaluated in parallel do threads have exclusive access to (say) an 
array/vector or just scalars?

A simple rule you can add (if it isn't there already) is: no two 
processes that directly share data should be active at the same time.

Note: with copy-in/copy-out the copy operations probably need to be 
atomic, but not the process evaluation.
>
> - everybody on the call agreed that associating unnamed branches with 
> the module level instead of the analog block level is a good thing. 
> However, the restriction of unnamed branches to a single analog block 
> (in the last paragraph of section 3.1.1) was considered overly 
> restrictive. If the unnamed branches are associated with the module 
> there would be no issue as each contribution to unnamed branches in 
> the various analog blocks within a module would essentially be made to 
> the same branch. Of the nature of all contributions is the same, they 
> simply add up, if not, then we'd be in the realm of switch branches 
> for  which additional rules shall be made to apply.
>
> - copy-in, copy-out behaviour has too many restrictions to be acceptable.
I think my earlier point on that was: that's how the simulator works, 
it's not really something you can change.
>
> - for switch branches it was concluded that the best approach was do 
> disallow concurrent switch branches, i.e. a switch branches whose 
> contributions are distributed over multiple analog blocks. In most 
> cases this would be the result of bad modelling, while a few cases 
> that might be legal can also be described using switch branches on 
> named branches that are local to the analog blocks.
It can't see how you can enforce that, it's going to be difficult to 
analyze statically and how can you tell in a large design using 3rd 
party IP where the switch branches are?

The wired-or case I posted before seems like a simple case that should 
be handled properly.

Looking at the discussion document I think you are confusing the 
race-condition argument with the switch branch condition evaluation. For 
any given branch the contribution from each analog block is evaluated 
independently, if you can't tell from static analysis that they are all 
flow or there is always a potential it's going to be a switch branch, if 
it's a switch branch then there should only be one potential 
contribution active at any time (unless the contributions are 
identical), and that has to be a runtime check.

> - for continued analog blocks, it was considered that this was a legal 
> extension necessary for the support of generate constructs where a 
> specific order of evaluation of the resulting multiple analog blocks 
> was required. As it is, for the various options described in section 
> 3.2.2, option 2 extended for named blocks was considered best in being 
> more easily to read, allowing sufficient flexibility in not having to 
> write the blocks to concatenate next to each other, and associateing 
> the continuation with the analog statement rather than the sequential 
> block (as in option 3). For the keyword to use, we did not want to 
> reuse "continue" to prevent confusion, and settled for the word 
> "concatenate".
I still advise against "concatenate" because it will meet resistance in 
other committees - new keywords always do.

The concatenate keyword should have a label so that you can concatenate 
different groups of blocks within a module separately. You could make 
the label optional, but I think making it mandatory would be better - 
and you can relax that rule later.

As another alternative you could skip the keyword and just label the 
analog statement and concatenate the statements with the same label, 
e.g. scopes first and last below would be concatenated:

       analog : foo begin : first ... end  // concat. group: foo, scope: 
first

       analog : bar begin ... end  // concat. group: bar, scope: first

       analog : foo begin : last ... end  // concat. group: foo, scope: last
 
- less typing, no new keywords.
>
> - based on the discussion results and the decisions taken, the 
> following will now be done:
>   * Marq will update the multiple analog blocks document with the 
> current insights and discussion results.
>   * Marq will make a new update of Chapter 7 of the LRM 2.3 to reflect 
> the decisions, to be discussed next week.
>   * Marq will make a document on the impact of changes to Chapter 7 to 
> the other chapters in the LRM 2.3 as well as the syntax maintained by 
> Graham Helwig.
I don't think we are at a point where we can commit to changes yet. I 
would prefer to see more discussion on the items individually on the 
reflector and proper proposals for each item before any updates.

Kev.

PS: If responding on a particular topic just cut out that part and start 
a new thread with it.
>
> next call:
> April 19, 2007, regular call times


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.