Subject: Re: Proposal: Deprecate procedural assign-deassign
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Oct 30 2001 - 15:05:44 PST
Stuart Sutherland wrote:
>
> Kevin's description sounds more like the true "continuous assignment", not
> the "PROCEDURAL continuous assignment" that Cliff recommends
> deprecating. The reason I say this is because Kevin keeps referring to
> "wires" and "strengths", both properties of the true "continuous
> assignment" only. It is the confusion between the two statements that
> causes many of us (including me) to feel the seldom, if ever, used
> "PROCEDURAL continuous assignment" should be deprecated. If my assumption
> that Kevin is referring to the true continuous assignment is correct, it is
> yet another argument for deprecating the unused form. On the other hand,
> if Kevin meant "reg" instead of "wire", then there may be a legitimate need
> for the PROCEDURAL continuous assignment.
Actually it's kind of halfway between, it looks like a procedural assignment
but is effectively continuous.
As I said, there is still some debate on syntax/implementation.
> I strongly oppose recommending the Verilog force/release as a replacement
> to the PROCEDURAL continuous assignment. My experience has been that these
> constructs can have a serious impact on simulator performance. They are
> also not well supported in the older PLI TF and ACC libraries--those
> libraries have no way to know when a force is put into effect, and when it
> is released. Finally, when dealing with net types, a force statement
> overrides ALL drivers of a net, which means they are not useful in any type
> of wired logic (except for their intended usage for testing and debugging).
My interest in using an extended force/release mechanism is that it
makes it easier to implement mixed language simulators. The "driver access"
functions in Verilog-AMS are extensions of the digital simulator, and can
be used to translate Verilog driver values to (say) VHDL driver values
which could be resolved in a VHDL domain (maybe through PLI) and the
result driven back with a "force". The reason for wanting a "priority"
associated with the force is that if I added some (say) analog components
to the net I would want to override the VHDL-level force with result from
an A-D conversion (without having to modify the code doing the VHDL-level
force).
Just food for thought :-)
Regards,
Kev.
> At 11:38 AM 10/30/2001, Kevin Cameron x3251 wrote:
> > > From owner-vlog-pp@eda.org Tue Oct 30 10:37:29 2001
> > > X-Sender: cliffc@mail.sunburst-design.com
> > > To: vlog-pp@eda.org, verilog-ams@eda.org
> > > From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
> > > Subject: Re: Proposal: Deprecate procedural assign-deassign
> > >
> > > At 02:22 PM 10/29/01 -0800, Kevin Cameron x3251 wrote:
> > > > > Subject: Re: Proposal: Deprecate procedural assign-deassign
> > > > >
> > > > > I also agree.
> > > > > --Steve Grout
> > > >
> > > >I seem to remember that the current methodology for driving the
> > > >resolved value onto signals from auto-inserted A/D conversion modules
> > > >in Verilog-AMS is something like an assign from procedural code
> > > >(I'm not sure how anyone is actually implementing it).
> > > >
> > > >If it's to be deprecated can we extend force/release to have some
> > > >kind of optional strength/priority to cover the functionality
> > > >needed in A/D converters etc?
> > > >
> > > >Kev.
> > >
> > >
> > > Can anyone from the Verilog-AMS team shed light on the above statement?
> >
> >I'll clarify:
> >
> >The way that Verilog-AMS allows you to mix analog and digital behavior
> >on a wire is by disconnecting the digital drivers of the wire and
> >(auto) inserting an D->A conversion module which probes the drivers
> >to calculate an appropriate analog contribution (voltage or current)
> >which gets handled by the analog (spice-like) solver. The calculated
> >analog value for the wire is then driven directly onto the digital
> >wire by an A->D module (using an assign-like construct).
> >
> > > In Verilog-1995 and -2001, procedural assign statements are made to
> > > variable types (such as regs or reals) and variable types do not have
> > > strengths. Only net types have strengths.
> > >
> > > The procedural assign statement also does not resolve with other
> > procedural
> > > assign statements. In Verilog, last procedural assign statement wins and
> > > takes control of the variable until another procedural assign statement
> > > makes an assignment or until a deassign statement, which causes the
> > > assigned variable to hold its last assigned value until the next normal
> > > procedural assignment changes the variable. Truely 'tis an ugly construct!
> > >
> > > Did Verilog-AMS change this behavior? Am I missing something in this
> > > discussion?
> >
> >There didn't seem to be a final solution for the syntax of the assign-like
> >construct in the A->D modules that everyone was happy with, so I was
> >thinking we could just do a general purpose mechanism in V++, e.g. use
> >force/release with some extra priority information indicating what is
> >doing the forcing (behavioral code,PLI,debug,A->D etc.) and which force
> >takes priority if there is more than one.
> >
> >A general purpose mechanism could be used for interfacing to more simulation
> >environments than just Verilog-A.
> >
> >Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Tue Oct 30 2001 - 15:07:27 PST