Concurrent signal assignment vs. port mapping

Discussion in 'VHDL' started by Torsten Landschoff, Jul 28, 2008.

  1. 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
     
    Torsten Landschoff, Jul 28, 2008
    #1
    1. Advertisements

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

    -- Mike Treseler
     
    Mike Treseler, Jul 28, 2008
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.