Re: [sv-bc] Keywords

At 10:56 AM 4/26/2005, Michael McNamara wrote:
>  (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. )

"and therefore not allowed" gets us right back to history, intent and 
debate and does not move us toward the future. I would drop this argument 
in the interest of proposing a solution.

>  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).
>
>  -----------------

I am not sure I am ready to force configs into separate files for reasons 
stated in my previous email message.

The other objection is "... special flag, although this is allowed."

The top-level config recognition that Kev proposed would require simple 
changes by implementation "N" and implementation "M" and the changes seem 
to be small and reasonable.

One implementation would now allow "config" to be used within the 
boundaries of module-endmodule, macromodule-endmodule and 
primitive-endprimitive.

The other implementation would now read top-level config-endconfig without 
the use of a command line switch.

Seems like relatively simple concessions on the part of both 
implementations (spoken by someone who has never implemented a Verilog tool!)

>  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

Regards - Cliff

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