Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Re: VHDL Help

Reply
Thread Tools

Re: VHDL Help

 
 
goouse99@googlemail.com
Guest
Posts: n/a
 
      07-31-2012
Am Dienstag, 31. Juli 2012 03:45:36 UTC+2 schrieb Bruno Carvalho:
> Hello,
>
>
>
> Thanks for your reply.
>
>
>
> Well, when i simulate the component alone it works correctly.
>
>
>
> But when i run a simulation with the component integrated to my system byport maps, the behavior is wrong.
>
>
>
> Could i consider your commentary about delay once i'm doing a functional simulation ? Sorry if i'm doing a silly question.
>
>
>
> Thank you so much.
>
>
>
> Best Regards.
>
>
>
> Bruno
>
>
>
> On Wednesday, July 25, 2012 10:02:42 PM UTC-4, Bruno Carvalho wrote:
>
> > Hello,

>
> >

>
> >

>
> >

>
> > I'm having difficulties to understand a modelsim simulation of a vhdl component written by me.

>
> >

>
> > I have a vhdl component which name is tx_controller. This component hasa simple logic. It reads the number of words stored in a buffer (dc_fifo altera ip core). If the number of words stored in buffer < 376, so i send tothe output data_out the value 0xFF. When the words store in buffer >= 376, i send to the data_out the value of input data_in which is values came from buffer.

>
> >

>
> > In this simulation the behavior of tx_controller is correct.

>
> >

>
> > But when i use the same module integrated in my system through port maps the component has a strange behavior. E.g.: When the data_in has the value 0x40, data_out should receive the value 0x40, but it keeps with the last value (0x00) and the value is changed to 0x40 only in the next rising edge in clock signal.

>
> >

>
> >

>
> >

>
> > Bellow is my code

>
> >

>
> >

>
> >

>
> > --------------------------------------------------------------

>
> >

>
> > library IEEE;

>
> >

>
> > use IEEE.std_logic_1164.all;

>
> >

>
> > use IEEE.numeric_std.all;

>
> >

>
> > --------------------------------------------------------------

>
> >

>
> >

>
> >

>
> > ENTITY tx_controller IS

>
> >

>
> > GENERIC(WR_USED_MIN: integer := 376;

>
> >

>
> > NULL_PACKET: integer := 255);

>
> >

>
> > PORT (clk, rst: IN STD_LOGIC;

>
> >

>
> > data_in: IN STD_LOGIC_VECTOR(7 DOWNTO 0); --DATA FROM BUFFER

>
> >

>
> > fifo_is_empty: IN STD_LOGIC;

>
> >

>
> > wr_used: IN STD_LOGIC_VECTOR(8 DOWNTO 0); --N WORDS IN BUFFER

>
> >

>
> > fifo_rd_enable: OUT STD_LOGIC; --ENABLE FIFO READING

>
> >

>
> > data_out: OUT STD_LOGIC_VECTOR(7 DOWNTO 0) --DATA TO INTERFACE

>
> >

>
> > );

>
> >

>
> > END tx_controller;

>
> >

>
> >

>
> >

>
> > ARCHITECTURE behav OF tx_controller IS

>
> >

>
> > CONSTANT fifo_min : STD_LOGIC_VECTOR(8 DOWNTO 0) := STD_LOGIC_VECTOR(to_unsigned(WR_USED_MIN, 9));

>
> >

>
> > BEGIN

>
> >

>
> >

>
> >

>
> > MAIN: PROCESS(rst, clk, data_in, wr_used)

>
> >

>
> > BEGIN

>
> >

>
> > IF (rst = '1') THEN

>
> >

>
> > fifo_rd_enable <= '0';

>
> >

>
> > data_out <= (others => '0');

>
> >

>
> > ELSIF (rising_edge(clk)) THEN

>
> >

>
> > IF (wr_used < fifo_min) THEN

>
> >

>
> > data_out <= (OTHERS => '1');

>
> >

>
> > fifo_rd_enable <= '0';

>
> >

>
> > ELSE

>
> >

>
> > fifo_rd_enable <= '1';

>
> >

>
> > data_out <= data_in;

>
> >

>
> > END IF;

>
> >

>
> > END IF;

>
> >

>
> > END PROCESS;

>
> >

>
> > END behav;

>
> >

>
> >

>
> >

>
> >

>
> >

>
> > Somebody can identify some problem analysing my vhdl code ?

>
> >

>
> >

>
> >

>
> > Thanks for any help.


Hi Bruno,
When simulating a system consisting of synchronous designs the outputs are mostly registered.

So the behavior is well defined.

In many testbenches designers use WAIT FOR statements to assign their stimuli.
And Most often these statements are causing signals to change at the activeclock edge. This is a big problem.

While in the waveform this looks like a registered output, the attached FFscan show undetermined behavior. Wether the old state of the signal is taken by the FF or the new one can't be said. That depends on the sequence of signal changes in the delta cycles for that time.

So please check your testbench if you are using WAIT FOR statements.
(AFTER statements can cause similar problems)

You can overcome this by using e.g.
WAIT UNTIL rising_edge(clk);
after each WAIT FOR. (shorten the time in the WAIT FOR for some ns)


The tricky thing is, that your waveform might look OK, but it isnt.
And you can't see it because the malbehavior is hidden in the delta cycles.
But as soon as you connect your module with other modules that have true registered outputs you observe strange behavior , as you did. Especially whenyou are using comparators, they are probably all misaligned.

Have a nice simulation
Eilert
 
Reply With Quote
 
 
 
 
Gabor
Guest
Posts: n/a
 
      07-31-2012
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Am Dienstag, 31. Juli 2012 03:45:36 UTC+2 schrieb Bruno Carvalho:
>> Hello,
>>
>>
>>
>> Thanks for your reply.
>>
>>
>>
>> Well, when i simulate the component alone it works correctly.
>>
>>
>>
>> But when i run a simulation with the component integrated to my system by port maps, the behavior is wrong.
>>
>>
>>
>> Could i consider your commentary about delay once i'm doing a functional simulation ? Sorry if i'm doing a silly question.
>>
>>
>>
>> Thank you so much.
>>
>>
>>
>> Best Regards.
>>
>>
>>
>> Bruno
>>
>>
>>
>> On Wednesday, July 25, 2012 10:02:42 PM UTC-4, Bruno Carvalho wrote:
>>
>>> Hello,
>>> I'm having difficulties to understand a modelsim simulation of a vhdl component written by me.
>>> I have a vhdl component which name is tx_controller. This component has a simple logic. It reads the number of words stored in a buffer (dc_fifo altera ip core). If the number of words stored in buffer < 376, so i send to the output data_out the value 0xFF. When the words store in buffer >= 376, i send to the data_out the value of input data_in which is values came from buffer.
>>> In this simulation the behavior of tx_controller is correct.
>>> But when i use the same module integrated in my system through port maps the component has a strange behavior. E.g.: When the data_in has the value 0x40, data_out should receive the value 0x40, but it keeps with the last value (0x00) and the value is changed to 0x40 only in the next rising edge in clock signal.
>>> Bellow is my code
>>> --------------------------------------------------------------
>>> library IEEE;
>>> use IEEE.std_logic_1164.all;
>>> use IEEE.numeric_std.all;
>>> --------------------------------------------------------------
>>> ENTITY tx_controller IS
>>> GENERIC(WR_USED_MIN: integer := 376;
>>> NULL_PACKET: integer := 255);
>>> PORT (clk, rst: IN STD_LOGIC;
>>> data_in: IN STD_LOGIC_VECTOR(7 DOWNTO 0); --DATA FROM BUFFER
>>> fifo_is_empty: IN STD_LOGIC;
>>> wr_used: IN STD_LOGIC_VECTOR(8 DOWNTO 0); --N WORDS IN BUFFER
>>> fifo_rd_enable: OUT STD_LOGIC; --ENABLE FIFO READING
>>> data_out: OUT STD_LOGIC_VECTOR(7 DOWNTO 0) --DATA TO INTERFACE
>>> );
>>> END tx_controller;
>>> ARCHITECTURE behav OF tx_controller IS
>>> CONSTANT fifo_min : STD_LOGIC_VECTOR(8 DOWNTO 0) := STD_LOGIC_VECTOR(to_unsigned(WR_USED_MIN, 9));
>>> BEGIN
>>> MAIN: PROCESS(rst, clk, data_in, wr_used)
>>> BEGIN
>>> IF (rst = '1') THEN
>>> fifo_rd_enable <= '0';
>>> data_out <= (others => '0');
>>> ELSIF (rising_edge(clk)) THEN
>>> IF (wr_used < fifo_min) THEN
>>> data_out <= (OTHERS => '1');
>>> fifo_rd_enable <= '0';
>>> ELSE
>>> fifo_rd_enable <= '1';
>>> data_out <= data_in;
>>> END IF;
>>> END IF;
>>> END PROCESS;
>>> END behav;
>>> Somebody can identify some problem analysing my vhdl code ?
>>> Thanks for any help.

>
> Hi Bruno,
> When simulating a system consisting of synchronous designs the outputs are mostly registered.
>
> So the behavior is well defined.
>
> In many testbenches designers use WAIT FOR statements to assign their stimuli.
> And Most often these statements are causing signals to change at the active clock edge. This is a big problem.
>
> While in the waveform this looks like a registered output, the attached FFs can show undetermined behavior. Wether the old state of the signal is taken by the FF or the new one can't be said. That depends on the sequence of signal changes in the delta cycles for that time.
>
> So please check your testbench if you are using WAIT FOR statements.
> (AFTER statements can cause similar problems)
>
> You can overcome this by using e.g.
> WAIT UNTIL rising_edge(clk);
> after each WAIT FOR. (shorten the time in the WAIT FOR for some ns)
>
>
> The tricky thing is, that your waveform might look OK, but it isnt.
> And you can't see it because the malbehavior is hidden in the delta cycles.
> But as soon as you connect your module with other modules that have true registered outputs you observe strange behavior , as you did. Especially when you are using comparators, they are probably all misaligned.
>
> Have a nice simulation
> Eilert


Also your process MAIN has extra items in the sensitivity list.
I don't think this will affect simulation, but it's best to clean
it up to make sure. A clocked process should only have the clock
and any asynchronous set/reset inputs in the sensitivity list.
Synthesis generally ignores the sensitivity list, so keeping the
list correct prevents unintentional differences between simulation
and synthesis.

MAIN: PROCESS(rst, clk, data_in, wr_used)

should be:

MAIN: PROCESS(rst, clk)

-- Gabor
 
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
VHDL-2002 vs VHDL-93 vs VHDL-87? afd VHDL 1 03-23-2007 09:33 AM
BPSK on VHDL (warning - VHDL newbie) pygmalion VHDL 6 06-23-2006 07:30 PM
VHDL 2002 vs VHDL 1993 dude VHDL 1 03-23-2006 01:18 PM
multiD-vhdl: Multi Dimensional Arrays (allowing generics on each dimension) for VHDL (including ports) albert.neu@gmail.com VHDL 2 03-21-2006 04:05 PM
what's the difference between VHDL 93 CONCATENATION and VHDL 87 CONCATENATION? walala VHDL 3 09-18-2003 04:17 AM



Advertisments