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

    YEAHHHH, EXCELLENT, I've just tried to put a CLKINT (which make the clock line global) and the problem disappears. I have had some problems which were solved by using a CLKINT before, but didn't know why it helped. Now turns out it's all about the clock skew problem.

    Yeah, it is a correlator that I'm designing, I tried 2 methods, the other was to use a series of Shift register and Multipliers, but no way it's fit in the chip I was given. The MAC method involves so many problems, it's a nightmare.

    Could you think of any other methods?

    J.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    YEAHHHH, EXCELLENT, I've just tried to put a CLKINT (which make the clock line global) and the problem disappears. I have had some problems which were solved by using a CLKINT before, but didn't know why it helped. Now turns out it's all about the clock skew problem.

    Yeah, it is a correlator that I'm designing, I tried 2 methods, the other was to use a series of Shift register and Multipliers, but no way it's fit in the chip I was given. The MAC method involves so many problems, it's a nightmare.

    Could you think of any other methods?

    J.

    --- Quote End ---

    Glad to help!

    Whilst I have designed a number of correlators ours always have to run flat out so we sacrifice resources to get speed (and use quite large FPGAs). The current one has 140 parallel accumulators and recirculates the complex PN sequence in a 2bit wide 80 bit long shift register (rather than circulating the 24 bit wide data). I've also implemented the same correlator as a Matched Data Filter arrangement - they take more or less the same resources.

    In your case you could maybe reduce the resource usage by changing from using a shift register to using a Circular buffer which would more easily map into a RAM (assuming your Actel has RAMs). The VHDL would be a little bit more complex but the synthesised logic would be much smaller.

    Mark.