Subject: Re: Thoughts on OOMRs
From: Jonathan Sanders (jons@cadence.com)
Date: Thu Feb 08 2001 - 01:27:39 PST
Kevin,
I'm not sure of the starting point of this conversation, maybe I'm
stepping into the middle of the discussion but I will try to help clarify
this from our experience.
OOMRs are not defined during elaboration but are evaluated (this is
probably what you meant. They are essentially like undeclared ports
and I sort of view them as that white wire you sometimes see soldered
on the back of a pc board (i.e. jumper wire).
These are used for more than probes from digital testbenches although
that clearly is one use. In a netlisting environment these are used to
connect to global signals or even global parameters. We do this in
several of our solutions.
As far as discipline resolution the key issue is with respect to the
global signals aspect. Here I have my supply voltages defined and
in any module that I want to connect to the global supplies (without
using of ports) I would reference them using OOMRs, for example:
module netlist ();
ablk1 b1 (sig);
ablk2 b2 (sig, aout, globalsigs.vcc, globalsigs.gnd);
dblk1 b3 (aout, dout, globalsigs.vcc, globalsigs.gnd);
endmodule
module globalsigs();
electrical vcc, gnd;
ground gnd;
supply #(.dc(5), .trise(10u)) v1(vcc);
endmodule
module dblk1 (in, out, vp, vn);
...
module supply (out);
...
..
In the above case there is an OOMR connection that connects
a digital signal from in dblk1 to the analog signal defined in the
globalsigs module. The question is does the connect module
get connected across the port of dblk1 (netlist.b3.vp) or across
the port of supply found in globalsigs (globalsigs.v1.out)?
Where the OOMRs for discipline statement come into play is when
you want to either debug a circuit or force a connect module at a certain
location (typically to protect resolution from going into characterized IP).
In the debug case you might create a special connect module called
a2d_debug and a special connect rule such as:
connect a2d_debug input electrical, output logic_debug;
Then if you set the discipline of a net to logic_debug using OOMRs then the
connect module that would be used would be your debug connect module.
Removing the OOMR puts things back to normal.
As for IP protection, if you set the discipline to the top level nets of a
synthesized
ASIC then detail discipline resolution will not allow the analog discipline to
traverse down into the ASIC putting connect modules onto every pin of every
digital gate of the ASIC. That is allowed but if you characterized the
ports at
the ASIC level then you don't need to put all of those connect modules into the
design.
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
At 06:05 PM 2/6/01, Kevin Cameron x3251 wrote:
>OOMRs are defined during elaboration. They are essentially
>like "undeclared" ports in their target modules - and can
>be handled that way as far as semantics go. However, as OOMRs
>are often used as "probes" from digital testbenches it is
>probably not a good idea to let the target end assume the
>default discipline for the target module, as that would
>possibly cause an inappropriate A2D converter insertion.
>I think we need a syntax for defining a special "probe"
>discipline that can be found from the default discipline for
>a module so that only a "light weight" A2D is inserted e.g.:
>
> discipline TSMC33_18 probe LOGIC_3_3V; // Use a 3.3V
> // logic monitor
>
>Otherwise if there is A/D conversion without considering the
>OOMR the OOMR should attach to it's digital output, and after
>that it should probably fail.
>
>Using an OOMR to drive an analog net from digital will also
>require a (digital) discipline to determine the D2A. I would
>take the default from the driving context, and if that is
>unsatisfactory we may need to extend the module syntax to
>include discipline definition for OOMRs as well as local
>nets (a mechanism which could be used for probes too).
>
>Kev.
>
>--
>National Semiconductor
>2900 Semiconductor Drive, Mail Stop D3-677, Santa Clara, CA 95052-8090
***********************************************************
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 : Thu Feb 08 2001 - 01:35:47 PST