Same code ... Different results ...

Discussion in 'VHDL' started by Niall, May 16, 2007.

  1. Niall

    Niall Guest

    [I tried to post this earlier, but it didn't post for some reason]

    Hi there.

    [I recently started to learn VHDL, and I really enjoy it. So far I've
    created a clock, counter, mux, demux, latch, shift register etc. I
    want to make something to tie these things all together, so if you
    have any suggestions I'd love to hear them :)]

    Anyway.

    One step at a time.

    At the moment I have a clock input going into a counter and its output
    goes into the select ports of a multiplexer. It kinda works in certain
    test bench situations (or under certain 'stimulous' ... heh), but then
    under others it gives different results.

    My mux has four input busses (8 bits per input), and one output bus (a
    byte wide again, obviously), and there are two select ports, but while
    these particular dimensions are very easily configurable the output
    for the second test (see later), is always wrong in the same manner.
    If I manually select the control (select), bits I get this output
    (http://twomers.googlepages.com/mux_good.JPG), which is fine and is as
    I expected. However, if I use the counter I created to select the
    input select bits I get a conflicting result - http://twomers.googlepages.com/mux_bad.JPG

    The problem is that ... well the latter is wrong. The mux seems to
    ignore the first transition (both the counter and mux react to
    clk'event and the first transition is the first rising edge of the clk
    signal), and retains the output it's initialised to ... it appears to
    be lagging by a transition-phase or something. I showed that the mux
    actually works as it should with test 1, but it fails for test two.
    It's bugging me! I've tested it a lot and only come here as a last
    resort - I find that figuring things out by yourself teaches you a lot
    more than others telling you the answers, though that only works to a
    point.

    Here's the code (only test bench code now - if ye reckon ye'll need
    more let me know and I'll oblige):


    LIBRARY IEEE;
    USE IEEE.STD_LOGIC_1164.ALL;
    USE IEEE.NUMERIC_STD.ALL;

    ENTITY multiplexer_tb IS
    END ENTITY multiplexer_tb;

    ARCHITECTURE multiplexer_tb_arch OF multiplexer_tb IS
    CONSTANT num_sel_bits : INTEGER := 2; -- Change these to change
    number of input ports
    CONSTANT bus_count : INTEGER := 8; -- and number of bits per
    port.

    SIGNAL clk, en, clk_clr, u_d : STD_LOGIC;
    SIGNAL per_time : TIME;
    SIGNAL input_select : STD_LOGIC_VECTOR
    ( num_sel_bits -1 DOWNTO 0 );
    SIGNAL out_bus : STD_LOGIC_VECTOR
    ( bus_count -1 DOWNTO 0 );
    SIGNAL in_busses : STD_LOGIC_VECTOR
    ( (bus_count*(2**num_sel_bits))-1 DOWNTO 0 );

    BEGIN
    clock_inst : ENTITY WORK.clock( clock_arch )
    PORT MAP ( en, per_time, clk );
    mux_inst : ENTITY WORK.multiplexer( multiplexer_arch )
    GENERIC MAP ( num_sel_bits, bus_count )
    PORT MAP ( en, clk, clk_clr, input_select, out_bus,
    in_busses );
    counter_inst : ENTITY WORK.counter( counter_arch )
    GENERIC MAP ( num_sel_bits )
    PORT MAP ( clk, en, clk_clr, u_d, input_select );


    multiplexer_tbing : PROCESS IS
    BEGIN
    u_d <= '1'; -- Count up or down? Up = '1'
    en <= '1';
    clk_clr <= '0';
    per_time <= 10 NS;

    in_busses <= X"DDCCBBAA";

    -- -- TEST #1
    -- input_select <= "00";
    -- WAIT FOR 20 NS;
    --
    -- input_select <= "01";
    -- WAIT FOR 20 NS;
    --
    -- input_select <= "10";
    -- WAIT FOR 20 NS;
    --
    -- input_select <= "11";
    -- WAIT FOR 20 NS;
    -- -- END TEST #1

    -- TEST #2
    WAIT FOR 100 NS;
    -- END TEST #2

    en <= '0';
    WAIT;

    END PROCESS multiplexer_tbing;
    END ARCHITECTURE;


    (again, if ye have any design issues with my code, let me learn -
    ye're more likely much more experienced than I)
    (I still haven't figured out that whole library thing, or rather
    haven't put the effort into it yet, so I still use WORK)

    I initially though it might have been delta-delays or something, but I
    quickly decided it wasn't.

    I have a theory to explain the lag, but I can't put it into words and
    if I change to code to reflect the theory it just gets worse :/
    Literally! It lags by 360 degrees rather than 180 ... 'degrees' I
    guess. Could it be a time delay with the counter signaling to the mux?
    I shouldn't think so cause it's only a simulation test-bench so is
    presumably an idealised circuit, right?
     
    Niall, May 16, 2007
    #1
    1. Advertising

  2. Niall

    Andy Guest

    On May 16, 5:45 pm, Niall <> wrote:
    > [I tried to post this earlier, but it didn't post for some reason]
    >
    > Hi there.
    >
    > [I recently started to learn VHDL, and I really enjoy it. So far I've
    > created a clock, counter, mux, demux, latch, shift register etc. I
    > want to make something to tie these things all together, so if you
    > have any suggestions I'd love to hear them :)]
    >
    > Anyway.
    >
    > One step at a time.
    >
    > At the moment I have a clock input going into a counter and its output
    > goes into the select ports of a multiplexer. It kinda works in certain
    > test bench situations (or under certain 'stimulous' ... heh), but then
    > under others it gives different results.
    >
    > My mux has four input busses (8 bits per input), and one output bus (a
    > byte wide again, obviously), and there are two select ports, but while
    > these particular dimensions are very easily configurable the output
    > for the second test (see later), is always wrong in the same manner.
    > If I manually select the control (select), bits I get this output
    > (http://twomers.googlepages.com/mux_good.JPG), which is fine and is as
    > I expected. However, if I use the counter I created to select the
    > input select bits I get a conflicting result -http://twomers.googlepages.com/mux_bad.JPG
    >
    > The problem is that ... well the latter is wrong. The mux seems to
    > ignore the first transition (both the counter and mux react to
    > clk'event and the first transition is the first rising edge of the clk
    > signal), and retains the output it's initialised to ... it appears to
    > be lagging by a transition-phase or something. I showed that the mux
    > actually works as it should with test 1, but it fails for test two.
    > It's bugging me! I've tested it a lot and only come here as a last
    > resort - I find that figuring things out by yourself teaches you a lot
    > more than others telling you the answers, though that only works to a
    > point.
    >
    > Here's the code (only test bench code now - if ye reckon ye'll need
    > more let me know and I'll oblige):
    >
    > LIBRARY IEEE;
    > USE IEEE.STD_LOGIC_1164.ALL;
    > USE IEEE.NUMERIC_STD.ALL;
    >
    > ENTITY multiplexer_tb IS
    > END ENTITY multiplexer_tb;
    >
    > ARCHITECTURE multiplexer_tb_arch OF multiplexer_tb IS
    > CONSTANT num_sel_bits : INTEGER := 2; -- Change these to change
    > number of input ports
    > CONSTANT bus_count : INTEGER := 8; -- and number of bits per
    > port.
    >
    > SIGNAL clk, en, clk_clr, u_d : STD_LOGIC;
    > SIGNAL per_time : TIME;
    > SIGNAL input_select : STD_LOGIC_VECTOR
    > ( num_sel_bits -1 DOWNTO 0 );
    > SIGNAL out_bus : STD_LOGIC_VECTOR
    > ( bus_count -1 DOWNTO 0 );
    > SIGNAL in_busses : STD_LOGIC_VECTOR
    > ( (bus_count*(2**num_sel_bits))-1 DOWNTO 0 );
    >
    > BEGIN
    > clock_inst : ENTITY WORK.clock( clock_arch )
    > PORT MAP ( en, per_time, clk );
    > mux_inst : ENTITY WORK.multiplexer( multiplexer_arch )
    > GENERIC MAP ( num_sel_bits, bus_count )
    > PORT MAP ( en, clk, clk_clr, input_select, out_bus,
    > in_busses );
    > counter_inst : ENTITY WORK.counter( counter_arch )
    > GENERIC MAP ( num_sel_bits )
    > PORT MAP ( clk, en, clk_clr, u_d, input_select );
    >
    > multiplexer_tbing : PROCESS IS
    > BEGIN
    > u_d <= '1'; -- Count up or down? Up = '1'
    > en <= '1';
    > clk_clr <= '0';
    > per_time <= 10 NS;
    >
    > in_busses <= X"DDCCBBAA";
    >
    > -- -- TEST #1
    > -- input_select <= "00";
    > -- WAIT FOR 20 NS;
    > --
    > -- input_select <= "01";
    > -- WAIT FOR 20 NS;
    > --
    > -- input_select <= "10";
    > -- WAIT FOR 20 NS;
    > --
    > -- input_select <= "11";
    > -- WAIT FOR 20 NS;
    > -- -- END TEST #1
    >
    > -- TEST #2
    > WAIT FOR 100 NS;
    > -- END TEST #2
    >
    > en <= '0';
    > WAIT;
    >
    > END PROCESS multiplexer_tbing;
    > END ARCHITECTURE;
    >
    > (again, if ye have any design issues with my code, let me learn -
    > ye're more likely much more experienced than I)
    > (I still haven't figured out that whole library thing, or rather
    > haven't put the effort into it yet, so I still use WORK)
    >
    > I initially though it might have been delta-delays or something, but I
    > quickly decided it wasn't.
    >
    > I have a theory to explain the lag, but I can't put it into words and
    > if I change to code to reflect the theory it just gets worse :/
    > Literally! It lags by 360 degrees rather than 180 ... 'degrees' I
    > guess. Could it be a time delay with the counter signaling to the mux?
    > I shouldn't think so cause it's only a simulation test-bench so is
    > presumably an idealised circuit, right?


    Are you sure you're passing the signals onto the ports in the right
    order? I prefer named association lists (port_name => signal_name;
    etc...) to make sure there are no errors, and to make it more
    readable.

    Andy
     
    Andy, May 17, 2007
    #2
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bart
    Replies:
    2
    Views:
    330
  2. pradeep
    Replies:
    3
    Views:
    836
    cwdjrxyz
    Jun 7, 2007
  3. Christopher Brewster
    Replies:
    5
    Views:
    361
    John Machin
    Nov 14, 2008
  4. bluebaron
    Replies:
    3
    Views:
    777
    Jonathan N. Little
    Nov 4, 2009
  5. Guest
    Replies:
    2
    Views:
    196
    Foo Man Chew
    Dec 29, 2003
Loading...

Share This Page