Subject: Re: Peter's Question (discipline binding)
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Wed Aug 01 2001 - 09:48:08 PDT
> From: "Jonathan Sanders" <jons@cadence.com>
>
> 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.
The justifying argument has been made several times - you just choose to ignore it.
> It was argued 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.
The "port bound" discipline approach is a subset of of the "process bound" approach
that applies in some cases - not vice versa.
> 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.
Frankly (as co-chair of this committee), I would consider that document as irrelevent
until it has been reviewed by the rest of the committee.
> 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.
There is currently a fixed limited set of digital primitives, creaing names (if you
need them) is not much of an issue - digital designers don't have to use them.
> -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.
The primitives in analog vs. digital netlists issue is addressed in the "representation
stop" proposals.
> 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?
The original Verilog-AMS A/D boundary handling proposal used process-binding because
it is necessary for handling back-annotation and related issues. Cadence decided to
go with port-binding for reasons of backward compatibility with the existing product's
approach.
Within a Verilog simulator there is very little extra work involved in implementing
both methods.
> 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.
I was there at day 0 doing this stuff. Process-binding the disciplines has no holes, port
binding them does: it will not work properly with back-annotation and design flows that
use tools that discard hierarchy.
Kev.
> 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 - 09:56:32 PDT