delay_or_event_control construct in IEEE 1364 Verilog 
Author Message
 delay_or_event_control construct in IEEE 1364 Verilog

What is the syntax of a delay_or_event_control construct in IEEE 1364 Verilog?

Is it
        delay_or_event_control ::=
                  delay_control
                | event_control
                | "repeat" "(" expression ")" event_control
or is it
        delay_or_event_control ::=
                  delay_control
                | event_control
?

In the draft spec., page 9-3 and appendix A say the first form; page 9-17
says the second form.  (First of all, why is the same non-terminal defined
twice in the text?  And why is it defined _differently_?)

Which form is it supposed to be?

If it's the first form, the grammar is ambiguous.  Consider this:  If it's
the first form, then how does one parse these tokens?:


Specifically, is that
        1) a loop_statement whose controlled statement is the procedural_ti-


                and whose controlled statement is "a = b;"), or is it
        2) a procedural_timing_control statement whose delay_or_event_control

                is "a = b;"?

(The interpretation makes a difference:  waiting for N edges on X and then
assigning once versus assigning N times, once for each edge on X, right?.)

If it's the second form, then this is not legal:


Is that supposed to be legal?  If so, then something is really screwed up in
the specification.

Or is it a third case?  (Hint:  Cadence "Verilog Language Reference Manual"
Version 1.0 (March 1991) didn't have this problem.)  Who broke IEEE 1364's
grammar?

Daniel
--
Daniel S. Barclay      Compass Design Automation, Inc.

        "Its leaders were supposed to serve the country
         But now they were paying no mind
         'Cause the people got fat and grew lazy
         Now their vote is like a meaningless joke" - Steppenwolf, "Monster"



Mon, 21 Sep 1998 03:00:00 GMT  
 delay_or_event_control construct in IEEE 1364 Verilog



        In my opinion the section 9 of the spec is fine.  Pages 9-17
through 9-22, READ together in one sitting give a concise, complete
introduction to the behavorial timing and event synchronization
constructs provided by the Verilog language.  The section starts out
simply, and develops the concepts, introducing more complex syntax
along they way.

        The section starts out with a complete BNF. Then the
sub-section on the timing and events synchronization begins with the

introductory sub-section, a minimized BNF snippet is included on page
9-17 taht includes only these two constructs. Pages 9-17 and 9-18 then
discuss in detail, with justification and examples, the ins and outs

        Page 9-18 introduces named events, with examples and
justification for this concept, as well as BNF snippets for the
declaration of, as well as the triggering of a named event.

        On 9-19 the event OR operation is introduced, with examples
and justification.  Later on that page the level sensitive event
control concepts in introduced, again, with examples, justification
and BNF snippets.

        Finally, on page 9-20, the intra-assignment timing control is
introduced, which is a feature of the language which can be used to
modify the behaviour of some of the previous concepts just described.
This is not a new feature; it was in the language before Gateway was
sold to Cadence. At this point in the specification, a BNF snippet is
included which refines the description on page 9-17, showing where the
repeat syntax is legal.  Since this is a useful and perhaps confusing
concept, three pages of justification and examples are included,
eludicating the purpose of this concept in the language.

Quote:

> What is the syntax of a delay_or_event_control construct in IEEE 1364 Verilog?

> Is it
>    delay_or_event_control ::=
>              delay_control
>            | event_control
>            | "repeat" "(" expression ")" event_control
> or is it
>    delay_or_event_control ::=
>              delay_control
>            | event_control
> ?

> In the draft spec., page 9-3 and appendix A say the first form; page 9-17
> says the second form.  (First of all, why is the same non-terminal defined
> twice in the text?  And why is it defined _differently_?)

> Which form is it supposed to be?

> If it's the first form, the grammar is ambiguous.  

> Consider this: If it's the first form, then how does one parse these
> tokens?:



        This is parsed as an intra-assignment event delay, the third
leg of the first BNF you have included. Again the first form is merely
part of a gentle introduction.

Quote:

> Specifically, is that
>    1) a loop_statement whose controlled statement is the procedural_ti-


>            and whose controlled statement is "a = b;"), or is it

        The grammar for looping constructs does describe such a
production; semantic analysis is required by your tool to favor the
intra-assignment delay.  Note that if you wanted the other form, you

Quote:
>    2) a procedural_timing_control statement whose delay_or_event_control

>            is "a = b;"?

        Semantic analysis requires you to reduce the ambiguity in
favor of item 2.

Quote:

> (The interpretation makes a difference:  waiting for N edges on X and then
> assigning once versus assigning N times, once for each edge on X, right?.)

> If it's the second form, then this is not legal:


> Is that supposed to be legal?  If so, then something is really screwed up in
> the specification.

        This form is legal, and again pages 9-20 though 9-22 describe
the required behaviour.

Quote:

> Or is it a third case?  (Hint:  Cadence "Verilog Language Reference Manual"
> Version 1.0 (March 1991) didn't have this problem.)  Who broke IEEE 1364's
> grammar?

        You really should honor the proprietary trade secret non
disclosure that I recall having seen on a copy of the document you are
refering to.

        A less troublesome comparison might be to the OVI Verilog
Language Reference Manual, version 1.0, November, 1991.  This document
contains all the information that Cadence elected to release to the
world when it transfered the control of the Verilog-HDL language to an
outside standards body (Open Verilog International).

        Nearly all of the text in pages 9-17 through 9-22 of IEEE-1364
came from pages 8-22 through 8-30 of the OVI 1.0 LRM.  

        The BNF in the appendix is different in the two
specifications, and while it is the case that the OVI BNF does not
include the ambiguity you describe, it also does not describe the
behaviour of the language.

        What I mean is that examination of the OVI BNF would lead one

times, awaiting a change of X before each assignment (and indeed, it
appears you were so lead to believe). However; in order to obtain
Verilog-XL compatability, one is required in implementing the OVI
specification to notice page 8-28 through 8-30, and modify the
behaviour of ones simulator appropriately.  (Conversly, one might only
determine the inconsistancy by listening to customer complaints about
incorrect behaviour of your simulator :-)

        As to who _changed_ IEEE-1364's grammar, it was the IEEE 1364
working group, following one of the basic princples of that effort:
document the defacto standard, the behaviour of Verilog-XL 1.6

        Unfortunately, an ambiguous grammar was used to describe the
language.  This should be corrected.

Quote:

> Daniel

--
Michael McNamara

--
Michael MacNamara



Sat, 26 Sep 1998 03:00:00 GMT  
 delay_or_event_control construct in IEEE 1364 Verilog

Quote:

> What is the syntax of a delay_or_event_control construct in IEEE 1364 Verilog?

> Is it
>    delay_or_event_control ::=
>              delay_control
>            | event_control
>            | "repeat" "(" expression ")" event_control
> or is it
>    delay_or_event_control ::=
>              delay_control
>            | event_control
> ?

> In the draft spec., page 9-3 and appendix A say the first form; page 9-17
> says the second form.  (First of all, why is the same non-terminal defined
> twice in the text?  And why is it defined _differently_?)

> Which form is it supposed to be?

There is nothing wrong with my IEEE 1364 draft on this particular construct.  In
fact they are the same provided that you flip from page A5 to A6.  I think
the format is the main reason of confusion.

- Show quoted text -

Quote:

> If it's the first form, the grammar is ambiguous.  Consider this:  If it's
> the first form, then how does one parse these tokens?:


> Specifically, is that
>    1) a loop_statement whose controlled statement is the procedural_ti-


>            and whose controlled statement is "a = b;"), or is it
>    2) a procedural_timing_control statement whose delay_or_event_control

>            is "a = b;"?

> (The interpretation makes a difference:  waiting for N edges on X and then
> assigning once versus assigning N times, once for each edge on X, right?.)

> If it's the second form, then this is not legal:


> Is that supposed to be legal?  If so, then something is really screwed up in
> the specification.

Both are legal, and they mean very different thing:

does the asignment n time, while



is the event control.

- Show quoted text -

Quote:

> Or is it a third case?  (Hint:  Cadence "Verilog Language Reference Manual"
> Version 1.0 (March 1991) didn't have this problem.)  Who broke IEEE 1364's
> grammar?

> Daniel
> --
> Daniel S. Barclay      Compass Design Automation, Inc.

>    "Its leaders were supposed to serve the country
>     But now they were paying no mind
>     'Cause the people got fat and grew lazy
>     Now their vote is like a meaningless joke" - Steppenwolf, "Monster"



Mon, 05 Oct 1998 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. IEEE 1364 Verilog PLI-TSC Request for Enhancements, Errata

2. Verilog 2001 (1364-2001 IEEE Standard) Question

3. Gate level primitives in IEEE 1364 Verilog standard...

4. 1364 delay_or_event_control, revisited :-(

5. IEEE 1364 and Verilog-A Courses in Feb in Silicon Valley

6. Verilog is now IEEE 1364 standard

7. Verilog HDL (IEEE PAR 1364) Working Group Meeting

8. IEEE 1364 Verilog PLI-TSC Request for Enhancements, Errata

9. 1364-95 Verilog vs Verilog-XL

10. $monitor and IEEE Std 1364

11. Q: Coding style in violation of IEEE-1364?

12. IEEE-1364

 

 
Powered by phpBB® Forum Software