Subject: Re: Thoughts on OOMRs
From: Pragmatic C Software (sjmeyer@pragmatic-c.com)
Date: Thu Feb 08 2001 - 17:25:37 PST
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.
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.
/Steve
in Verilog 2000, but it needs to be inserted at point of module definition:
(*
module <something>
-- Steve Meyer sjmeyer@pragmatic-c.com
This archive was generated by hypermail 2b28 : Thu Feb 08 2001 - 17:29:28 PST