RE: Proposal: Deprecate procedural assign-deassign


Subject: RE: Proposal: Deprecate procedural assign-deassign
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Oct 30 2001 - 13:35:15 PST


At 10:55 AM 10/30/2001, Dennis Brophy wrote:

It is nice to see this, but I can attest from someone that has already implemented these features, they tend to stay.  Yes, you remove them from the spec, but the industry continues to use them.  (And yes, I know one of the world's leading semiconductor companies which continues to use defparam's and will most likely do so even if dropped by Verilog-ACE.)

-Dennis


Please correct me if I misunderstand the concept of deprecating something.  I thought it meant that the construct still exists in the language, but implies the construct is obsolete and should be avoided.  Compliant software tools will still support the construct, because it is still part of the standard.  Software tools MAY generate a warning message that the construct is deprecated, and an alternate style should be used.

If my understanding is correct, I am all for deprecating defparam and procedural continuous assignments.  If deprecating means the constructs are actually removed from the standard, then I oppose the action, because it makes the language non backward compatible.

Stu

-----Original Message-----
From: Vassilios.Gerousis@Infineon.Com
[mailto:Vassilios.Gerousis@Infineon.Com]
Sent: Tuesday, October 30, 2001 12:18 AM
To: vlog-pp@eda.org
Subject: RE: Proposal: Deprecate procedural assign-deassign

Hi guys,
        I believe that John And Cliff had trouble with those items. That is why the enthusiasm
you see Dave.
        We need to get things into formal gear. I believe that Stu is creating a list of deprecating items. We will discuss them one by one and then formally vote on the matter. Since Stu is under the water, maybe Cliff can volunteer to put a list together as we go with

the review process. This way Stu can focus on the Verilog-ACE.

Vassilios

       

-----Original Message-----
From: David Smith [mailto:david_smith@avanticorp.com]
Sent: Monday, October 29, 2001 7:50 PM
To: 'John Sanguinetti'; vlog-pp@eda.org
Subject: RE: Proposal: Deprecate procedural assign-deassign

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       //
>//*****************************************************************//

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:26:13 PST