Conflicting results

[Niall]

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?

 

[Paul Uiterlinden]

Niall wrote:

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

From the port description of your mux design I reckon this is a synchronous
design. It clocks input data in on the rising edge of the clock and puts
new data out on the same edge.

In your first test you change your input data *exactly* at the rising edge
of the clock. The result is that your mux clocks in the *new* data. This is
similar to a setup/hold violation in the real world.

In your second test the input data of your mux is coming from another
design, your counter. This is another synchronous design, I suppose. The
trick now is, is that the output signals of that design change *after* the
rising edge of the clock. To be exact: one delta cycle after the clock.
This is caused by the signal assignment to the output in your counter.
Every signal assignment has a minimum delay of one delta cycle.

The main problem lies in your first test: you change input data exactly at
the rising edge of the clock. You should not do that.

Now that I look again at your pictures, I see that the output of your mux
changes on both edges of the clock. I don't get it anymore: is your mux a
synchronous design, a pure combinatorial design (why a clock input then?),
or a mix of both?

Please post the code of your mux here to see what you have made.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[Niall]

That's it - I had a clock going in and it was edge triggered. Don't
know why I had it there to be honest. Obviously wasn't thinking.

Thanks Paul Uiterlinden!