Subject: Re: Thoughts on OOMRs
From: Jonathan Sanders (jons@cadence.com)
Date: Sun Feb 11 2001 - 00:41:13 PST
Kevin,
I'll try not to debate this over email as we may be saying the same things but
I have a question. You say that it is essential that "existing (my words)"
verilog-D
testbenches work without changes. How many digital testbenches currently probe
into analog behavioral code? I suspect you just want the same ability if
the referenced
block is now replaced with a analog or mixed signal one but then again
maybe I am
missing your concern.
As for dropping things, I reject your assessment that we were aggressive on
dropping
necessary functionality. The meetings were open as were the decisions and
the few
things we dropped were openly debated to determine if they were 1) required
to make
the language useful, 2) if alternative methods (usually using the rest of
the language) were
feasible, 3) were there technical issues that needed to be
answered. We only dropped
a few big items (generate, parasitic, lightweight CMs) and it was
determined that lightweight CMs could be covered by existing constructs in
the language. As mentioned
before, a large number of issues for these CMs were opened and no one provided
resolutions for them, remember your rock is a proposal and after several
months no
proposal came. And during all of the meetings no one once delivered an
argument of
"necessary" functionality nor did our investigations find any "necessary"
functionality.
This in not to say interesting and useful functionality is not missing as
we decided to
delay dynamic and global parameters as well as support for analog
parasitic's to the
IEEE effort to name two items.
Jon
At 10:07 AM 2/9/01, Kevin Cameron x3251 wrote:
> > From jons@cadence.com Fri Feb 9 00:01:50 2001
> >
> > Kevin,
> >
> > see below,
> >
> > Jon
>
>IMO it is essential that top-level (legacy) Verilog-D testbenches
>work with no/minimum changes, and I think that requires some light-weight
>D2A mechanism that works automatically.
>
>`default_discipline is not precise enough for use with OOMRs, and (as
>I said before) you can't always modify the module source. If someone
>wants to suggest alternative syntax for `set_discipline thats OK with me.
>
>
>I think folks were a bit aggressive on previous clean-ups and disposed of
>necessary functionality (possibly because the rationales got lost). There
>were good reasons for a lot of the original stuff, and it needed refined
>rather than thrown out.
>
>Kev.
>
> > At 12:52 PM 2/8/01, Kevin Cameron x3251 wrote:
> > > > From jons@cadence.com Thu Feb 8 01:41:39 2001
> > > >
> > >[See web for full text]
> > > >
> > > > Hopefully this helps clarify some of your questions although it
> probably
> > > > will result in additional questions. I am out of the country right
> now
> > > but if
> > > > you still have questions on this or a view on which of the two
> ports the CM
> > > > should be placed let me know.
> > > >
> > > > Jon
> > >
> > >IMO the rule for inserting A/D converters is that D2As are created
> > >in the context of the driving process, and A2Ds in the context of the
> > >context of the receiving process. The problem we have is that currently
> > >we can't attribute disciplines to the ends of OOMRs to get the right
> > >A/D converters (I couldn't see the mechanism in your postings).
> >
> > I think the next time we do a face to face meeting that I'm in town for
> > we can hopefully clear this one up as I think one of us is confused and
> > I'm not sure who.
> >
> > >We also have two possible types of OOMR access from Verilog-D, static
> > >(through ports) and dynamic (from behavioral code), the latter type
> > >probably requires a "light weight" A/D conversion for reading, but
> > >writing is really awkward to define (and should probably be considered
> > >illegal for now).
> >
> > Since we are only in the cleanup and clarification phase we should
> certainly
> > make this illegal for now as we are not suppose to be adding
> stuff. There were
> > a lot of issues with lightweights IEs as I mentioned before and when
> the time
> > comes we will need to address all of those issues and determine if this is
> > really a necessary feature. For now my vote is illegal.
> >
> > >Also, in the case where we are using legacy (non-editable) Verilog-D,
> > >we need a mechanism for back-annotating disciplines to OOMRs from
> > >outside the refering module too. There used to be a compiler directive
> > >for setting disciplines on untyped ports, we can reintroduce it - e.g.:
> > >
> > > `set_discipline LOGIC3V_PROBE netlist.dblk1:netlist.b3.vp,...
> > >
> > >- which sets the dblk1 end of the OOMR.
> >
> > As mentioned in one of my replies there is a compiler directive
> > `DEFAULT_DISCIPLINE
> >
> > but as mentioned by Steve, compiler directives suck, especially in most
> of today's
> > compiled bases solutions. Thus we also implemented an elaborator
> switch to set
> > the default discipline. This is probably not something that you
> necessary want to force
> > into the source code. But again, this was just our way of solving this.
> >
> > Again, looking at your example above you can also use OOMR declarations.
> > e.g.
> >
> > module top();
> >
> > LOGIC3V_PROBE netlist.dblk1:netlist.b3.vp, ...... ;
> >
> >
> >
> > >Kev.
> >
> > ***********************************************************
> > Jonathan L. Sanders
> > Product Engineering Director
> > Mixed Signal and Physical Verification 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
> > ***********************************************************
> >
> >
> >
***********************************************************
Jonathan L. Sanders
Product Engineering Director
Mixed Signal and Physical Verification 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 : Sun Feb 11 2001 - 00:48:33 PST