Subject: Re: LRM 2.0 Issues list
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jan 04 2001 - 16:05:27 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.
>
> -ian
I added a link in the issues page:
http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/
- but I think we need to break this list down and track the items individually
(if they are not already covered) so that we can prioritize them.
Do we have a soft-copy of the 2.0 LRM yet?
More comments below...
> 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.
From my personal recollection this was unnecessary and could be covered by signal flow
semantics and there was never a proper statement of the requirement it served. Also, if it is
a purely digital construct we shouldn't be adding it.
> 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.
See - http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0001/fllwup-1.html
> 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?
This is probably another Verilog-2k issue, although I would definitely
agree it is a useful feature - particularly if you want to include
back-annotation described in Verilog-A[MS].
> 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.
Can you restate that one? - What's the issue with reg vs. wire?
[ In Verilog-D (as far as I can tell) the difference between a 'reg' and a 'wire' is that the
processes in the scope of the 'reg' declaration share a single driver - but I've never seen
a good description of the difference. Anyone have one? ]
> 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.
As above - what was the original requirement?
> 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.
Definitely IMO, see 'Note' in -
http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0002/fllwup-1.html
> 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.
Agreed. It was proposed before but rejected by Cadence.
> 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?
Mixed-signal driver resolution is similar to resolution in VHDL in that you convert up to more
accurate domains (through D2As) and propogate the result computed in the most accurate (analog)
back down (through A2Ds) to the less accurate. So connection modules were originally conceived
as being like VHDL port type-conversion functions, and the original proposal was just to let
the output of a connection module be the resolved value for A2Ds, and the analog contribution
equivalent to the digital driver(s) for D2As. The reason for having connection modules rather
than functions is that you usually need to preserve state in the conversion.
Using a seperate syntax for "net resolution" does allow more manual approaches (if you remove
restricting it to connect modules), but is (IMO) unnecessary.
The driver-access functions are purely digital, and are useful in purely digital simulation
for building models with bidirectional I/O and capictor models etc., we should probably
sort them out with other Verilog-2k issues in conjunction with BTF.
> Preferred approach is to insert CBs corresponding to net loads/drivers, not to dream up
> smart CBs.
I'm not sure what you mean by that, but...
I would have preferred to use VHDL style implicit signals (e.g. <signal>'driver[<index>]'event,
<signal>'driver[<index>]'next_event'time, and <signal>'driver[<index>]'next_event'value).
But it didn't fit well with Verilog syntax, so we went for a more query based approach - I'd
be happy to see an proposal for the implicit signal approach.
> 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.
The work was mostly done before (and then discarded), it shouldn't be hard to resurrect
and revise :-)
> 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.
[Issue #5 - http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0005/index.html
& #1 - http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0001/index.html]
I think it is useful to consider the/an entire analog solver process as being much the
same as a digital process but with piece-wise-linear (PWL) inputs and outputs. It simplifies
the user model of a Verilog-AMS simulation, and lets us break the issues down some:
1. How should Verilog-D behave if events can occur at real (off-tick) times?
2. How should PWL ported processes interact with discrete valued processes
(interpolation etc.)?
3. How should PWL ported processes interact with each other? (there can be
disjoint sets)
4. How do we initialize a PWL process?
NB: each analog process can be considered as an independent PWL process with rules for (#3)
being applied.
> 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?
In original discussions system include files were supposed to be indicated
by using angle brackets (<>) rather than quotes ("") to discriminate them from
user includes (in line with C/C++) - what happened to that?
> 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.
See issue #6 - http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0006/index.html
> 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 --
Kev.
This archive was generated by hypermail 2b28 : Thu Jan 04 2001 - 16:10:29 PST