Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
17 years ago

Data corrupted, any problem with VHDL codes

HI everyone.

I just have a quick question to ask.

When we use the LOOP in VHDL, is there any chances that the number of times the LOOP is repeated affects the data, say, in the following piece of code, the code "content(i) <= content(i+1)" is repeated 65 times (content is an array of 8bit number), and the data I get at the output of the Modules (dataout[7:0]) is corrupted at some points:

-- ram.vhd

library ieee;

use ieee.std_logic_1164.all;

use ieee.std_logic_arith.all;

use ieee.std_logic_unsigned.all;

entity RAM is

generic ( bits: integer := 8;

words: integer:= 66);

port (clk_in: in std_logic;

clk_out: in std_logic;

we: in std_logic;

re: in std_logic;

reset: in std_logic;

datain: in std_logic_vector(bits - 1 downto 0);

dataout: out std_logic_vector(bits - 1 downto 0)

);

end RAM;

architecture beh of RAM is

signal readp: integer range 0 to words;

type table is array (0 to words - 1) of std_logic_vector(bits-1 downto 0);

signal content: table :=(others => "10000000");

begin

process(reset,clk_in, we)

begin

if (reset = '1') then

content <= (others => "10000000");

elsif (clk_in'event and clk_in = '1') then

if (we = '1') then

for i in 0 to words - 2 loop

content(i) <= content(i+1); --***could it be this line? ***

end loop;

content(words - 1) <= datain;

end if;

end if;

end process;

process(clk_out, re)

begin

if (clk_out'event and clk_out = '1') then

if(re = '1') then

dataout <= content(readp);

end if;

end if;

end process;

process(clk_out, re, reset)

begin

if (reset = '1') then

readp <= 0;

elsif (clk_out'event and clk_out = '0') then

if(re = '1') then

readp <= readp + 1;

if(readp = words - 1) then

readp <= 0;

end if;

end if;

end if;

end process;

end beh;

Any suggestion would be greatlly appreciated.

Cheers.

J.

13 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    You seem to infer a dual clock shift register. You better instantiate an altera dual clock ram.

    Your loop is not the problem but it could be your use of two clocks going wrong.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    I don't see clearly, why you organized the code this way. However, when you write data to the shift register, the content of the complete array is shifted, and can't be accessed consistently for a time interval of several ns. If clock_out is unrelated to clock_in, you have no gurantee to read consistent data. To my opinion, the issue can't be avoided with the present structure.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    You can't do this if those are two independent clocks; you will most likely need to either look up how to infer dual port memory from your manufacturer or simply use their dual port ram blocks. If the two clocks are real you really should just put this in one clocked process. Again it's always good to refer to your manufacturers manuals on how to infer RAM. You'll find it's very similar to the way you set up "table" but very unlike your read and write processes. You can read and write with two separate clocks but it will require handshake signals using clock domain synchronization flip flops. It will not be single clock cycle access either.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Thank you for having a look at my post.

    Following is the link to some illustration for my design.

    datacorrupted.rar (http://www.filefactory.com/file/a01448d/n/datacorrupted_rar) (scroll down to option2, click on the link Download With FileFactory Basic)

    doc5.pdf is the clk_in and clk_out waveform.

    doc6.pdf is how I want the output to be.

    doc7.xls is the real data I captured (after transfering the output to a Microprocessor and have it printed on screen). As you can see, at column BF, some of the data is corrupted (one bit changes) making the waveform change dramatically (you can plot a graph of column BF and BE to see the difference).

    Please note that the clocking was control externally by the microprocessor which is much simpler than internally.

    The 99 points of data were stored in a FIFO

    I could have used a built-in RAM (with 99 points stored from address 0 to 98) and ignore the VHDL RAM for this design, but doing this will result in a really complicated addressing system.

    Any suggestion after having a look at the diagram and data would be really appreciated.

    Thank you

    J
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Actually, I used an Actel FPGA (which I don't like but company does) for this design, not Altera. Is there any chances the way the the logic elements and the net were placed and routed inside the chip corrupted the data?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Well you can see by the way the error propogates through to subsequent addresses that the error occurs at the input phase (in the shift register) and it is bit 5 (16) that is causing problems - to me it looks like your enormous shift register has a timing problem (posibly due to clock skew) on this one bit between those two elements.

    Do you get any timing warning from the compiler? Did you use the proper global clock lines for the CLK_IN to keep skew to a minimum? Have you defined any timing constraints?

    Your spreadsheet and your doc6 do not seem to match up by the way.One shows the error occuring between elements 57 and 56 of the shift register whilst doc6 implies it is elements 63 and 62.

    Mark.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- Quote Start ---

    Actually, I used an Actel FPGA (which I don't like but company does) for this design, not Altera. Is there any chances the way the the logic elements and the net were placed and routed inside the chip corrupted the data?

    --- Quote End ---

    There is a chance, but as the other people have said, if the in_clock and out_clock are unrelated then this design will now work whatever the technology used.

    Imagine the Content(0) word. Due to difference in routing delays for each bit, each bit will change at a slightly different delay after input clock rises.

    Now imagine you try and latch the output using output clock. Depending on the relationship of the input and output clock edges at this instant it is possible that you will see some of the bits in the word as the new value and some as the previous value. Hence corrupt data!

    This comment ignores the crucial but unpleasant effects of metastability whereby you violate setup/hold times of flip-flops by changing the input data using a different clock to that latching the data. Also causing corrupt data.

    So looks like a redesign is the only way to go!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- Quote Start ---

    There is a chance, but as the other people have said, if the in_clock and out_clock are unrelated then this design will now work whatever the technology used.

    --- Quote End ---

    Normally I would agree, but if you look at his doc5 (granted not that easy as it RARed) you'll see that clk_in and clk_out are related and mutually exclusive - basically he is clocking in data to a bloody great shift register - then reading out the whole shift register (for some reason) and then clocking in another word. So metastability wise it shouldn't be an issue but as my previous post mentions he has a clock skew/timing issue one one wire!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- Quote Start ---

    Normally I would agree, but if you look at his doc5 (granted not that easy as it RARed) you'll see that clk_in and clk_out are related and mutually exclusive - basically he is clocking in data to a bloody great shift register - then reading out the whole shift register (for some reason) and then clocking in another word. So metastability wise it shouldn't be an issue but as my previous post mentions he has a clock skew/timing issue one one wire!

    --- Quote End ---

    Thanks Mark, yeah, as you said, the CLK_IN and CLK_OUT are related to each other, 66 CLK_OUT pulses are covered by 1 CLK_OUT, (in my test, the Clocks were controlled by a microprocessor).

    --- Quote Start ---

    Well you can see by the way the error propogates through to subsequent addresses that the error occurs at the input phase (in the shift register) and it is bit 5 (16) that is causing problems - to me it looks like your enormous shift register has a timing problem (posibly due to clock skew) on this one bit between those two elements.

    Do you get any timing warning from the compiler? Did you use the proper global clock lines for the CLK_IN to keep skew to a minimum? Have you defined any timing constraints?

    --- Quote End ---

    Yeah, I think the problem arised at the input phase, which consists of writing the data into content(words - 1) and a series of shifting process. But if you plot a graph of the last column (where the data was first written in --> fine), you will see it is likely the shifting process that cause the error.

    I don't have any timing warning from the compiler and no global clock lines for the CLK_IN has been used yet (will give it a go)... and no time constraints was defined...

    --- Quote Start ---

    So looks like a redesign is the only way to go!

    --- Quote End ---

    Thanks vernmid for your suggestion, actually, I'm designing a hardware correlator using a MAC circuit. Wish I could change the design, however the circuit was a given and the FPGA chip doesn't have enough resource for me to drive the design to other directions.

    Thanks everyone, for your contribution.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Ahhh. You didn't use the Global clock! In that case I definitely think you have a clock skew problem, basicaly the data from one latch is bing clocked out in advance of the data to the next latch being clocked in - it's a common problem with large shift registers (I used Actel devices nearly 20 years ago and experienced same) but using a Global clock rather than normal routing should cure it as the skew over the global clock will be much much less than if you've used local routing for the clock.

    I assumed it was a correlator you were designing, couldn't think of any other reason for this arrangement.