Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Same code ... Different results ...

Reply
Thread Tools

Same code ... Different results ...

 
 
Niall
Guest
Posts: n/a
 
      05-16-2007
[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?

 
Reply With Quote
 
 
 
 
Andy
Guest
Posts: n/a
 
      05-17-2007
On May 16, 5:45 pm, Niall <(E-Mail Removed)> 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

 
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
Weird issue, same code, same browser, two different apache servers,very different css bluebaron HTML 3 11-04-2009 07:13 PM
running same script on same data on two different machines -->different result Christopher Brewster Python 5 11-14-2008 08:19 PM
list of html code same but output is different on different browsers pradeep HTML 3 06-07-2007 05:54 PM
same code, different providers => different behaviours?? Bart ASP .Net 2 03-22-2007 10:25 AM
same code produces different decimal symbol on different computers with same settings ASP General 2 12-29-2003 02:29 PM



Advertisments