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.
- 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.
- 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.
- 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".
- 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.
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.
Received on Fri Apr 13 02:23:04 2007