Re: Thoughts on OOMRs


Subject: Re: Thoughts on OOMRs
From: Jonathan Sanders (jons@cadence.com)
Date: Thu Feb 08 2001 - 23:53:46 PST


Kevin,

see below,

Jon

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 - 00:00:48 PST