ModelSim named association

[Mike]

There seems to be a problem using named association with ModelSim. If
I instantiate a component with:

uut: cnt8
port map (
clk_i => clk,
n_reset_i => n_reset,
tco_o => tco,
q_o(0) => cnt_q(0),
q_o(1) => cnt_q(1),
q_o(2) => cnt_q(2),
q_o(3) => cnt_q(3),
q_o(4) => cnt_q(4),
q_o(5) => cnt_q(5),
q_o(6) => cnt_q(6),
q_o(7) => cnt_q(7)
);

then everything is fine. However if I use

uut: cnt8
port map (
clk_i => clk,
n_reset_i => n_reset,
tco_o => tco,
q_o(0) => cnt_q(0),
tco_o => tco,
q_o(1) => cnt_q(1),
q_o(2) => cnt_q(2),
q_o(3) => cnt_q(3),
q_o(4) => cnt_q(4),
q_o(5) => cnt_q(5),
q_o(6) => cnt_q(6),
q_o(7) => cnt_q(7)
);

(Note I have moved the wiring of tco_o) Then ModelSim complains with
the message
"# ** Error: top.vhd(41): association q_o has already been specified."

Has anyone else come accross this problem?

OK, I know the solution is to write code as per the first example, or
even better to use

q_o => cnt_q

but this is just an example. In reality the VHDL is generated by a
Xilinx program called ngc2hdl which takes a netlist in ngc format and
wraps it in VHDL so that it can be simulated. Or not as the case may
be.

Any ideas?

Mike

 

[Mike Treseler]

There seems to be a problem using named association with ModelSim. If
I instantiate a component with:

uut: cnt8
port map (
clk_i => clk,
n_reset_i => n_reset,
tco_o => tco,
q_o(0) => cnt_q(0),

The line above is the problem.
The right hand side can't be a slice.
Try something like this:

architecture synth2 of instance is

signal clk_i_s : std_ulogic; -- [in]
signal n_reset_i_s : std_ulogic; -- [in]
signal tco_o_s : std_ulogic; -- [out]
signal q_o_0_s : std_ulogic; -- [out]
signal q_o_1_s : std_ulogic; -- [out]
signal q_o_2_s : std_ulogic; -- [out]
signal q_o_3_s : std_ulogic; -- [out]
signal q_o_4_s : std_ulogic; -- [out]
signal q_o_5_s : std_ulogic; -- [out]
signal q_o_6_s : std_ulogic; -- [out]
signal q_o_7_s : std_ulogic; -- [out]

begin -- architecture synth2

uut_1 : entity work.cnt8
port map (
tco_o => tco_o_s,
clk_i => clk_i_s,
n_reset_i => n_reset_i_s,
q_o(0) => q_o_0_s,
q_o(1) => q_o_1_s,
q_o(2) => q_o_2_s,
q_o(3) => q_o_3_s,
q_o(4) => q_o_4_s,
q_o(5) => q_o_5_s,
q_o(6) => q_o_6_s,
q_o(7) => q_o_7_s
);

end architecture synth2;

Or better yet, make your counter a one-liner in
a synchronous process and avoid the instance details.

-- Mike Treseler


---------------------------------------------------------
-- example of counter variable inside
-- a synchronous process
-- Mon Aug 16 11:07:47 2004 Mike Treseler

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity count_var is
generic (len : natural := 8); -- vector length
port (
clk : in std_ulogic;
rst : in std_ulogic;
cnt : out unsigned(len-1 downto 0)
);
end count_var;

architecture synth of count_var is
subtype count_t is unsigned(len-1 downto 0);
constant init : unsigned := (count_t'range => '0');
begin
clkedrocess (clk, rst)
variable cnt_v : count_t;
-- other variables here:

begin
values:if rst = '1' then
cnt_v := init;
cnt <= cnt_v;
elsif rising_edge(clk) then
cnt <= cnt_v;
cnt_v := cnt_v + 1;
-- do other stuff here:

end if values;
end process clked;
end synth;
---------------------------------------------------------

 

[Nicolas Matringe]

Mike Treseler a écrit:

The line above is the problem.
The right hand side can't be a slice.

Actually it can. Used it many times. I would say the *left* hand side
can not be a slice.

 

[Duane Clark]

Mike Treseler a écrit:



Actually it can. Used it many times. I would say the *left* hand side
can not be a slice.

I have made both sides slices many times. The restriction that I have
found is that if the left side is a slice, then all bits of that bus
must be assigned to signals; none can be open.

isa_d: ISA
port map(
....
ES_MON(0) => M_OUT_I(1), -- ESR
ES_MON(10 downto 1) => ES_MONI,
ES_MON(14 downto 11) => M_OUT_I(11 downto 8), -- bypass signals
ES_MON(15) => M_OUT_I(6), -- shunt
....

Can't say about the original question though. I have not tried that.

 

[Mike Treseler]

Nicolas Matringe wrote

Actually it can. Used it many times. I would say the *left* hand side
can not be a slice.

You're right. I just tried it.
In fact both sides can be sliced.

I think the OP's original problem is not slicing, but
interrupting the assending indexes in the instance.
The base entity's port type may be an unconstrained vector.
There is a good example of this on page 146
of Ashenden's Designer's Guide, 2nd Ed.

-- Mike Treseler

 

[Egbert Molenkamp]

I think the OP's original problem is not slicing, but
interrupting the assending indexes in the instance.

A PhD student today had the same problem. The order changed and it worked!
I read the VHDL-93 standard on page 63 line 508 (also in VHDL-2002)

"Furthermore, every scalar subelement of the explicitly declared interface
object must be associated
exactly once with an actual (or subelement thereof) in the same association
list, and all such associations
must appear in a contiguous sequence within that association list."

I think that the last part "contiguous" requires that the "interruption" is
not allowed.
Based on that I think that ModelSim seems to be correct (and thus Xilinx is
not).

Egbert Molenkamp

 

[Mike]

A PhD student today had the same problem. The order changed and it worked!
I read the VHDL-93 standard on page 63 line 508 (also in VHDL-2002)

"Furthermore, every scalar subelement of the explicitly declared interface
object must be associated
exactly once with an actual (or subelement thereof) in the same association
list, and all such associations
must appear in a contiguous sequence within that association list."

I think that the last part "contiguous" requires that the "interruption" is
not allowed.
Based on that I think that ModelSim seems to be correct (and thus Xilinx is
not).

Egbert Molenkamp

Xilinx now admit it is their problem and will fix it in the next
revision. In the meantime you have to modify the wrapper file by hand,
keep it somewhere safe and use it to overwrite the version created by
simgen.

Mike