Repair Generate Statements

Proposal Details

• Who Updates: TristanGingold
• Date Proposed: 2015-01-10
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Current Situation

There are several issues with new generate statement in vhdl 08:

A) Declarative regions

According to 12.1 Delcarative region item l), there is one declarative region for a generate statement. So the following piece of code is not valid:

   g : if l1: c1 generate
     constant cst : natural := 3;
   begin
     s <= cst;
   else l2: generate
     constant cst : natural := 2;
   begin
     s <= cst;
   end generate;

as cst is declared twice in the same declarative region. Likewise, the following piece of code is valid:

   g : if l1: c1 generate
     constant cst1 : natural := 3;
   begin
     s <= cst1;
   else l2: generate
     constant cst2 : natural := cst1 + 1;
   begin
     s <= cst2;
   end generate;

But this is certainly not expected by the user, nor coherent with elaboration.

So I think there should be a declarative region per generate_statement_body (which is unusual for a _body construct).

For for-generate statement, the parameter_specification would be implicitely declared in the declarative region of the

generate statement body.

B) Expanded name

(TODO)

C) Alternative label

According to LRM 11.1, labels of concurrent statement are implicitely declared. This doesn't include alternative labels, as they aren't labelling a concurrent statement. So, apparently they aren't declared until elaboration (see LRM 14.5.3). So referencing them within block_specification is a little bit weird, as they aren't declared during analysis and in particular aren't visible at that time.

I think the alternative labels should be declared at analysis time.

D) Type of generate specification for for-generate statement

LRM 3.4.2 says: "for a generate specification that is an expression, it is an error if the type of the expression is not the same as the type of the discrete range of the generate parameter specification".

For very common cases (like: for i in 1 to 5 generate ...), the type of the discrete range is integer but the type of expression in generate specification is universal integer. This isn't the same type. I think this need a rewording and usual implicit conversion should be added here.

(I also think the phrasing could be improved: in fact the type of the expression is known at analysis time, and therefore the expression should be analyzed using that type).

E) Staticness of generate specification

Possibility of improvement: for for-generate statements, the expression or the discrete range of generate specification must be static. I think this could be relaxed.

Requirement

Implementation details

Code Examples

Use Cases

Arguments FOR

Arguments AGAINST

-- DavidKoontz - 2015-01-10

General Comments

-- DavidKoontz - 2015-01-10

The first paragraph of 11.8:

The block declarative part is derived from declarative items following the first condition that returns TRUE (treating else as elsif TRUE). Only one of the two declarations of cst is included in the block declarative part and there is only one declarative region for the if generate. You either get the one following the if condtion or get the one following the else but not both.

The condition for a generate statement has to be globally static. The implication is which declarative items apparently comprising a declarative region represents the actual declarative region (if any), the decision is made at elaboration time based on conditions. The mechanism should be identical to previous standard versions, the difference is the case generate and expanded if generate require more conditions (or cases) be traversed.

See 14.5.3 Generate quoted above.

-- TristanGingold - 2015-01-11

No, the first example is not valid: it should be rejected at analysis time as an identifier is declared twice (and overloaded is not allowed), as specified by LRM08 12.3 Visibility.

I don't agree with your last sentence (The declarations ain't declarations until they are elaborated) and I don't think this can be backed with the LRM. Furthermore, this is self-contradictory: that would mean you cannot speak of declarations before elaboration. If you go that way, you could nearly write garbage within an 'if false generate ... end' part of the design.

Declarative part mostly match declarative regions, and this is not the case here. I think this is confusing from a user point of view. The second example is clearly invalid, but according to the LRM, it isn't invalid at analysis time; it is only invalid during elaboration. That's also confusing.

-- DavidKoontz - 2015-01-13

Thanks for fixing the broken merge, that's what I came back for. Yes the second example is invalid, I didn't see it with enough pixels (or they weren't big enough).

A generate statement doesn't produce a block statement until it is elaborated. Elaboration of any declarations found withing involves plugging that portion of the resulting design specification into the design network. It doesn't matter if the generate body contains multiple declarations of the same name before elaboration, the generate statement bodies and their block declarative parts are set mutually exclusive.

At most one one is included in the elaborated design network. The rest are dead code.

Because they are mutually exclusive you can also treat them as separate declarative regions, only one (at most) of which will survive to be elaborated. There's only at most one elaborated declarative region. They are independent of each other, required to stand alone by 14.5.3, incidentally making the second example illegal, but not the first.

Supporters

Add your signature here to indicate your support for the proposal