Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Concurrent signal assignment vs. port mapping

Reply
Thread Tools

Concurrent signal assignment vs. port mapping

 
 
Torsten Landschoff
Guest
Posts: n/a
 
      07-28-2008
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

 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      07-28-2008
Torsten Landschoff wrote:

> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
concurrent signal assignment: order can matter? ralvarexo@googlemail.com VHDL 5 12-30-2011 09:13 PM
Assignment to output signal from internal signal not istantaneous dibacco73 VHDL 1 02-12-2009 11:28 PM
"Target of signal assignment is not a signal" Nicolas Moreau VHDL 9 07-25-2007 04:21 PM
problems locating the concurrent EDU.oswego.cs.dl.util.concurrent package Pep Java 6 08-16-2005 07:26 AM
Concurrent Assignment Taras_96 VHDL 6 04-04-2005 01:01 AM



Advertisments