Subject: Re: Proposal: Deprecate procedural assign-deassign
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Mon Oct 29 2001 - 14:22:57 PST
> 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.
> David Smith wrote:
> >
> > So, what is the voting process? I agree by the way as well.
> >
> > David
> >
> > -----Original Message-----
> > From: John Sanguinetti [mailto:jws@forteds.com]
> > Sent: Monday, October 22, 2001 1:04 PM
> > To: vlog-pp@eda.org
> > Subject: Re: Proposal: Deprecate procedural assign-deassign
> >
> > Again, I agree.
> >
> > At 8:42 AM -0700 10/22/01, Clifford E. Cummings wrote:
> > >Deprecate procedural assign-deassign
> > >
> > >I don't know the formal wording but I propose that we vote to
> > >deprecate procedural assign-deassign statements. Some of the most
> > >gosh-awful models have been written with these infinitely abusable
> > >statements that at first glance appear to be similar to a continuous
> > >assignment statement.
> > >
> > >I think every new Verilog user at some time has placed an assign
> > >statement inside of an always block where no assign statement was
> > >required and either got lucky on the behavior or confused.
> > >
> > >The concept of taking control of a variable with a procedural assign
> > >statement that updates the LHS anytime the RHS variable changes,
> > >even if the RHS variable is not in the sensitivity list is pretty
> > >strange. The concept that last assign wins is also confusing and
> > >restoring other non-assign procedural assignments to activity after
> > >a deassign statement is similarly confusing. I have worked with
> > >customers that had to translate their old assign-deassign Cadence
> > >Synergy code into synthesizable code for Synopsys and Synplicity
> > >with multiple assign statements spread throughout a large model.
> > >Ultimately, I could not figure out what the assign priorities were
> > >within the code.
> > >
> > >The force-release commands do the same thing but they are rarely
> > >abused, not synthesizable by any tool, and rather clearly documented
> > >to be mostly for debugging purposes.
> > >
> > >Having both assign-deassign and force-release where the latter has
> > >higher priority and can also assign to wire types has always been
> > >confusing to new users.
> > >
> > >I would like to see this committee take a stand for sanity and
> > >deprecate procedural assign-deassign.
> > >
> > >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 //
> > >//*****************************************************************//
>
> --
> --Steve Grout
> Design Verification, CAD Methodology/R&D, Manager, Individual
> Contributor -
> Design Verification, CAD System, Database, Flows, Tools,
> Integration,
> and Support for both Digital and Analog/Mixed-Signal Design Teams.
> 101 Kenneil Court
> Apex, NC 27502
> Phone: 919-303-5066
> email: grouts@flash.net
> http://www.flash.net/~sgrout/Personal/resume2001.pdf (or
> doc,rtf,txt)
>
>
This archive was generated by hypermail 2b28 : Mon Oct 29 2001 - 14:24:37 PST