RE: [vhdl-200x-ft] FT27: optional architectures

Tristan,
> >
> > > * One problem with optionnal architecture is that when an
> > > architecture is obsoleted, you don't really know wether
> you should
> > > elaborate without architecture or fail to elaborate. The same
> > > problem already exists with the package body.
> >
> > You use the reserved word "open" to indicate that no
> architecture be
> > included. Thus, if an architecture is obsoleted, you replace all
> > references to it in binding indications with "open".
> Ok, I was not clear enough.
> Suppose you are using default bindings and default
> configurations. Suppose the only architecture of an entity
> (which is instantiated) is obsoleted. How your design will
> elaborate: fails or without architecture for the instantiated entity.

Thanks for clarifying the question. My suggested change to the default
binding rules includes not binding any architecture if the is no
architecture in the library. Under this scheme, the behavior when an
architecture becomes obsolete depends on whether you leave the architecture
in the library or not.

Presumably, the architecture becomes obsolete by virtue of changing the
entity. Since the architecture depends on the entity, after the entity is
re-analyzed, the architecture would have to be re-analyzed to be included in
the design.

If the change to the entity means the architecture is no longer needed, but
the architecture is left in the library, elaboration would fail.

Once the architecture is removed from the library, elaboration can proceed,
and the default binding rule will cause the entity alone to be bound into
the design.

> > > * The second problem is how do you configure the entity ?
> Since the
> > > entity can have component instantiation, you should be able to
> > > configure them.
> >
> > The current situation is this: A block configuration that occurs
> > immediately within a configuration declaration or
> immediately within a
> > component configuration configures the equivalent block
> corresponding
> > to the design entity. If the block configuration names an
> > architecture, it configures the design entity comprising the entity
> > and the architecture.
> >
> > What's new in the proposal is that, if the block configuration uses
> > the reserved word "open" instead of an architecture name,
> the design
> > entity consists of the entity declaration alone. The block
> > configuration contains configuration items for the contents of the
> > entity declaration. That may include component instances
> and nested
> > blocks.
> We don't understand each other.
> What's new too is that, an entity may contain component
> instantiation. Currently, there is no way to configure them
> (of course).

The following example illustrates the scenario I think you are describing.

  entity E is
    component C is
      ...
  begin
    C_INST : component C
      ...
  end entity E;

We can configure the entity and the component instance in it as follows:

  configuration E_CFG of E is
    for open
      for C_INST : C
        ...
      end for;
    end for;
  end configuration E_CFG;

The point is that the block configuration immediately within E_CFG
configures the block corresponding to the design entity, which, in this
case, consists only of the entity declaration.

> Furthermore, the label of a component
> instantiation (C.I.) in an entity can be the same as a label
> of a C.I. in an architecture. How do you address this issue ?

In VHDL-2002, the block structure of design entities was changed, so that an
architecture body was logically nested within an entity declaration. Under
that scheme, a component instance in the architecture could have the same
label as that of a component instance of the entity declaration, since the
label of the inner instance (in the architecture body) would hide the label
of the outer instance (in the entity).

In VHDL-200x, however, it is proposed to revert to the previous block
structure for design entities, namely, having the declarative region of an
architecture body extend that of the corresponding entity declaration. In
other words, the entity declarative region and the architecture declarative
region would jointly form the declarative region of the design entity. In
that case, you could not have the same label for a component instance in the
entity and a component instance in the architecture, since they labels would
be homographs in the same declarative region.

> > > * Finally, as a proposal too, we should be able to configure the
> > > architecture of a design entity instantiation. Currently,
> it is not
> > > possible to do that.
> >
> > I'm sorry, I don't understand what it is that you're suggesting.
> > Would you care to elaborate?
> Sure.
> With VHDL 93, you can instantiate entities directly:
> C: entity Work.X (Y) port map (P1 => S1, P2 => S2);
> However, you can omit the architecture name:
> C: entity Work.X port map (P1 => S1, P2 => S2);
> But you can't configure which architecture you want to use.
> I'd like to be able to configure them.

Thanks - I see what you mean now. That makes good sense. Rather than just
relying on the default binding rule to bind in the most-recently analyzed
architecture, you could defer the choice of architecture to a configuration
declaration.

I'd suggest you put in an enhancement request on the VASG web page at
www.eda.org/vasg/. That way, we can track the proposal for the next
revision.

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106