Subject: RE: Peter's Question (discipline binding)
From: S. Peter Liebmann (spl@antrim.com)
Date: Tue Jul 31 2001 - 16:34:59 PDT
One advantage of the process bound approach is that if the same exact design
is done with different heirarchy, you will get the same result. On the other
hand, it is clamed that with the port bound approach, one can reduce
the number of interface elements and speed up the simulation (I believe
you can also do that in the process bound result). The aim of the
working group is to resolve the issues you have mentioned since there
seems to be a lot of confusion.
Peter L.
> 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
> ***********************************************************
-- Peter LiebmannAntrim Design Systems, Inc. Tel. 831-430-4804 Fax. 831-430-1904
This archive was generated by hypermail 2b28 : Tue Jul 31 2001 - 16:46:22 PDT