Concurrent signal assignment vs. port mapping

[Torsten Landschoff]

Hello list,

Up to today, I thought that concurrent signal assignment (with a
simple signal on the right side) is equivalent to port mapping in
VHDL. The code below would generate sig delayed by on cycle on sig_d:

entity doesnotwork is end doesnotwork;

architecture tb of doesnotwork is
signal clock, sig, sig_d : bit := '0';
signal clock2 : bit := '0';
begin
clock_gen: clock <= not clock after 5 ns;

producer: process (clock) is begin
if clock'event and clock = '1' then
sig <= not sig;
end if;
end process;

fwd_clock: clock2 <= clock;
consume: process (clock2) is begin
if clock2'event and clock2 = '1' then
sig_d <= sig;
end if;
end process;
end architecture;

However it turns out in simulation, that sig and sig_d show the same
value. This is because the concurrent signal assignment to clock2
makes clock2 one delta cycle behind clock. sig is negated at the same
time, so that the process consume already sees the updated value of
sig.

The following code uses a port map to do essentially the same (and I
believe the synthesized design would actually behave the same as
doesnotwork above):

entity doeswork is end doeswork;

architecture tb of doeswork is
signal clock, sig, sig_d : bit := '0';
begin
clock_gen: clock <= not clock after 5 ns;

producer: process (clock) is begin
if clock'event and clock = '1' then
sig <= not sig;
end if;
end process;

p2: block
port (clock2 : in bit);
port map (clock2 => clock);
begin
consume: process (clock2) is begin
if clock2'event and clock2 = '1' then
sig_d <= sig;
end if;
end process;
end block;
end architecture;

Here clock2 is basically an alias for clock and consume sees the old
data on sig. I just tested that making clock2 an alias for clock also
works fine.

I know I am not telling you something new here, but I ran into this
issue while I tried to simulate a design that makes use of the
opb_ipif v3.01.c of EDK 9.2. Despite the fact the the OPB_IPIF has
pipeline registers for the bus lines, they are actually seen early on
the user_logic side.

The problem gets worse with clock forwarding to the user logic - the
"signal slicing" code in the coregen generated wrapper seems indeed
necessary so that the clock does not arrive before the data lines.

Has anybody run into such problems? Is there a better work around?

Thanks for any comments, Torsten

 

[Mike Treseler]

The problem gets worse with clock forwarding to the user logic - the
"signal slicing" code in the coregen generated wrapper seems indeed
necessary so that the clock does not arrive before the data lines.

Has anybody run into such problems?
Yes.

Is there a better work around?

I use one sim clock and I don't use coregen.

-- Mike Treseler