Subject: Re: Thoughts on OOMRs
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Feb 12 2001 - 12:31:34 PST
> From jons@cadence.com Sun Feb 11 01:01:49 2001
>
> At 09:47 AM 2/9/01, Kevin Cameron x3251 wrote:
.....
> >if you are re-using the hierararchy in something else):
> >
> > module netlist ();
> > ...
> >
> > discipline LOGIC3_PROBE
> > dblk1:netlist.b3.vp;
> >
> > endmodule
> >
> >- but once again you can't do that with legacy Verilog, so you still need a
> >global mechanism. Attributes might work, but I'm not sure whether everyone
> >wants to/will implement the attribute system - vs. a single directive.
> >
> >Kev.
>
> Kevin, the above discipline declaration is a viable way although the line
> should be:
>
> discipline LOGIC3_PROBE dblk1.netlist.b3.vp; // assuming top blk is dblk1
There are two ends on an OOMR - I was (sort of) assuming "netlist" module end
was "digital" and the far end should be LOGIC3_PROBE, so I was thinking of a
syntax like -
<discipline spec> [<instance path>:]<net in instance context>
{,[<instance path>:]<net in instance context>};
- i.e. the "<instance path>:" gives the context in which you are defining
the discipline.
I think you are saying that the syntax (as it stands) sets the far end so the
"instance path" is unnecessry - but then how do I set the local end.
Also, I might want to set the discipline on an OOMR in another module, and I
don't think the current OOMR evaluation handles that.
> You should also know that this does not have to be placed in the top level module
> (the legacy Verilog testbench) but can be placed in any module, the reason for
> the full hierarchical path. No matter what you need the ability to put this type of
> information into some part of the source code. It seems that you are OK approach
> as long as it does not require editing the legacy Verilog, correct? Also, I understand
> and agree that we should not force the editing of existing Verilog source code for the
> design but are you implying that testbenches should also not be edited if you want
> to do AMS? if so why?
There is still a (small) problem in introducing extra modules if you can only have
one "top" - i.e. an extra module annotating disciplines would have to be placed under
an existing top module (that you might not want to edit).
Does Verilog 2000 allow multiple tops?
> BTW, You can use the __VAMS_ENABLE__ macro to allow this testbench to also be used
> on purely digital designs.
>
> Jon S.
I'm not sure how that helps?
Kev.
----- End Included Message -----
This archive was generated by hypermail 2b28 : Mon Feb 12 2001 - 13:22:19 PST