Subject: RE: Prioritization issues:
From: David Smith (david_smith@avanticorp.com)
Date: Wed Aug 15 2001 - 10:04:56 PDT
I think that before we start getting into the technical discussions we need to follow Vassilios's process. Once we, as a group have decided the priorities and the order to start addressing the issues we can get into technical discussions one at a time. I will wait to consider your responses and comments in that forum.
I do appreciate the effort to make the responses below. I just want to not get side tracked by trying to respond to things as they come up as opposed to a planned approach.
Regards,
David
-----Original Message-----
From: Kevin.Cameron@nsc.com [mailto:Kevin.Cameron@nsc.com]
Sent: Wednesday, August 15, 2001 1:50 AM
To: verilog-ams@eda.org
Cc: David Smith; Ernst Christen; John Shields
Subject: Re: Prioritization issues:
David Smith wrote:
We have worked up some responses. I am sending only the top issues that we feel need to be address, some comments as appropriate, and an indication on those we agree or disagree with (even if not a priority).
The basis for this analysis is the following:
* the standard should be implementable by any development organization and be compatible with other vendor implementations. Seems simple, but with the Verilog-D underpinnings, one key is getting a well defined simulation cycle that is integrated with 1364 spec. The unified text should be reviewed.
* somewhat related, the simulation cycle should be compatible with the VHDL-AMS simulation cycle to allow effective language interoperability. This does not mean that Verilog-D and VHDL-D differences should be coerced in any way, of course. But the interaction between analog solver time and digital time should be compatible. If the standards, for example, respond to the time of analog threshold crossing by requiring the event time to be calculated differently for the two languages, that would be a bad result.
* Issues with the Verilog-A subset are less important, particularly as they relate to compatiblity with existing customer designs. We want clarity in the spec.
* to get forward progress, by not trying to do everything in one revision. It is a bad idea to add features before disambiguating those that are defined. It is not black and white, but, for example, taking on the back annotation agenda now seems ill advised. A better LRM will result in a more timely manner if we do not overdilute the effort. There are just not enough people competent to work on this.
The following document indicates our responses. It only covers our first 21 priorities. But that is enough to get working on. We do have some comments on non-prioritized items as well as indication of agreement or disagreement.
We have provided both Excel and HTML formats.
Regards
David
Some feedback (original HTML indented):
1
Truncating vs Rounding when
converting Analog to Digital
times
1
N
Neither rounding nor truncating is correct. The
best solution is to either except the number
(exact match) or raise to the next time slice).
This is to eliminate back tracking the digital
simulator. It is also consistent with 1076.1
The problem is that Verilog works with a variable time-step (set by the user). Zero-delay
events can be handled at the "real" time in a separate delta (and should be), but delays
like '#1' get put into the digital event queue which doesn't do real-time scheduling.
2
Driver-receiver Segregation
21
While it appears to be an extended form of signal
resolution it is actually something quite
different. The solution actually results in a
partitioning of the net into multiple networks
with different resolution schemes being used on
different sections (analog net resolves using
analog drivers with an analog value, digital net
resolves using only the digital values).
The function of the D->A convertors is to translate digital drivers into an analog contributions
which can be solved together, and the result of that calculation is then converted back to
the digital domain via A->D convertors. Resolution takes place in the domain of highest
(sufficient) accuracy.
6
External Module Definitions
(ENH)
11
The problem is actually worse. If Verilog-AMS is
meant to replace spice netlist then the issue
stated is clearly a problem. Having a declaration
mechanism (as suggested) does help to find the
source. Unfortunately having the source is not
enough. Each spice is different in its definition
of the element parameters. A worse problem is the
inability in Verilog-AMS to relate the process
parameter information (model card) to any other
system variables. While this is only a small
problem with Verilog-2001 it will become
significant when Verilog-plus-plus is released
(next year). How much of a Spice netlist
replacement is Verilog-AMS meant to be? I believe
the Verilog 2001 syntax for include is: incluide
<models.h>; The 'include<models.h> seems
inconsistent.
Verilog uses regular double quotes for including file (""), but doesn't come with any
"standard" include files. The suggestion was to follow the C inclusion mechanism
for standard include files (<>) that come with a Verilog-A - i.e. the default disciplines
and math constants, and any other header files delivered with a Verilog-A[MS]
simulator.
7
Back-Annotation (ENH)
N
In my opinion it is better to have proposed solutions for this and any other problems that
will have to be addressed at some time in the future (at Accellera or the IEEE), so that
we don't create unnecessary problems and re-working. The proposed solutions do
not necessarily have to appear in the next LRM. (Re-netlisting is not an acceptable
approach to back annotation).
93
Filters for foreign languages
N
This is not a language issue but an environment
issue. There are insufficient semantics to
translate any spice netlist into Verilog-AMS.
Filters are not possible without defining the
missing semantics.
Filters are definitely possible without supporting all the quirks of all the Spice type
simulators. This mechanism was proposed primarily to handle direct use of SPF
from existing tools - SPF being a simpler subset of Spice netlist. It was also intended
to give a formal backward-compatibility mechanism for things not handled by
either the rep-stop or external-module mechanisms (e.g. Mast and Spectre).
If Verilog-A[MS] is missing any functionality required for supporting the translation
of Spice or other languages please point out the deficiencies so that we can fix them.
95
Representation Stops
N
This has little change of being adopted by the1364
committee or the IEEE standardization process.
Why?
I would be happy to see alternative proposals for any of the external-module,
rep-stop or foreign language handling mechanisms - they were done a while
ago as a starting point.
Regards,
Kev.
This archive was generated by hypermail 2b28 : Wed Aug 15 2001 - 10:10:44 PDT