Modelsim and configuration statements

[Thomas Reinemann]

Hello,

I have an entity with two architectures
entity gaindiv(rtl_long)
entity gaindiv(rtl_round)

They are instantiated by different entities (fir_tap and iir_tap) within
if-generate statements. The instantiating and instantiated entities
belong to the same lib.

I tried a lot of things, but Modelsim uses always the architecture which
I have compiled as last.

I used simple configurations right behind the component declaration and
the separate block configuration for each, entity iir_tap and fir_tap,
no success.

I discussed this problem with the support. For this purpose I reduced my
complex design to are very simple example, and you are right all worked
well. Before I spent a lot of time to grab the files, I ask you, do you
have any hints/experience to this situation. How to deal with this problem?
On a higher level of my design I use different architectures of an
entity, too. All works well, but here instantiation happens not within
an if generate statement.

Bye Tom

 

[Andy Peters]

Hello,

I have an entity with two architectures
entity gaindiv(rtl_long)
entity gaindiv(rtl_round)

They are instantiated by different entities (fir_tap and iir_tap) within
if-generate statements. The instantiating and instantiated entities
belong to the same lib.

I tried a lot of things, but Modelsim uses always the architecture which
I have compiled as last.

I think what's happening here is that the entities have the same name,
so when you compile them into your library, the compiler doesn't know
that they are different, so the last one overwrites the previous one.

=a

 

[Thomas Reinemann]

I think what's happening here is that the entities have the same name,
so when you compile them into your library, the compiler doesn't know
that they are different, so the last one overwrites the previous one.

Of course both entities have the same name. But I think VHDL is supposed
to have entities with multiple architectures, The library browser shows
both architectures, but assigns the last compiled file to the entity,
this one is loaded.
Do you mean, my source shall have only one entity?

I have two source files

===== gaindiv_long.vhdl

entity gaindiv is
....
end gaindiv;

architecture rtl_long of gaindiv is
....
end rtl_long;

configuration gaindiv_long_conf of gaindiv is

for rtl_long
....
end for;

end gaindiv_long_conf;

==== and gaindiv_round.vhdl

entity gaindiv is
....
end gaindiv;

architecture rtl_round of gaindiv is
....
end rtl_round;

configuration gaindiv_round_conf of gaindiv is
for rtl_round
end for;

end for;
end gaindiv_round_conf;

==========================


Bye Tom

 

[Guest]

Hi Tom

1. I wouldn't declare the entity twice as you do. It could disturb the
compiler, which will see that the entity was recompiled after the 1st
architecture was.

2. Nice that you have two configurations which configure the rtl_long
and rtl_round architectures but where are the configuration statements
of the instanciating entities?

Eric

 

[Mike Treseler]

Of course both entities have the same name. But I think VHDL is supposed
to have entities with multiple architectures, The library browser shows
both architectures, but assigns the last compiled file to the entity,
this one is loaded.
Do you mean, my source shall have only one entity?

Yes. The idea is to configure different
architectures to the *same* entity.
The configuration names are different.
These are used instead of the
entity name as the top of the design.

In some cases, this abstraction is
not worth the trouble.

-- Mike Treseler

 

[Jonathan Bromley]

Of course both entities have the same name. But I think VHDL is supposed
to have entities with multiple architectures, The library browser shows
both architectures, but assigns the last compiled file to the entity,
this one is loaded.
Do you mean, my source shall have only one entity?

Yes, that's the idea.

I have two source files

===== gaindiv_long.vhdl

entity gaindiv is
...
end gaindiv;

architecture rtl_long of gaindiv is [...]

==== gaindiv_round.vhdl

entity gaindiv is
...
end gaindiv;

architecture rtl_round of gaindiv is

So, let's suppose you compile the first of these. Compiler
sees and processes two design units: the entity and its
associated architecture. Now compile the second file.
Compiler AGAIN compiles the entity, overwriting the (identical)
compiled entity in the library. Consequently, the first
architecture is now unusable because it belongs to an entity
that is out-of-date.

The correct solution, if you're doing this seriously, is to
keep entities and architectures in separate files. Then you
compile the entity just once, and subsequently compile each
architecture whenever you feel like it. This works well,
because the architecture (implementation) is likely to be
frequently updated because of bugfixes, but the entity is
likely to remain stable.

However, given your existing source code, you need to know
about the "-just" option to ModelSim's compiler. Using
this option you can suppress recompilation of the entity.
Here's how...

vcom -just e gaindiv_long.vhdl; # compile the entity
vcom -just a gaindiv_long.vhdl; # compile the architecture
vcom -just a gaindiv_round.vhdl; # and the other architecture

Now you're not recompiling the entity, and all is well.
Similarly, use "-just c" to compile only configurations.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Thomas Reinemann]

The correct solution, if you're doing this seriously, is to
keep entities and architectures in separate files. Then you
compile the entity just once, and subsequently compile each
architecture whenever you feel like it. This works well,
because the architecture (implementation) is likely to be
frequently updated because of bugfixes, but the entity is
likely to remain stable.

Great, this worked. In former times we put tuck in the envelope to the
thank. Just imagine a chocolate Santa Claus, enjoy your meal.

Bye Tom