Forum Discussion

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

Trouble 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_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    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