wait statements in functions 
Author Message
 wait statements in functions


|>
|> Can anyone help me with the following questions?
|>
|> Appendix A of the LRM(87) says:
|>
|>   subprogram_statement_part :=
|>     { sequential statement }
|>
|> Am I wrong if I think technically this means that a wait statement is
|> allowed in a function?
|>
|> But then in section 8.1 it says "it is an error if a wait statement
|> appears in a function subprogram".
|>
|> Is the first definition an error? Are there any other sequential
|> statements that are not allowed in functions?
|>
The syntax diagrams in the appendix just specify syntax. Whether or not
a particular construct is possible or not within the particular context,
is described in the sections dealing with the construct. That is:
section 8.1 has precedence to the syntax specification.

As far as the usage of wait in a function is concerned, the passage
in 8.1 says (LRM'93, but this hasn't been changed):
"It is an error if a wait statement appears in a function subprogram, or in
a procedure that has a parent that is a function subprogram. Furthermore, it
is an error if a wait statement appears in an explicit process statement that
includes a sensitivity list, or in a procedure that has a parent that is such
a process statement."

As for the definition "parent": B.179: "A process or a subprogram that contains
a procedure call statement for a given procedure or for a parent of the given
procedure."

So: translated into understandable language (though I think the style has been
much improved since 87):

1. You mustn't have a wait in a function.
2. You mustn't have a wait in a process which already has a sensitivity list.
3. You may have a wait in a procedure in the following case: If you would not
   call the procedure, but copy and paste its body text (ignoring declarations
   and parameter passing changes) to the place where it is called, then
   the resulting code must remain valid VHDL (and thus obey to rule 1. and 2.)

As to other limitations that exist with functions:
There are a number of restrictions, but I fear for you that you have to read
the LRM with care to find them out, as not all restrictions are in chapter 8.
A function mustn't have side effects (in VHDL'93 it is more complicated
as there are specific "IMPURE" functions that actually allow this),
and they mustn't call a procedure that has such side effects; functions must
always terminate with a "return expression" statement, not with a "return" only;
also you may not have out or inout parameters with a function.
There may be other limitations I may have forgotten.

--

|  |   / GMD-SET German National Research  | Phone: (+49) 2241 14 2448
|__|  /  Center for Computer Science       | Fax:   (+49) 2241 14 2342
|  | /   Schloss Birlinghoven              | Had a nightmare yesterday:
|  |/    53754 St. Augustin, Germany       | My system started up with
                                           | ... Booting vmunix.el ...



Mon, 03 Mar 1997 19:24:20 GMT  
 wait statements in functions

Can anyone help me with the following questions?

Appendix A of the LRM(87) says:

        subprogram_statement_part :=
          { sequential statement }

Am I wrong if I think technically this means that a wait statement is
allowed in a function?

But then in section 8.1 it says "it is an error if a wait statement
appears in a function subprogram".

Is the first definition an error? Are there any other sequential
statements that are not allowed in functions?

--
Natalie Kershaw (Hardware Engineer) C.I.S.R.A.
1 Thomas Holt Drive
North Ryde NSW 2113



Mon, 03 Mar 1997 15:00:34 GMT  
 wait statements in functions

Quote:


>|>
>|> Can anyone help me with the following questions?
>|>
>|> Appendix A of the LRM(87) says:
>|>
>|>       subprogram_statement_part :=
>|>         { sequential statement }
>|>
>|> Am I wrong if I think technically this means that a wait statement is
>|> allowed in a function?
>|>
>|> But then in section 8.1 it says "it is an error if a wait statement
>|> appears in a function subprogram".
>|>
>|> Is the first definition an error? Are there any other sequential
>|> statements that are not allowed in functions?
>|>
>The syntax diagrams in the appendix just specify syntax. Whether or not

(deletion ...)

don't you think the syntax should exclude those possibilities? of course the
LRM says a lot more than the syntax diagrams, but it is awkward to work with a
set of syntax with so many precedences. the syntax i am working with has
"subprogram_sequential_statement" which has no "wait" in it. period.

(deletion ...)

Quote:
>a particular construct is possible or not within the particular context,
>is described in the sections dealing with the construct. That is:
>section 8.1 has precedence to the syntax specification.

(deletion ...)

Quote:
>--

>|  |   / GMD-SET German National Research  | Phone: (+49) 2241 14 2448
>|__|  /  Center for Computer Science       | Fax:   (+49) 2241 14 2342
>|  | /   Schloss Birlinghoven              | Had a nightmare yesterday:
>|  |/    53754 St. Augustin, Germany       | My system started up with
>                                           | ... Booting vmunix.el ...




Thu, 06 Mar 1997 03:40:18 GMT  
 wait statements in functions


: >|> Appendix A of the LRM(87) says:
: >|>
: >|>     subprogram_statement_part :=
: >|>       { sequential statement }
: >|>
: >|> Am I wrong if I think technically this means that a wait statement is
: >|> allowed in a function?
: >|>
: >|> But then in section 8.1 it says "it is an error if a wait statement
: >|> appears in a function subprogram".
: >|>
: >|> Is the first definition an error? Are there any other sequential
: >|> statements that are not allowed in functions?
: >|>
: >The syntax diagrams in the appendix just specify syntax. Whether or not

: (deletion ...)

: don't you think the syntax should exclude those possibilities? of course the
: LRM says a lot more than the syntax diagrams, but it is awkward to work with a
: set of syntax with so many precedences. the syntax i am working with has
: "subprogram_sequential_statement" which has no "wait" in it. period.

While there are certain semantic restrictions that the syntax could represent,
not all semantic restrictions are expressible syntactically.  For example,
the syntax for a variable assignment statement is:

    variable_assigment_statement ::= target := expression;

Nowhere does it say that the target must consist of a variable or of an
aggregate of all variables, nor does it say that the type (and subtype) of the
target and the type (and subtype) of the expression must be the same, etc.

Even if the grammar expressed the semantic restrictions that it could, it would
be even larger than it is now.  As a result, IMHO, it would be much harder, not
easier to understand.

--Paul

--

Menchini & Associates|                           |prove their worth by
2 Davis Dr./POB 13036|    voice: 919-990-9506    |hitting back."
RTP, NC  27709-3036  |    fax:   919-990-9507    |         -- Piet Hein



Fri, 07 Mar 1997 04:17:08 GMT  
 wait statements in functions


Quote:



>: >|> Appendix A of the LRM(87) says:
>: >|>
>: >|>         subprogram_statement_part :=
>: >|>           { sequential statement }
>: >|>
>: >|> Am I wrong if I think technically this means that a wait statement is
>: >|> allowed in a function?
>: >|>
>: >|> But then in section 8.1 it says "it is an error if a wait statement
>: >|> appears in a function subprogram".
>: >|>
>: >|> Is the first definition an error? Are there any other sequential
>: >|> statements that are not allowed in functions?
>: >|>
>: >The syntax diagrams in the appendix just specify syntax. Whether or not

>: (deletion ...)

>: don't you think the syntax should exclude those possibilities? of course the
>: LRM says a lot more than the syntax diagrams, but it is awkward to work with a
>: set of syntax with so many precedences. the syntax i am working with has
>: "subprogram_sequential_statement" which has no "wait" in it. period.

>While there are certain semantic restrictions that the syntax could represent,
>not all semantic restrictions are expressible syntactically.  For example,

Of course you are right.

Quote:
>the syntax for a variable assignment statement is:

>    variable_assigment_statement ::= target := expression;

>Nowhere does it say that the target must consist of a variable or of an
>aggregate of all variables, nor does it say that the type (and subtype) of the
>target and the type (and subtype) of the expression must be the same, etc.

As a matter of fact, can this be accomplished purely by the syntax in a
reasonable way? Semantic restrictions are needed.

Quote:

>Even if the grammar expressed the semantic restrictions that it could, it would
>be even larger than it is now.  As a result, IMHO, it would be much harder, not
>easier to understand.

>--Paul

>--

>Menchini & Associates|                           |prove their worth by
>2 Davis Dr./POB 13036|    voice: 919-990-9506    |hitting back."
>RTP, NC  27709-3036  |    fax:   919-990-9507    |         -- Piet Hein

Sure the semantic restrictions can (should???) not be easily included in the
syntax, but i think things like "wait stmt" in functions could be more clearly
and easily handled as a syntax rule than as a semantic restriction. and IMHO,
i don't think this is a way to make the language even larger (well just what
makes a language large? # of rules?).

Lun
--




Sat, 08 Mar 1997 06:59:09 GMT  
 wait statements in functions

   don't you think the syntax should exclude those possibilities? of course
   the LRM says a lot more than the syntax diagrams, but it is awkward to
   work with a set of syntax with so many precedences. the syntax i am
   working with has "subprogram_sequential_statement" which has no "wait" in
   it. period.

You mean you don't allow a wait statement in a procedure body?  Then your
syntax is *wrong*.

A lot of people read the BNF and are then confused when the LRM text makes
illegal certain constructs which the BNF allows.  Consider this example:

  constant_declaration ::=    
         CONSTANT identifier_list : subtype_indication [ := expression ] ;

A naive user might think that

    constant c : bit_vector := 3;

is legal, since the BNF does not specifically disallow it.  The BNF says
nothing about matching types.  (In fact, VHDL could be extended to allow the
above statement, by providing an implicit type conversion from an integer
type to type BIT_VECTOR.  Such an extension would not require a change to
the BNF.  This might not be a bad idea for a hardware description language.)

Here's another example:

  aggregate ::=    
         ( element_association { , element_association } )

  element_association ::=  
         [ choices => ] expression

This would seem to allow such "aggregates" as

    (1)        
        -- illegal: a one-element aggregate requires named association
    ('0', 3 => '1')
        -- illegal: cannot mix named and positional association
    (OTHERS => '1', 3 => '1')
        -- illegal: OTHERS must be the last choice

If you really want the BNF to specify these syntactic rules, you must be
willing to live with a much more complex BNF.  For instance:

  aggregate ::=
        ( positional_association, positional_association { , positional_association } [ , others_association ] )
        | ( positional_association, others_association )
        | ( others_association )
        | ( named_association { , named_association } [ , others_association ] )

  positional_association ::=
        expression

  named_association ::=
        named_association_choices => expression

  named_association_choices ::=
        named_association_choice { | named_association_choice }

  named_association_choice ::=
        simple_expression
        | discrete_range
        | element_simple_name

  others_association ::=
        OTHERS => expression

And of course, even this syntax doesn't say that the type of an aggregate
must be determinable from its context, or that for an array aggregate an
OTHERS choice is only allowed if the aggregate appears in one of a set of
contexts, or that if a non-locally-static choice appears (in an array
aggregate, that is), it must be the only choice, or that the discrete_range
or simple_expression cases of a named_association_choice may not appear in a
record aggregate.  (I leave it as an exercise to the reader to construct a
BNF which handles as many of these cases as possible.)

True, the BNF could be more specific in some cases, such as differentiating
between the kinds of statements that can appear immediately within a
function body from those that can appear immediately within a procedure
body.  But the LRM writers had to choose between precision in the BNF, and
readability and conciseness.
--

(speaking only for myself)      "Cekoslovakyalilastiramadiklarimizdanmissiniz."



Sat, 08 Mar 1997 23:08:53 GMT  
 wait statements in functions
[...]
|> A lot of people read the BNF and are then confused when the LRM text makes
|> illegal certain constructs which the BNF allows.  Consider this example:
|>
|>   constant_declaration ::=    
|>          CONSTANT identifier_list : subtype_indication [ := expression ] ;
|>
|> A naive user might think that
|>
|>     constant c : bit_vector := 3;
|>
|> is legal, since the BNF does not specifically disallow it.  The BNF says
|> nothing about matching types.  (In fact, VHDL could be extended to allow the
|> above statement, by providing an implicit type conversion from an integer
|> type to type BIT_VECTOR.  Such an extension would not require a change to
|> the BNF.  This might not be a bad idea for a hardware description language.)

Uhh, this is not a good idea. What would be the coding for the "3"?

"11"       (just the bits that are needed, how to behave then with "11" + "1")
"011"      (with sign bit)
"00000011" (byte wide)
"11000000" (byte wide, but reverse byte order)
"00110011" (ASCII representation)
"0010"     (Gray code)

Append your own representations ...

The whole thing becomes even worse with the hypothetical
        constant c : bit_vector := 3.1415;
Which encoding would you use for universal real numbers?
IEEE 754?
VAX "A"-"Z" :-) floating formats?
PDP-11?
Fixed point, with how many bits?
Which byte ordering?
mantissa two's complement or sign bit only?
Truncate or round? Up? Down?

Append your own representations, you will always find someone whose
favorite format is not covered.

Nothing said against a "standard math" package which has one or another
conversion function from integer or real to bit_vector and vice versa,
but I wouldn't like to see implicit conversions, even if they sound
reasonable for a HDL.

--

|  |   / GMD-SET German National Research  | Phone: (+49) 2241 14 2448
|__|  /  Center for Computer Science       | Fax:   (+49) 2241 14 2342
|  | /   Schloss Birlinghoven              | Had a nightmare yesterday:
|  |/    53754 St. Augustin, Germany       | My system started up with
                                           | ... Booting vmunix.el ...



Sun, 09 Mar 1997 01:00:24 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Unexpected STATEMENT FUNCTION statement

2. Synthesis of wait statements

3. wait statement question

4. wait statement

5. Is wait statements better??

6. wait statement on Xilinx Foundation.

7. wait statements in sub-programs for synthesis

8. Process without wait statement

9. Wait until statement problem in synthesis

10. Final conclusion of wait until statement discussion

11. procedure + wait statement

12. VHDL FLI/Tcl in Modelsim and wait statement

 

 
Powered by phpBB® Forum Software