Subject: Revised issues list
From: Ian Wilson (imw@antrim.com)
Date: Mon Feb 05 2001 - 15:13:06 PST
This is a reduced list of issues, with proposals or workarounds, and
with suggested 'bins'.
--ian
Verilog-AMS 2.0 LRM Issues (revised)
Ian Wilson
Date: 02/04/01
3.4.3.{2,3} Empty disciplines; undeclared nets [bin: disciplines]
Description allows for netlists with uncommitted interconnect.
The intention is clear although the explanatory text is highly ambiguous.
Alternate proposal: treat 'wire' (and other intrinsic Verilog types) as
pseudodisciplines. This supports the LRM examples (such as connect modules
of the wire_to_electrical variety without requiring changes to user libraries).
3.5 Real net declarations [bin: wreal]
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.
Proposal: move this to an 'optional features' Annex.
3.6 Default discipline [bin: disciplines]
This applies to discrete disciplines only. Requires further definition (e.g. relationship
with `reset_all).
Proposal: change name (?default_discrete_disc) to make clear. Add to set of things
cleared by `reset_all.
4.4.1 Restrictions on analog operators [bin: ?]
The 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).
Proposal: add table of default values for analog operators, etc.
4.5 Analysis dependent functions [bin: ?]
Meaning of some cases (see also initial_step) is not clear for AC analysis, etc.
Proposal: add words to make clear what happens on first/any/last steps of AC
analysis, and what happens to sequential code such as $fopen().
6.7 Events [bin: MS]
Constructs like @(posedge clk or cross(V(1), 1)) require analog/digital synchronization
semantics.
Proposal: provide rewriting rules for new constructs in terms of existing
structural and single-domain language.
7.3.3 Real valued ports [bin: wreal]
Require considerably more in the way of definition, especially how these interoperate with
existing Verilog-D types, semantics, and syntax.
Proposal (see above): move to Annex.
8.2.{1,2} Domains. Contexts [bin: MS]
The concept of variables being associated with a particular domain depending on assignment is
ambiguous.
Proposal: disallow cross-domain access to variables.
8.3 Behavioral Interaction,
8.3.6 Concurrency [bin: MS]
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.
Proposal: either disallow mixed domain access to variables, or add constructs
to allow deterministic code to be written in the concurrent Verilog environment.
For example: add semaphore to language.
8.4 Discipline Resolution [bin: disciplines]
Proposal: there are at least two competing practical view on this: the 'islands'
approach, and the 'common view' approach. Put something simple in Chapter 8, and
defer implementations to an Annex.
8.4.3 Connection of continuous-time disciplines [bin: 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.
Proposal: remove restriction.
8.10 Driver Access and net resolution [bin: MS]
These are defined to work in connect modules only. Connect modules are not allowed
to be instantiated as normal modules. Result: how can a user debug a connect module?
Proposal: remove restrictions on 'manual' instantiation of connect modules. Define
results of driver access functions in different use cases.
10 System tasks and functions [bin: ?]
Proposal: $table has been offered. May want to convert to analog operator status
or add to an Annex.
D Standard definitions
The file names have changed from <foo>.h to <foo>.vams.
When? Why?
E SPICE compatibility
Material in Annex is Spectre-specific (see syntax for sources for example).
Proposal: use something neutral like SPICE3.
Additional constructs required to import existing Spice in an automated way -
in particular, global nodes/global parameters.
Proposal: details of these as extensions available if there's interest.
-- end --
This archive was generated by hypermail 2b28 : Mon Feb 05 2001 - 15:15:48 PST