Subject: RE: Peter's Question (discipline binding)
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Wed Aug 01 2001 - 10:07:18 PDT
> From david_smith@avanticorp.com Tue Jul 31 16:37:54 2001
>
> 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.
In the abstract view of the simulator, processes drive signals (wires) and
the connection of a wire to other processes is determined by the ports.
For A/D converter insertion you need to associate a "type" with the driver
(or receiver) interface of the processes, we re-used "disciplines" which
are used with port declarations for that rather than introduce an extra
process-level syntax. Disciplines were introduced for carrying Verilog-A
simulation attributes for wires (which end up as single nodes in the
analog simulation).
The issue with process vs. port binding is where the A/D convertors get
inserted in the design hierarchy, and how it interacts with back-annotation.
Since back-annotation in Verilog-A will require breaking the port
connections to insert routing parasitics and R-L-C wiring it is desirable
to keep A/D converters as close as possible to their associated process
- which is what happens with process-binding, port-binding semantics are
that A/D converters are inserted on the "top side" of the port and it is
not at all clear how they would be wired when back-annotation is applied.
Kev.
> 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 : Wed Aug 01 2001 - 10:17:13 PDT