Subject: From John Shields..
From: Ian Wilson (imw@antrim.com)
Date: Mon Dec 18 2000 - 11:02:33 PST
-----Original Message-----
From: jshields@analogy.com [mailto:jshields@analogy.com] On Behalf Of
John Shields
Sent: Sunday, December 17, 2000 2:18 PM
To: Ian Wilson; verilog-ams@eda.org
Subject: Re: Conference call times
Ian Wilson wrote:
> Did it again: call-in time is from 1pm PST.
>
> --ian
Hi Ian,
Now that I know your intentions, I'll always assume west coast time :) I
will not be able to attend on Monday. As I was the person who requested
the call-in, I apologize for my conflict.
Let me tell you what I would like to do regarding Verilog-AMS. I
will represent Avant! interests, that much is clear. There are others
here who will pay attention, but for now, will not devote time
unless encouraged by me to review something or if they get hooked
by a compelling discussion on the reflector.
I was most interested in the IEEE standardization effort and I am still unclear
whether that will move forward. One reasonable course of action is
to defer it until Accelera promotes a 2.1 or 3.0 revision that clears up
some of the current defects. Organizationally, that it is my most
important question to the group.
My personal interest is in PLI (vpi-ams) and having a clean formal
information model unified with Verilog-2000. (I suspect I will be as
lonely as Bill Hobsen was, in that regard. :) However, I would not press to do
any further work on PLI until we have the basic LRM work staffed and
organized. When we agree it is time to work on PLI, I intend to volunteer quality
time.
I would like to first focus on cleaning up ambiguities in the spec, a further
LRM cleanup effort. I would be willing to study the Verilog-2000 LRM
and the OVI Verilog-AMS 2.0 documents toward that end and devote some
regular time. IMHO, The BNF should be a first priority. I am looking to you for
access to the latest documents in pdf or frame, as appropriate.
I am loathe to encourage work on changes/enhancements to the 2.0 spec that are
not driven by ambiguity resolution, at least until the cleanup effort is organized,
staffed, and progressing. My concern is that the work will get fragmented.
Some of Kevin's issues falls in this category for me, though he raises some
good issues. If there is consensus to focus on one or more of Kevin's issues first,
I will accept it, but we all have limited bandwidth.
Finally, I disagree with one of Jon Sander's philosophies, if taken to excess.
The idea of relying on the 1364 spec for Verilog-D issues and defering to it
is generally smart. We do want to write a unified comprehenisve LRM. I do think,
for clarity and rationale's sake, we will have to cross the line. I believe, for
example, that the simulation cycle should be written as a unified, comprehensive
statement. That may indeed find fault with the 1364 spec as part of its
outcome, too. If so, I would prefer to use this writeup to carry issues back to the 1364
steering committee for clarification. There is nothing wrong with finally partitioning the
simulation cycle description to 1364 and 1364.1, after you know you got it
right. I do not have any fantasies about changing 1364, though. For example,
I recognize the intentional 0 delay event ordering issues as part of bedrock of Verilog's
definition.
Perhaps there are other areas where crossing that line will best serve the goal
of making it possible to produce consistent implementations of Verilog-AMS simulators and
reusable models across the industry. I would love it if we could hyperlink the specs
and avoid replicated text, but I am not expecting this to happen.
In summary, a black and white statement that we will defer to 1364-D spec without
referencing it carefully or duplicating some text for readability of 1364.1 is short-sighted
IMHO. Especially where the 1364 spec is recognized as defective, and it is important to our
goals, I don't think it is healthy to simply say we will stand on "Jello" and build from there.
I hope this is useful input, and I apologize again for being unavailable tommorrow.
Regards,
John Shields
Avant! Corporation
This archive was generated by hypermail 2b28 : Mon Dec 18 2000 - 10:54:42 PST