Subject: Re: Thoughts on OOMRs
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Feb 12 2001 - 17:50:52 PST
> From jons@cadence.com Mon Feb 12 16:44:29 2001
>
> See below,
>
> Jon
...
> I think you are confused on OOMRs. An OOMR in the port list is just a connection
> between two nets while other uses of OOMRs like disciplines are just hierarchical
> references. Thus if you want to set the discipline on both sides of a OOMR
> connection then two discipline statements would be needed, one for each net.
>
> >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.
>
> Once again, OOMRs connections are not nets/wires but maybe better treated
> as a port that connects two nets/wires. You can set the discipline of any net
> from any module using the OOMR (hierarchical reference) path in a discipline
> statement.
Agreed - you need two statements. The reason I was using a different syntax is
that you could want to set the discipline of an OOMR in a module you reach via
an OOMR. E.g. a child module (say 'top.child') may reference a global signal
(say 'clocks.refresh'), if 'clocks' is not in 'child' the path
'top.child.clocks.refresh' is invalid, while 'top.child:clocks.refresh' would
indicate the correct net.
It comes into play when I have a (legacy) Verilog-D testbench probing into
Verilog-A versions of modules and I need to add discipline information, e.g.:
module testbench;
...
@(posedge clock) begin
if (dut.b1.clk2 == 1) print (....);
end
...
dut (...); // Device under test
endmodule
`ifdef __VAMS_ENABLE__
module discs;
discipline CMOS_3V_PROBE testbench:dut.b1.clk2; // set testbench view
discipline CMOS_3V dut.b1.clk2; // set DUT net (maybe
// override electrical)
endmodule
`endif
- or something like that, best discussing it at a whiteboard :-)
Each driver and receiver of a net may have a different discipline and the OOMR
discipline assignment mechanism needs to handle that.
> > > You should also know that this does not have to be placed in the top..
> >
> >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?
>
> As far as I know and we certainly support it since VerilogXL says that Verilog can
> have unlimited top level modules and thus this is not a problem, at least for Cadence.
Good - not a problem then.
> > > 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?
>
> If you do allow / expect (I do) that users will edit their testbenches when analog is
> brought into the design then the above macro can help make the testbench usable
> for digital or ams designs. E.g.
>
> `if __VAMS_ENABLE__
> vsource #(.dc(5), .ampl(5), .freq(10.2K)) v1 (input, gnd);
> `else
> assign input = 1;
> `endif
I meant more that it doesn't help much with fixing the legacy code - although you can
disable the extra modules with the discipline assignments easily (as above).
As someone keen on design automation, in particular the reuse of Verilog-A & Verilog-D
in larger AMS designs, I'd like to avoid any requirement for regenerating source (it
causes problems with data management) and would prefer to be able to use `include and
indirect mechanisms.
Kev.
This archive was generated by hypermail 2b28 : Mon Feb 12 2001 - 18:29:41 PST