I would certainly NOT be in favor of overriding via configuration an architecture specified explicitly in an entity instantiation. If I tell the tool to use a specific architecture, it ought to do exactly that or die trying.
When I need configurability anymore, I usually use generic-controlled if-generates around the possible instantiations that specify the different architectures explicitly. But I rarely need to change more than a single architecture.
But I get Daniel's point. It would be beneficial to use a configuration to specify an architecture for an entity instantiation that did not specify one. It allows the architecture-binding flexibility afforded by configurations, while avoiding the cost of component declarations. Full component declarations and instantiations, along with configurations would still be required if binding to a differently named entity is required.
Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX
Cell: 817-422-3124
-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jim Lewis
Sent: Tuesday, February 22, 2011 10:56 AM
To: vhdl-200x@eda.org
Subject: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list
Hi Daniel,
> 2: easier way to design configurable testbenches, e.g. support
> shorthand entity instantiation (to be embedded into >configurations)
> instead of component instantiation.
> For example, you have these files:
> *Top-level design: block0.vhdl*
> library ieee,work;
> use ieee.<packages>.all;
> use work.subblock0;
>
> entity block0 is port(...);
> end entity block0;
>
> architecture structural of block0 is
> begin
> instance0: entity work.subblock0 port map(...);
> end structural;
>
> *Sub-level design: subblock0.vhdl, subblock0_arch.vhdl*
> The entity of subblock0 is specified in subblock0.vhdl.
> The architecture of subblock0 is specified in subblock0_arch.vhdl.
>
> *cfg_block0.vhdl*
> library work;
> use work.subblock0;
>
> configuration cfg_block0 of block0 is
> for structural
> for sub0_arch0: subblock0
> use entity work.subblock0(arch0);
> end for;
> end for;
> end configuration cfg_block0;
>
_Summary_
Need ability to use a configuration to bind/re-bind an
architecture of an entity that was instanced using a direct
entity instantiation.
I suspect that the current language binds the architecture during the
direct entity instance (whether the architecture was specified or not)
and does not allow it to be rebound.
_Use Model_
If subblock0 above is the transaction source for a testbench,
configurations would be used to select which test is active.
In general configurations are not well supported in synthesis,
so this is only a testbench issue.
_Alternatives using current language_
Alternative direct entity instantiation but no configurations and
compile the desired architecture to make it the current architecture.
The simulation will then load the desired architecture. Issues with
this are that if the architecture failed to compile, often the
last successfully compiled architecture is used. As a result,
this method does not carry the design-safe intent of VHDL.
Another alternative is to use component instantiation. This
requires more typing or cut and paste. This impact can be reduced
by putting the component in a package and putting the package either
immediately before or after the entity declaration. The impact can
also be reduced if one has a script that reads the entity and
generates a package containing the component.
As an aside, generally my testbench models have the model
interface (which is defined in a standard and rarely changes) and
a transaction interface. The transaction interface is abstracted
into one or more records that are defined in a package. As a result,
when the transaction interface needs revisions, only the record type(s)
change and not the component interface. So as a result, the component
interface only gets created once by cut and paste and while that is
tedious, it is not that time consuming.
My Rating: Nice to have, but not essential
As an aside, this is what I consider to be the irony of
direct entity instantiation:
* not well enough supported in synthesis to use for RTL
* not configurable (architecture, ?generics?) so not too
useful for testbenches
Best,
Jim
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Feb 22 09:52:45 2011
This archive was generated by hypermail 2.1.8 : Tue Feb 22 2011 - 09:52:49 PST