Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20642 Discussions

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

Altera_Forum
Honored Contributor II
909 Views

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?
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
287 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
287 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
287 Views

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
0 Kudos
Reply