Subject: Re: Thoughts on OOMRs
From: Jonathan Sanders (jons@cadence.com)
Date: Sun Feb 11 2001 - 00:54:52 PST
At 09:47 AM 2/9/01, Kevin Cameron x3251 wrote:
> > From pragc@www.tdl.com Thu Feb 8 18:13:17 2001
> >
> > Quoting Kevin Cameron x3251 (Kevin.Cameron@nsc.com):
> > > > From jons@cadence.com Thu Feb 8 01:41:39 2001
> > > >
> > > [See web for full text]
> > >
> > > 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.
> > >
> >
> > Verilog 2000 has deprecated compiler directives except for backward
> > compatibility and replaced them with attribute mechanism except for
> > backward compatibility with the original Verilog 95 (and Cadence)
> directives.
> >
> > I think the problem of dealing with source order compiler directives was
> > voted one of the worst parts of Verilog in some of the Verilog 2000
> surveys.
> > Worst problem is that behavior becomes dependent on order of source files.
>
>Wouldn't argue with that.
>
> > This
> > > `set_discipline LOGIC3V_PROBE netlist.dblk1:netlist.b3.vp,...
> >
> > would be written as attribute:
> >
> > (* discipline_set= "LOGIC3V_PROBE",
> > LOGIC3V_PROB = netlist.dblk1:netlist.b3.vp, ... *)
> >
> > But it is not clear what attribute should be attached to. I think this
> wold
> > be design wide attribute but I am not sure if Verilog 2000 has such
> attributes.
>
>It's difficult to attach beacause it's done after the fact, there was an
>alternative non-preprocessor syntax for use in modules (which works better
>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
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?
BTW, You can use the __VAMS_ENABLE__ macro to allow this testbench to also
be used
on purely digital designs.
Jon S.
This archive was generated by hypermail 2b28 : Sun Feb 11 2001 - 01:01:54 PST