Subject: Re: Peter's Question (discipline binding)
From: S. Peter Liebmann (spl@antrim.com)
Date: Tue Jul 31 2001 - 14:18:12 PDT
It is by no means clear that Antrim's method of connect block insertion, which
is explained in Kevin's document, is a subset of what is in the LRM. Unless
this is explained as part of the LRM, I see no reason not to incorporate
Kevin's proposal in the LRM.
Peter L.
> 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 - 14:28:42 PDT