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

Hi Andy,
Exactly. If an architecture is explicitly specified in both the entity
instantiation, and a configuration that uses it, I would like the
synthesiser to throw me an error, since there could be a possible conflict.

Regards,
Daniel

On Wed, Feb 23, 2011 at 1:52 AM, Jones, Andy D <andy.d.jones@lmco.com>wrote:

> 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 message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.