Oh sorry, my mistake.
The reason why I omitted the architecture in the entity instantiation is
because I want the architecture name to be configurable. That's why I wanted
it to be specified using configurations instead:
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;
The architecture name of subblock0 is specified in configurations, so I
don't specify the architecture in the entity instantiation of subblock0
itself. Subblock0 is meant to have multiple architectures.
Regards,
Daniel
On Wed, Feb 23, 2011 at 12:27 AM, Daniel Kho <daniel.kho@gmail.com> wrote:
> Yes, but again, that won't work with configurations.
>
> Regards,
> Daniel
>
>
> On Tue, Feb 22, 2011 at 11:50 PM, Jones, Andy D <andy.d.jones@lmco.com>wrote:
>
>> You can specify the architecture in the entity instantiation itself:
>>
>>
>>
>> Label: entity work.entity_name(arch_name)…
>>
>>
>>
>> Been that way since ’93.
>>
>>
>>
>> *Andy D Jones
>> *Electrical Engineering
>>
>> Lockheed Martin Missiles and Fire Control
>> Dallas TX
>>
>>
>>
>> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
>> Behalf Of *Daniel Kho
>> *Sent:* Tuesday, February 22, 2011 7:30 AM
>> *To:* vhdl-200x@eda.org
>> *Cc:* hans@ht-lab
>> *Subject:* EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list
>>
>>
>>
>> Hi Hans,
>>
>>
>>
>> Just a few more (these aren't solely my suggestions; others have
>> contributed to the discussion as well):
>> 1: make some currently non-synthesizable code become synthesizable.
>> Examples are "after", "assert", "report", etc. Need to >study which of these
>> are feasible to implement.
>>
>>
>>
>> Some of them like assert are already supported by most synthesis tools. As
>> far as I know they only generate a warning rather than stopping the
>> synthesis process. I believe that synthesis vendors are already trying to
>> support as many language constructs as possible as this is a major product
>> differentiator.
>>
>>
>> Yes, I'm aware of this. Most synthesis tools just give warnings on valid
>> VHDL syntax but those that they don't know how to generate logic with. So I
>> agree that constructs like "after" and "assert" (and a whole bunch of
>> others) to not stop the synthesis process, but they all do get ignored by it
>> and no logic is being generated. I was thinking that we give the designer an
>> option whether or not he wants to generate logic for these? Perhaps an
>> attribute (like "keep")?
>>
>> One reason for this is that more and more people would like to have their
>> simulation testbenches synthesized to become either BIST or tester circuits.
>>
>>
>>
>> 2: easier way to design configurable testbenches, e.g. support shorthand
>> entity instantiation (to be embedded into >configurations) instead of
>> component instantiation.
>>
>>
>>
>> Please explain.
>>
>>
>> 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;
>>
>>
>> Currently both my synthesis and simulation tools reported errors for this
>> design. Apparently the entity instantiation in the top-level design is not
>> supported for use with configurations (though it is valid when
>> configurations are not used):
>> instance0: entity work.subblock0 port map(...);
>>
>> To make this work, I had to explicitly convert the entity instantiation
>> into a component instantiation (which was THE way to do things a long time
>> ago when direct entity instantiation wasn't yet supported). Having to do
>> this again with configurations is like we're stuck with something of the
>> past...
>> architecture structural of block0 is
>> component subblock0 is port(...); end component subblock0;
>> begin
>> instance0: subblock0 port map(...);
>> end structural;
>>
>> Anyway, the main reason I request this is because I think everybody agrees
>> we need to spend more time simplifying design verification - that means
>> making it easier to write testbenches and run simulations. Configurations is
>> an elegant way to automate verification of testcases, and there are quite a
>> number of people out there who use this method to generate testbenches.
>> Other methods (without using configurations) are possible too, and I believe
>> there are other things we can do to improve those areas.
>>
>> Well, to compete against other design verification languages like
>> SystemVerilog, e, Vera, I believe we should start with finding ways to make
>> it easier to write testbenches the pure VHDL way. VHDL itself is already an
>> excellent language for design verification, though things can be made easier
>> to use.
>> I for one do not use PSL or VHPI or stuff like that, because that means
>> having to learn another language and a whole new paradigm.
>>
>> 3. Timing constraints supported by language.
>>
>>
>>
>> This was mentioned before and I didn't understand it then, do you have an
>> example?
>>
>> I know that synthesis tools supports all sorts of attributes to set pin
>> numbers, IOB's, fsm coding styles etc but I find it questionable coding
>> style as it makes your code highly un-portable.
>>
>>
>>
>> We were discussing about how to make the synthesiser/P&R timing-aware. We
>> currently already have the SDC file format to input timing constraints, so
>> there was a suggestion of supporting timing constraints directly by VHDL
>> (either by embedding SDC, or have our own syntax, or both).
>>
>>
>>
>> Regards,
>> Hans
>> www.ht-lab.com
>>
>>
>> ..
>> Regards,
>> Daniel
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>>
>> believed to be clean.
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, 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 08:35:55 2011
This archive was generated by hypermail 2.1.8 : Tue Feb 22 2011 - 08:36:00 PST