Subject: Re: Proposal: Deprecate procedural assign-deassign
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Oct 30 2001 - 13:27:38 PST
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.
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).
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.
>
> > Regards - Cliff
> >
> >
> > //*****************************************************************//
> > // Cliff Cummings Phone: 503-641-8446 //
> > // Sunburst Design, Inc. FAX: 503-641-8486 //
> > // 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
> > // PMB 501 Web: www.sunburst-design.com //
> > // Beaverton, OR 97005 //
> > // //
> > // Expert Verilog, Synthesis and Verification Training //
> > //*****************************************************************//
> >
> >
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Tue Oct 30 2001 - 13:20:52 PST