Subject: RE: Peter's Question (discipline binding)
From: David Smith (david_smith@avanticorp.com)
Date: Tue Jul 31 2001 - 16:19:03 PDT
Greetings,
I have recently joined the Verilog-AMS group and admit to not being completely up to speed on all the issues. I have read through the documents referred to below and the related email.
It is not clear to me what the advantage of one method over the other is. Can anyone point me to a place where the use of the "process bound" approach (and what the "basic" and "detail" modes of resolution mean when used with the "process bound") is described in terms of user benefits? I do see some of the differences in terms of how they are implemented but it is not clear what the usefulness of each approach is.
Thanks for any clarification you can provide.
David
David W. Smith
Architect
> Avant! Corporation
9205 SW Gemini Drive
Beaverton, OR 97008
Voice: 503.520.2715
FAX: 503.643.3361
Email: david_smith@avanticorp.com
http://www.avanticorp.com
-----Original Message-----
From: Jonathan Sanders [mailto:jons@cadence.com]
Sent: Tuesday, July 31, 2001 12:36 AM
To: Kevin Cameron x3251; Verilog-AMS@eda.org
Cc: spl@antrim.com
Subject: Re: Peter's Question (discipline binding)
Kevin,
While you make a good attempt to try to find a solution here the fundamental
problem is that we still have not received justification to support more
than one
resolution method. It was argue back in the 2.0 effort that the Antrim
proposal was
a subset although in my meeting with Ian he argued that in theory you could
duplicate all of the functionality of what is in the LRM if not by software
then by
methodology. I believe he is correct although the methodology for several
of the
features seemed a bit painful in a top down flow from my remembrance.
Likewise we both agreed (I sent Vassilios and Dennis B a summary report) that
all of the concerns of what was in the LRM actually did not hold true once we
went over them. Again everything in the Antrim proposal can be done in
what is
in the LRM. The "exception" is something we removed due to a digital use model
but certainly could be added back as it is not a technical issue. The
issue is the
ability to put CM's on the ports of digital primitives (Ian wanted to do
this inside of
a mixed structural and behavioral module). The reason why it is currently
not allowed
is as follows:
-Digital primitives have no named ports which means we need to have names
for these
ports.
-Digital engineers NEVER use digital primitives as what we analog folks
think of as
primitives. They always put wrappers around them and thus they
would never
run into this problem. Of course what we are finding is that
analog guys/gals
don't want no stinking wrappers and want to use and, nand, nor,
.... as if it
were a resistor.
Anyway we removed the section in the LRM to define names for these ports
back around
1.7 but it certainly could be added back to address this issue.
So I go back to the why do we need a second method?
The reason I say this is that both Ian and I agreed that few if any vendor
would implement
both since architecturally they become two major projects that provide
"duplicate" functionality.
You cannot easily do both in one quick swoop so most vendors would pick one
and then we
are stuck with ..... is this a standard?
Both methods have their "advantages" and both have their "holes" but we
have one that
is in the standard and has been their from day 1 (ok maybe not day one but
it was in 1.0).
Our rule in 2.0 was make what is in the standard work and if we can't then
consider alternatives
but for some reason this issue seems to have never been held to that standard.
Jon
At 11:19 AM 7/30/2001, Kevin Cameron x3251 wrote:
>You'll find the proposal here -
>
>http://www.eda.org/verilog-ams/hm/0139.html
>http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0002/fllwup-2.html
>
>
>Regards,
>Kev.
>
>--
>National Semiconductor
>2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090
***********************************************************
Jonathan L. Sanders
Product Engineering Director
Custom IC Solutions
Cadence Design Systems, Inc.
555 River Oaks Pkwy
San Jose, CA. 95134
INTERNET:jons@cadence.com Tel: (408) 428-5654 Fax : (408) 944-7265
***********************************************************
This archive was generated by hypermail 2b28 : Tue Jul 31 2001 - 16:24:21 PDT