Same code ... Different results ...

N

Niall

[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?
 
A

Andy

[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
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top