Do configurations apply to "generated" components?
Joel Kolstad
that they weren't behaving the way I expected. I started hacking and
slashing until I came up with a decent little test program to demonstrate
this... here:
entity TestComp is
port(
i : out integer
);
end TestComp;
architecture arch1 of TestComp is
begin
ThisIsArch1 : i<=1;
end arch1;
architecture arch2 of TestComp is
begin
ThisIsArch2 : i<=2;
end arch2;
entity bar is
end bar;
use Std.TextIO.All;
architecture foo of bar is
component TestComp is
port(
i : out integer
);
end component;
for all:TestComp use entity Work.TestComp(arch1);
signal a,b : integer;
begin
GenTest : for i in 1 to 1 generate
GendComp : TestComp
port map(
i => a
);
end generate;
AnotherComp : TestComp
port map(
i => b
);
process
variable l : line;
begin
wait for 1 ns;
write(l,"GendComp used architecture " & integer'image(a));
writeline(Output,l);
write(l,"AnoterComp used architecture " & integer'image(b));
writeline(Output,l);
wait;
end process;
end foo;
If you simulate this program, it'll display:
: GendComp used architecture 2
: AnoterComp used architecture 1
I expected the "for all:TestComp..." :configuration to affect the component
(GendComp) with a for...generate as well as the individually instantiated
AnotherComp. It appears that the configuration statement doesn't "reach"
the for...generate loop, however, and default binding takes over, thereby
binding GendComp to architecture 2 (since it was compiled later than
architecture 1).
Is this the way VHDL is supposed to work?
---Joel Kolstad
Alan Fitch
<Joel.K...@USA.Net> writes
Now *that's* a good question. I shall attempt to answer it on the basis
that Paul Menchini will correct me if I get it wrong :-)
The VHDL '93 standard says (page 74)
"If the reserved word all is supplied, then the configuration
specification applies to all instances of the specified component
declaration whose labels are implicitly declared in the immediately
enclosing declarative part. This rule applies only to those component
instantiation statements whose corresponding instantiated units name
components"
I think the key phrase is "immediately enclosing declarative part".
In VHDL '93, a generate statement creates a new declarative region.
If you then look at LRM page 141 (visibility), it lists declarative
regions, including the generate statement, and says
"in each of these cases, the declarative region is said to be associated
with the corresponding declaration or statement. A declaration is said
to occur immediately within a declarative region if this region is the
innermost region that encloses the declaration, not counting the
declarative region (if any) associated with the declaration itself"
For instance, to configure the generated components in your example
above using a configuration declaration, you would use
configuration Fred of bar is
for foo -- architecture
for AnotherComp: TestComp -- instance
use entity work.testcomp(arch1);
end for;
for Gentest(1) -- generate label
for Gendcomp : TestComp
use entity work.testcomp(arch1);
end for;
end for;
end for;
end;
Notice the extra level of hierarchy inside the generate region.
It would be interesting to try your example in VHDL '87, since generate
statements did not have declarative regions associated with them then.
regards
Alan
--
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK
Tel: +44 (0)1425 471 223 Email: alan....@doulos.com
Fax: +44 (0)1425 471 573
** Visit THE WINNING EDGE www.doulos.com **
SteVe
> I've been trying to use configuration statements, and eventually realized
> that they weren't behaving the way I expected. I started hacking and
> slashing until I came up with a decent little test program to demonstrate
> this... here:
> I expected the "for all:TestComp..." :configuration to affect the component
> (GendComp) with a for...generate as well as the individually instantiated
> AnotherComp. It appears that the configuration statement doesn't "reach"
> the for...generate loop, however, and default binding takes over, thereby
> binding GendComp to architecture 2 (since it was compiled later than
> architecture 1).
>
> Is this the way VHDL is supposed to work?
>
> ---Joel Kolstad
I had the same problem a while ago. The key point is that the generate
statement introduces a level of hierarchy in the code; this way the statement
"for all:..." affects only the TestComp that are found in the current level of
hierarchy, that is AnotherComp.
I had some troubles in making your code run with Synopsys, and made some
insignificant changes. Here is the code where all components use architecture
1; the key point is in the configuration at the bottom of the file (I added it
to simulate with VSS).
entity TestComp is
port(
i : out integer
);
end TestComp;
architecture arch1 of TestComp is
begin
ThisIsArch1 : i<=1;
end arch1;
architecture arch2 of TestComp is
begin
ThisIsArch2 : i<=2;
end arch2;
entity bar is
end bar;
use Std.TextIO.All;
architecture foo of bar is
component TestComp
port(
i : out integer
);
end component;
-- for all:TestComp use entity Work.TestComp(arch1);
signal a,b : integer;
begin
GenTest : for i in 1 to 1 generate
GendComp : TestComp
port map(
i => a
);
end generate;
AnotherComp : TestComp
port map(
i => b
);
process
variable l : line;
begin
wait for 1 ns;
-- write(l,"GendComp used architecture " & integer'image(a));
-- writeline(Output,l);
-- write(l,"AnoterComp used architecture " & integer'image(b));
-- writeline(Output,l);
wait;
end process;
end foo;
configuration bar_cfg of bar is
for foo
for all:TestComp use entity Work.TestComp(arch1);
end for;
for GenTest
for all:TestComp use entity Work.TestComp(arch1);
end for;
end for;
end for;
end bar_cfg;
Hope this will help.
Bye, SteVe
Joel Kolstad
fledged "configuration myConfig is..." approach, but what I was hoping to
accomplish was to be able to easily swap architectures in and out of a
particular component (entity) by doing the following:
-- Have a bunch of "for all:..." statements that would establish the default
binding, regardless of the compilation order of the various architectures.
-- Have various configuration statements that only "take aim" at the
components whose architectures I want to be something other than my
"preferred default" (that the "for all..." statement set).
For instance, say you had a large project with ten different components that
you have have two or more architectures for. Now, _every_ different
configuration has to specify _all ten_ bindings so that you're darned sure
you have the right architecture. This make each configuration rather large,
and worse yet, requires you to go back and change _every configuration_
every time you add _one more component with multiple architectures_. (To
add the new "preferred default binding.") At least, that's my understanding
of it... and that strikes me as a little annoying.
I can still see doing what I want to do (having my cake and eating it to) if
I take the Ben Cohen approach to VHDL and split the entity declarations into
physically different files than the architectures, so that I can simply have
my build macros compile the various architectures in the right order such
that I get the preferred default binding I desire. Hmm...
Well, even with these drawbacks, configuration statements are pretty handy.
---Joel Kolstad
Colin Marquardt
> I can still see doing what I want to do (having my cake and eating it to) if
> I take the Ben Cohen approach to VHDL and split the entity declarations into
> physically different files than the architectures, so that I can simply have
> my build macros compile the various architectures in the right order such
> that I get the preferred default binding I desire. Hmm...
In its current beta version, emacs' vhdl-mode can create Makefiles
for compiling. It uses the configuration information (if it is a
purely hierarchical configuration, i.e. one configuration covers
only one level) for that if present, and the most recently compiled
architecture otherwise.
And emacs' speedbar with vhdl-mode makes the "one design unit, one
file"-approach quite painless.
Colin
PS: Reto (vhdl-mode author) is away, so if I said something stupid,
he cannot correct me immediately.