Forum Discussion

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

Unable to write on SDRAM on DE0- Nano Cyclone IV E - waitrequest

Hi,

I have a problem on a project on De0-Nano eval board (Cyclone IV E).

I have no idea where look or what I'm wrong.

I design a system made by: a I2S receiver connected to a fifo and the fifo to a Master Avalon-MM (Qsys System).

The strange behaviour is: I cannot write on SDRAM when I use the signals generated by I2S signals instead works correctly with the below piece of VHDL

	process(clk, rstN)
		variable cnt : integer range 0 to 255 := 0;
	begin
		if (rstN = '0') then
			count <= (others => '0');
			ready <= '0';
						
		elsif rising_edge(clk) then
			if count =  0 then				
				ready <= '1';
				left_channel_in 	<= x"1234" & std_logic_vector ( to_unsigned( cnt, 16)  );
				right_channel_in 	<= x"ABCD" & std_logic_vector ( to_unsigned( cnt, 16)  );
				cnt := cnt +1;
			else
				ready <= '0';
			end if;
			
			count <= count + 1;
			
			
		end if;
	end process;

Below, the signals on avalon bus, in the case of usage of above vhdl

http://www.alteraforum.com/forum/attachment.php?attachmentid=11997&stc=1

If I connect the I2S Reciever to rest of system, it doesn't work, see the image (the waitrequest after the first write never goes low)

http://www.alteraforum.com/forum/attachment.php?attachmentid=11998&stc=1

I don't understand why : in both tests the code which manages the SDRAM is the same and I write in both case to a fifo.

Has Anyone an idea?

3 Replies

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

    Attached the compilation reports generated by Quartus on both scenarios.

    I made a diff and see (last part of files) some differences between Timing constraint but I don't know if these are the reason of issue.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi,

    The simulation plots you attached are so tiny it's impossible to read them.

    Good idea to diff the compilation output, I wish I had thought of doing that before, Quartus generates so much output.

    I also diffed the files and I see two other differences besides the timing issues:

    ko.txt:

    Warning (10036): Verilog HDL or VHDL warning at de0_nano.vhd(378): object "step" assigned a value but never read

    ok.txt:

    Warning (10036): Verilog HDL or VHDL warning at de0_nano.vhd(320): object "i2s_rx_data_valid" assigned a value but never read

    That warning about i2s_rx_data_valid never being assigned a value sounds fishy to me.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi,

    those warnings are caused by two different configuration of the system (KO and OK): in one case (KO) I use "i2s_rx_data_valid" in the other "OK" the signal step.

    In any case I decided to clean this and bring the qsys system on top-level module: the funny thing is now seems to work (I'll post the whole system code) but I'm really afraid because this means (maybe, I'm investigating) a change in place&route makes the design not working.

    One interesting result: the TimeQuest Analyzer report only 1 "Worst-Case Slack" on clock signal to SDRAM, but I'm not able to evaluate this report and if I have to do anything.

    https://www.alteraforum.com/forum/attachment.php?attachmentid=12003