Subject: Re: Thoughts on OOMRs
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Feb 08 2001 - 12:54:52 PST
> From ghelwig@asc.corp.mot.com Thu Feb 8 00:14:48 2001
> Subject: Re: Thoughts on OOMRs
>
> Hello Kevin,
>
> In Verilog-A, an analog net reference is always used structurally, never
> behvaiourally (eg. to access it value). But in Verilog a digital net
> reference is used both structurally and behaviourally. The mechanism is
> not symetrical between the domains. To have a net (also branch)
> reference directly used within a (analog or digital) expression result
> in ambiguity. Does the user mean to access the potential or flow wrt to
> ground? That is why analog probe access function was specified to remove
> this ambigutiy.
Mostly I'm thinking about the Verilog(-D) testbench case where I want to
do a simulation with some modules in an analog mode. I'll assume the user
wants to know the value of the logic in the target module (whether it's
to ground or some other reference would depend on the design).
> Now these proposed lightweight conversion mechanisms then must assume
> that the net/branch access is potential? This is not good!
Sorry, there was a typo - I fixed the web version.
> Specifically, the "b.z = 1;" statement is a digital net assignment,
> therefore the the LHS is expected to refer to digital net, if it is not
> then it is an error. Similarly, the "assign p = b.z;" statement has an
> invalid RHS expression because "b.z" syntax denotes it is as digital net
> reference (not an analog one).
I have a problem with that. If I mix in some parasitics in my simulation,
the net is still (IMO as a user) digital. I expect my digital drive to
be converted into an analog contribution and solved with the parasitics
and as a result I get more accurate timing in my simulation.
But my example was off-the-cuff, more detailed (correct?) examples are
probably necessary for exploring this issue.
Kev.
> Regards
> Graham
>
> Kevin Cameron x3251 wrote:
> >
> > > From imw@antrim.com Wed Feb 7 09:26:10 2001
> > >
> > > The need for a declaration of the net referenced in an OOMR
> > > appears to be purely an artefact of the hierarchical approach
> > > to discipline assignment.
> > >
> > > There doesn't seem to be an inherent need for a declaration:
> > >
> > > module top;
> > > A a();
> > > B b();
> > > endmodule
> > >
> > > module A;
> > > electrical e;
> > > endmodule
> > >
> > > module B;
> > > electrical z;
> > > analog V(z) <+ V(top.A.e); // no ambiguity
> > > endmodule
> >
> > I think you are correct with that example. I was thinking of:
> >
> > module top;
> > A a();
> > B b()
> > C c()
> > endmodule
> >
> > module A;
> > initial b.z = 1;
> > endmodule
> >
> > module B; // replacing a digital module B ?
> > electrical z;
> > analog V(z) <+ I(...);
> > endmodule
> >
> > module C;
> > assign p = b.z;
> > endmodule
> >
> > - you need a discipline in A to insert a d2a and one
> > in C to insert an a2d. As module B is using a base discipline
> > you need to do something like:
> >
> > ...
> > module A;
> > CMOS2V_1M b.z;
> > initial b.z = 1;
> > endmodule
> >
> > ...
> > module C;
> > CMOS2V_PROBE b.z;
> > assign p = b.z;
> > endmodule
> >
> > An alternative method is a C-like "cast" :
> >
> > ...
> > module C;
> > assign p = (CMOS2V_PROBE)b.z;
> > endmodule
> >
> > - which lets you probe the same wire in different
> > ways from the same module.
> >
> > BTW, if anyone wants to probe from procedural verilog
> > testbenches we could (re)introduce quick conversion e.g.:
> >
> > connect function quick_a2d(node)
> > electrical node;
> > quick_a2d = (node > 1.0) ? 1
> > : 0;
> > endfunction
> >
> > connect quick_a2d input CMOS2V_PROBE, output digital;
> >
> > ...
> > @(posedge clock) begin
> > reset = (CMOS2V_PROBE)design.reset;
> > end
> >
> > - I think something like that was in the ealier LRMs as $a2d
> > and $d2a. It's advantage is that no connect module is added
> > (permanently) to the simulation - which reduces memory
> > requirements.
> >
> > Kev.
> >
> > Kev.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Graham Helwig email: A11558@email.mot.com
> ghelwig@asc.corp.mot.com
> Telephone:+61-8-82033532 Fax:+61-8-82033501
> Motorola Australia Software Centre,
> 2 Second Avenue, Technology Park, Adelaide, SA, 5095, Australia
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
----- End Included Message -----
This archive was generated by hypermail 2b28 : Thu Feb 08 2001 - 13:47:49 PST