Re: 1364.1 pragmas


Subject: Re: 1364.1 pragmas
From: John Michael Williams (jwill@AstraGate.net)
Date: Thu Aug 29 2002 - 16:37:55 PDT


Hi Cliff.

I am not convinced by the reasons you give.
One funny observation below.

But, thanks for the explanation.

-- 
                         John
                     jwill@AstraGate.net
                     John Michael Williams

Clifford E. Cummings wrote: > > Hi, John - > > Attributes were added to Verilog-2001 to move vendors away from parsing > comments. > > For all practical purposes, attributes are more or less comments that > should be examined for commands (more or less what you have said below). > > It seemed pretty silly to require that a tool search all comment strings in > a design to see if instructions had been passed to a tool. Attributes are a > way of indicating that this comment may hold valuable information. > > Have you ever used a comment like "// synopsys will compile this > differently", intending a comment but causing a Synopsys tool to abort with > a syntax error? I have.

Yes. I spent an hour once, trying to convince a synthesis developer that allowing comment directive users to insert spaces after the comment delimiter was not a good idea. This was a different tool. Because sw developers wanted users to be able to write arbitrarily formattable comment DIRECTIVES, we got a tool that would confuse directives with ordinary comments. But, this has nothing to do with standards. And, it could be corrected easily in a good Std.

> > Synplicity will read all Synposys comments but Synopsys will not read all > Synplicity comments. I once had a Synopsys employee complain that > Synplicity benchmarked against Synopsys code and recognized all of the > Synopsys comments but then Synplicity gave the customer code with > Synplicity comments that Synplicity optimized very well but Synopsys tools > did not (because Synopsys does not recognize Synplicty comments). 1364.1 > and attributes are intended to set a standard for pragmas that all tools > will recognize and thereby increase portability. Now you done have to code > the model with // exemplar parallel_case // synopsys parallel_case and // > synthesis parallel_case. > > Standard pragmas are a great idea. How we chose to implement them for > 1364.1 is up for debate. > > Regards - Cliff > > At 07:47 AM 8/29/02 -0700, John Williams wrote: > >Hi Cliff. > > > >Clifford E. Cummings wrote: > > > > > > At 04:21 PM 8/28/02 -0700, you wrote: > > > ... My take on attributes from Verilog-2001 > > > days was that we were trying to get vendors away from parsing comments ( > > > //synopsys full_case) and provide a mechanism to make Verilog source code > > > useful to tools other than just simulators (or synthesis tools). > > > ... > > > >WHY are you "trying to get vendors away from parsing comments?" > > > >Comments are the only syntactic commonality guaranteed to > >be shared among all simulation or synthesis tools, including > >Verilog, VHDL, SystemC, C, and even Pascal. Actually, > >the 1364.1 attribute construct is in the form of > >a Pascal comment! > > > >By embedding synthesis directives in comments, the > >directives, if nothing else, are totally portable. > >By being strict about the exact format of an > >embedded directive, accidental reading of a real > >comment as a directive can be minimized. > > > >I'm not saying the goal of shifting synthesis > >directives to language-specific constructs is wrong, > >but I don't see any good reason for it, and there seems > >to be at least one serious disadvantage (nonportability). > >-- > > John > > jwill@AstraGate.net > > John Michael Williams > > ---------------------------------------------------- > Cliff Cummings - Sunburst Design, Inc. > 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 > Phone: 503-641-8446 / FAX: 503-641-8486 > cliffc@sunburst-design.com / www.sunburst-design.com > Expert Verilog, Synthesis and Verification Training



This archive was generated by hypermail 2b28 : Thu Aug 29 2002 - 16:39:58 PDT