Re: [sv-bc] Keywords

-- On Apr 26 2005 at 08:41, Clifford E. Cummings sent a message:
 > To: sv-bc@eda.org
 > Subject: "Re: [sv-bc] Keywords"
 > Hi, Kev -
 > 
 > I think all the vendors could do as you have suggested, but most if not all 
 > would prefer to have a single list of keywords.
 > 
 > Turns out, the biggest offender is the keyword "config," which is the one 
 > we need to descend into the next level of keywords.  Cadence implemented 
 > most of Verilog-2001 and then got around to implementing configs. Now they 
 > have the problem of customers using all types of Verilog-2001 capabilities, 
 > but some of the Verilog-2001 code uses "config" as an identifier, so it is 
 > not as easy as telling the tool that this block of code is Verilog-1995, as 
 > I suggested in an earlier email message.

 Colleagues: Let us please raise our level of civility here. 'Cadence
 ... then got around to implementing configs' is rather shrill, don't
 you think?

	[Ok, I am numbing my sensitivity meter...]
 
 Cliff, you note that '...some of the Verilog-2001 code uses "config"
 as an identifier'.  This is precisely the issue.  We have existing
 designs.
 
 We have two implementations of the standard, one that treats config
 blocks as design elements restricted to unique files (and hence does
 not reserve their keywords), and one that allows them to appear
 anywhere in the input stream (and hence does reserve the keywords).

 There is much back and forth here over history and intent.  Language
 experts have presented compelling lines of reasoning backing both
 implementations.

 I am much more interested in the future.  

 What is the use model that delivers good engineering practise and
 design reuse?  Let us agree on that, while doing our best to support
 existing designs.  

 We have a set of existing designs that include config blocks in the
 input stream, and hence require reservation of config, cell, et
 cetera.  We have another set that require configs to be in a unique
 files, and hence do not impose these keyword reservations, and hence
 allow use of these keywords as variable names throughout the design.

 Therefore we have a situation where a given design that is deemed
 compliant by one implementaion, can not be run on the other. This is
 bad.  We could pick one or the other interpertation as right, but the
 damage has already been done.  The designs exist. The implementations
 exist.

 Looking forward, most seem to agree from an engineering perspective
 that keeping config blocks in their own file makes the most sense.

 (Quick Poll: does everyone agree to this?) 

 The disagreement is that in one implementation, the file containing
 the config must be presented to the tool with a special flag which
 tells the tool that it will be reading a config block.  The other
 implementation allows the file to appear without introduction, among
 the source files containing modules and primitives.

 (Quick Question: Are config blocks allowed by that implementation
 allowed to appear anywhere in the module & primitive source text, or
 must they appear only outside of module & primitive definitions?  I
 presume the later; however the BNF A 1.3 starts with:

 source_text ::= { description }
 description ::= module_declaration
	       | udp_declaration

 leaving the placement of config_declaration blocks unspecified, and
 therefore not allowed. )


 Proposal: We release an interpretation of 1364-2001c or 1364-2005, or
 insert this text into 1364-2005 (I am not sure what changes are in
 order at this point of the life of the project).

 -----------------

 The production "configuration_declaration" shall only appear in a
 file consisting of configuration declarations, comments and
 directives.  Such files need not be introduced to the compiler with a
 special flag, although this is allowed.  Instead, the compiler must
 examine the first non comment, non directive token of each file, and
 if it is "config", it shall treat the file as one that contains
 config blocks, and parse the file using the BNF defined in Section A
 1.2.  If the token is "module" "macromodule" or "primitive", the tool
 shall treat the file as one containing module and primitive source
 text, and parse the file using the BNF defined in Section A 1.3.

 Special rule: Existing practice permits the specification of modules
 and primitives to span files. In the case where a tool opens a new
 file when in the middle of reading a module or primitive definition,
 in shall not perform the check for the first non comment, non
 directive token, but shall continue processing the file using the BNF
 defined in Section A 1.3.

 -----------------

 As a result, with this small change to implementation "N" where it
 examines the first token of freshly opened files, all designs
 supported currently by implementaion "N" and by implementation "M"
 can be processed by implementation "N".

 As a result, with this small change to implementaion "M" where it no
 longer reserves the keywords "config" et al in module & primitive
 text, all designs supported currently by implementaion "M" and by
 implementation "N" can be processed by implementation "M".

 Comments?

 -mac 

 > One lesson to be learned from this is to create tools that flag all
 > keywords as un-implemented features so engineers don't start using
 > some keywords and later discover that additional keywords were
 > reserved but it is now difficult to separate new features from
 > recently implemented features.

 The verilog mode (available at <http://www.verilog.com>) does this
 today!

 > 
 > Regards - Cliff
 > 
 > At 12:02 AM 4/26/2005, you wrote:
 > >Just as a matter of interest: whose compilers can't handle limited context 
 > >keywords?
 > >
 > >I usually write recursive descent parsers that can handle tokens
 > >being keywords or not depending on context. It seems that life
 > >would be easier if "keyword status" could be limited to particular
 > >scopes for particular words e.g. there is no good reason that
 > >keywords for configuration should have any special meaning outside
 > >of a config block.
 > >
 > >Kev.
 > 
 > ----------------------------------------------------
 > 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, SystemVerilog, Synthesis and Verification Training
 > 
 >