Subject: BNF Questions? - FrameMaker BNF Should be the golden BNF file
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Apr 25 2002 - 17:11:55 PDT
Hi, All -
I believe some problems still exist in the BNF(? - detailed below).
I also agree with Stu that all BNF changes should now be forwarded to him
as snippets for him to change unless someone wants to own the BNF
FrameMaker file. Converting the FM file to text is pretty simple to do but
going from the hypertext file back to FM is a pain. The FM file should be
the master file. FM-to-text and forward to Stefen for subsequent generation
of the hypertext version.
Regards - Cliff
Section A.1.3 - I believe the current BNF requires that timeunit and
timeprecision be listed after all port declarations and before any other
statement. Also, timeunit must precede timeprecision according to the BNF.
I saw no such restriction in the draft text.
Section A.2.1.1
The third production is parameter type ... but type is not a keyword and
has no cross reference.
parameter_declaration ::=
parameter [ signing ] { packed_dimension } [ range ]
list_of_param_assignments
| parameter data_type list_of_param_assignments
| parameter type list_of_type_assignments
Stu has put a comment in the BNF in section A.6.4 about the function call
being a void function call. This comment should be removed. I suggest that
a new BNF definition for void_function_call be created in section 8.2 just
like the function_call already in section 8.2, and then use
void_function_call in section 6.4 and wherever it and a function call are
legal.
Still a problem(?)
At 12:25 PM 12/4/01 +0000, Peter Flake wrote:
>I have noticed mistakes I made.
>
>The syntax allows a modport in a module, because of the
>interface_or_generate_item.
Is this still required? It does not appear to be in the BNF
At 08:04 PM 3/17/02 +0000, Peter Flake wrote:
>4. Clarify packing of structures
>
>Since May, when the donation document was prepared, Co-Design has found
>the need to have both packed and unpacked structures and unions, like
>packed and unpacked arrays. So it is proposed to amend BNF lines 331 and
>332 as follows:
>
> | struct [packed][ signing ] { { struct_union_member } }
> | union [packed][ signing ] { { struct_union_member } }
At 12:14 PM 4/23/02 -0700, Stefen Boyd wrote:
>>Section A.6.4: Delete comment. Add footnote explaining that this is a
>>void function call.
>
>3) Added footnote 7
Again, a separate void_function_call definition should be made instead of
adding this note (which has not yet been added).
>>Section A.9.3: Delete comment. Replace with footnote
>
>4) Added footnote 8
I don't see the comment or the footnote.
Were the following BNF changes going to be added?
At 01:28 PM 4/22/02 -0400, you wrote:
>This is the proposed bnf for the assertion control system tasks: $asserton,
>$assertoff and $assertkill. The intention is for these to be invoked
>similarly to $dumpvars.
>
>Please let me know if there are any issues.
>Thanks,
>-Tom
>
>assertctrl_tasks ::=
> assert_task ;
> | assert_task ( levels [ , list_of_modules_or_assertions ] ) ;
>
>assert_task ::=
> $asserton
> | $assertoff
> | $assertkill
>
>list_of_modules_or_assertions ::=
> module_or_assertion { , module_or_assertion }
>
>module_or_assertion ::=
> module_identifier
> | assertion_identifier
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, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Thu Apr 25 2002 - 17:13:53 PDT