RE: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list

Several years ago, in our group we ran into the problem that different
tools that we use had different algorithms for finding the entity to
bind to a component instance by default.

We switched to direct entity instantiation because this leaves no room
for ambiguity.

After we made the switch, initially, I was surprised that the
architecture to bind to the instantiated entity cannot be given in a
configuration (and I kind of viewed it as an oversight by the LRM
writers). However,it is possible to change the architecture by making
sure that the desired architecture is the one last analyzed (compiled).
However, this only works if the direct entity instantiation is the form
that does not specify an architecture.

A couple of other thoughts on this:

1. I have found that the cases where one wants to change the entity (as
opposed to the architecture) are rare to non-existent.
2. It is good to have a keyword in instantiations, including
"component", as allowed by VHDL93, because it makes instantiations
easier to search for.
3. We have not run into tools that do not support direct entity
instantiation for synthesis.

-Farrell Ostler

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Jones, Andy D
Sent: Tuesday, February 22, 2011 10:52 AM
To: 'vhdl-200x@eda.org'
Subject: RE: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list

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.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.