Subject: Re: Thoughts on OOMRs
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Feb 09 2001 - 10:07:09 PST
> 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
> ***********************************************************
>
>
>
This archive was generated by hypermail 2b28 : Fri Feb 09 2001 - 10:19:48 PST