Subject: LRM 2.0 Issues list
From: Ian Wilson (imw@antrim.com)
Date: Thu Jan 04 2001 - 11:15:55 PST
The body of this email contains notes on a number of issues in the 2.0 LRM.
It is intended for input to the discussion process for the AMS working
groups, and not as a criticism of the effort that went into producing the
2.0 document.
I have edited this list from another document so please excuse any raw
spots or apparent irrelevant pieces.
Thanks & Happy New Year,
-ian
Verilog-AMS 2.0 LRM Issues
Ian Wilson
Date: 01/04/01
Overview
The reference document for Verilog-AMS is the 2.0 Language Reference Manual,
published on February 18th, 2000 by OVI.
This note outlines areas that are poorly defined, ambiguous, or missing content.
Its intention is to make sure that these areas are considered in future
standardization efforts and to aim at enabling multiple implementations that
can run user Verilog-A/MS code that conforms to the standard.
Issues of compatibility, portability and migration are also considered.
Notes are discussed by section.
1.2 Mixed-signal language features
Access to analog signals from digital behavioral blocks, and vice versa.
This is where the largest differences appear from earlier language levels.
The features are defined further in Chapter 8 and other places.
3.3 Genvars
Cleaned up from earlier versions (which had a generate statement).
There are significant issues of scoping, etc, related to genvar.
Verilog-2k has different mechanisms for this. This looks like a highly unportable feature.
3.4.3.{2,3} Empty disciplines; undeclared nets
Description allows for netlists with uncommitted interconnect.
The intention is clear although the explanatory text is highly ambiguous.
Antrim AMS supports netlists using wire as an interconnect using psuedodisciplines.
3.4.5 Ground declaration
Changed completely from previous usage (and totally incompatible with it, since ground
now becomes a different kind of keyword).
Need a migration plan for present users.
3.5 Real net declarations
Changed (and relocated) from previous definition.
This is an attempt to formalize $realtobits(), etc. Most of the semantics and syntax is missing
from the definition. No rules provided for conversions with other net types. Expect Verilog-2k
to conflict. This looks like a highly unportable feature.
3.6 Default discipline
This applies to discrete disciplines only. Requires further definition (e.g. relationship
with `reset_all).
4.4.1 Restrictions on analog operators
See earlier comments on genvar. Also, this LRM introduces null arguments to these and other
functions; this in turn introduces the need for various default values (which are not all
provided by the LRM).
4.4.7 Absolute delay operator
The LRM renames the previously named delay operator (which was a potential source of conflict
with existing Verilog-D decks).
Will need to support ‘delay’ as an alias for a migration period.
4.5 Analysis dependent functions
Extended and better defined (with tables) in this LRM.
Meaning of some cases (see also initial_step) is not clear for AC analysis, etc.
6.7 Events
This LRM allows mixture of analog and digital events.
This is a major new feature. It allows constructs like @(posedge clk or cross(V(1), 1)).
Requires analog/digital synchronization semantics to be *much* better defined.
6.7.4 Global events
Additional definition provided (including a table).
The meaning of ‘analysis point’ is not clear.
7.1.1 Top-level modules
Are multiple top-level modules that contain analog behavior allowed?
7.3 Ports
[Not the right place for this]: need rules for vector versus scalar connections if the entity
is reg rather than a wire type.
7.3.3 Real valued ports
Require considerably more in the way of definition, especially how these interoperate with
existing Verilog-D types, semantics, and syntax.
8.2.{1,2} Domains. Contexts
These sections have been added to provide definitions for following sections.
The concept of variables being associated with a particular domain depending on assignment is
ambiguous.
8.3 Behavioral Interaction
Provides definitions and rules for mixed access and mixed events.
Rules for synchronization are not sufficient to produce portable code - needs definition.
8.3.1 Accessing discrete nets and variables..
‘Bit’ is pretty strange. Results are undefined if any bit values are ‘x’/’z’.
8.3.6 Concurrency
New section(s). [Attempts to] provide rules under which the four subsequent sections are
to be interpreted.
Totally inadequate to write portable code that accesses variables from multiple domains.
This is important since these mechanisms are proposed for constructing connect modules, etc.
Whole area requires some clear semantics and possibly additional synchronization constructs.
8.4 Discipline Resolution
Totally reworked from previous versions. The algorithms described are based on net types
rather than on drivers/loads that appear on the a mixed net.
The source of much disagreement. Antrim AMS has a different view based on the importance
of the entities on the net rather than the declared net types; and an emphasis on accurate
representation of the analog part of mixed nets. I think this whole section will be replaced
by whatever a successful AMS simulator decides to implement.
8.4.3 Connection of continuous-time disciplines
Makes it illegal to have incompatible continuous disciplines on the same net (previously
undefined). Antrim AMS allows this; standard rules for connect module insertion apply.
User has complete control and it’s a useful feature.
8.{5-8} Connect Modules
Modified from previous versions. New syntax (connectmodule). New mechanism for finding
matching connect modules. New block added (connectrules/endconnectrules). New mechanism
provided for reusable connect modules. New syntax provided for uni-/bi-directional connect
modules.
100% incompatible with previous approach. Some of these changes are cosmetic. Others apply
totally different mechanisms from prior LRM. Will need major migration plan to accommodate
present users.
8.10 Driver Access and net resolution
New material or better defined relative to previous versions. Note that these are stated to
be callable from connect modules only.
These functions allow most of a mixed signal resolution function to be implemented.
There are some missing functions, though (e.g. there is no way to discover what change caused
driver_update() to become active). net_resolution() is pretty strange - what does ‘the default’
mean in the explanatory text?
Preferred approach is to insert CBs corresponding to net loads/drivers, not to dream up
smart CBs.
8.11 Supplementary driver access functions
Added on demand to provide at least a back door to enable accurate registration of analog
and digital events (i.e. start analog ramp so that threshold crossing matches digital event).
Necessary but not sufficient (mechanisms for decoupling digital drivers from the mixed net,
etc, are also required). This whole area needs work - perhaps with user community who care
about backannotation, mixed delay calculation, etc.
9.2 Mixed-signal simulation cycle
The information provided about initialization is inadequate to a mixed signal user. This
should be written in terms of Verilog-D initialization semantics, and explain any values
taken by Verilog-D entities during this phase.
10 System tasks and functions
Some changes from previous versions.
The $realtime vs. $realtime(N) mess gets cleaned up by introducing $abstime().
There is potential ambiguity with system tasks with the same name in Verilog-D and Verilog-AMS,
but with two different definitions ($random, possibly); and with system tasks that modify
their argument (for example, some system tasks take and modify a seed value. Does this count
as ‘assignment’ for the purpose of defining the domain of the variable (c.f. 8.2.1)? If so,
does this behavior apply to user system tasks also? How can the simulator determine whether
a system task argument is read-only or is modified by the task?).
Verilog-AMS needs table lookup functions for modeling - add $table & variants here.
11 Compiler directives
Extended from previous versions.
Presumably these are reset by `resetall.
D Standard definitions
The file names have changed from <foo>.h to <foo>.vams.
When? Why?
E SPICE compatibility
Successful implementations will need to be able to import large chunks of legacy
SPICE (including models). The material in the LRM is very Spectre-specific (see the
independent sources, for example).
Additional mechanisms (in particular, global parameter and node features) are
necessary to import SPICE code that uses these, since Verilog does not have these
capabilities.
F Discipline resolution methods
This was added as part of the discussion over net resolution, with the intention of removing
details of the algorithm from Chapter 8, and leaving that chapter generic. It didn’t work
(Annex F looks really odd. One solution would be to simplify Chapter 8, leaving room for
alternate views on mixed nets, and delete Annex F).
-- end --
This archive was generated by hypermail 2b28 : Thu Jan 04 2001 - 11:06:35 PST