Forum Discussion
Honored ContributorTrouble adding additional F2H_SDRAM Port
Hey there!
I've been working with the Quartus/Qsys environment for about 9 months now and have come across a very frustrating problem: The SECOND F2H Sdram (write-only) port I add does NOT work. The waitReq line from the added port remains high whenever I request a burst transfer and it stays high, locking up my state machines. The frustrating part is that the first F2H sdram port works perfectly fine, even as the second one is hung up. I followed this thread describing a similar problem: http://www.alteraforum.com/forum/archive/index.php/t-41489.html I made sure to recompile the preloader after qsys and quartus are done compiling. The first working F2H sdram port is 32-bit (I get a warning about not using the total 64 available bits). The second, non-working port is 64 bits. (Ive changed it to 32, but that didn't work). My design environment is split. I run quartus and qsys in Windows 7 and then I generate the pre-loader from the bsp-editor in Ubuntu Linux running in a virtual machine. I download and compile Critical Link's uboot source instead of the stock uboot from Altera. (Could this be it?) Any help would be greatly appreciated! Thank you!3 Replies
Altera_ForumI can't tell from the screenshot since it's really blury but it looks like you are exporting the Avalon-MM slave ports of the F2S interfaces so are you making sure to adhere to the Avalon-MM specification in your logic hooked up to those ports? For example, when the port is setup for Avalon-MM there is a 8-bit burst signal but if you don't adhere to the spec you could end up posting an unsupported burst size (8-bit burst signal means you can only post burst of 1-128). Normally I tell users to just simulate their system because things like that will be caught through assertion statements but since your masters are integrated outside of Qsys that won't be the case.
Other things to watch out for is that once you assert read or write you must keep it asserted until the transaction completes. Completion of a transaction occurs on the last beat of the burst when read/write is high and waitrequest is low. I could keep rambling on but if you haven't already done so I would review the rules in the Avalon-MM specification. I doubt your split enviornment is causing this unless you are mixing tools versions.- Altera_Forum
hi ,
You can download the hardware / software for reference. It has two software project, one is bare-metal (DS-5), the other is NIOS-II. That move data from On-Chip RAM to HPS' DDR3 via F2SDRAM bridge. https://www.dropbox.com/s/mwjpyzwrecq6m6w/f2hsdram_src_nios2_13.1_20141117.7z?dl=0 - Altera_Forum
I also have the same trouble with you: first F2H_SDRAM0 work is normal, second F2H_SDRAM0 work abnormalities, waitrequest signal after writing a few words has been maintained at high level. Did you solve the problem? How to solve the problem, you can share the experience?
Thank you
