Forum Discussion

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

Waitrequest ALTMEMPHY DDR2 Controller

Hi,

I have a problem with the ALTMEMPHY DDR2 Controller. I try to build a FIFO using the external DDR2 ram. In principle, the FIFO works but I do not achieve the required speed. With a (own written) memory mapped master interface I try to write in burst mode to the memory controller. But as soon I write one word, the memory controller sets the waitrequest_n flag for three clock cycles. Thus my write efficiency is not more than 25%. I attached a screenshot of a signal tab recording including all signals of the master interface. The clock for the memory mapped interface is 50MHz. The DDR2 itself runs on 150MHz. Did I miss a signal in my master interface? Are there some parameters to adjust? Let me know if you need more information. (The beginbursttransfer signal seems to have no influence in writing mode.)

Thanks

Christian

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Take some screenshots of your memory parameterization. Are you making sure your master and the local interface of the SDRAM controller are on the same clock domain? (called sysclk... or something similar from the SDRAM controller PLL)

    Also I don't recommend ever implementing beginbursttransfer. That's a signal that is not necessary and it's also difficult to time since it doesn't heed waitrequest. As far as I can tell your master is doing nothing wrong so I suspect there is a clock crossing between it and the memory. The asynchronous handshake clock crosser that automatically gets inserted can only let one transfer through at a time while the data changes clock domains which is what it looks like in your STPII capture.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Hi BadOmen

    Many thanks for your answer. So the first thing I did was to remove the beginbursttransfer signal but nothing changed. Then I checked the parameters of the DDR2 Controller and the clocking. Unfortunately, I can’t find an error. There are some screenshots in the attachment.

    Some more information that may be important:

    - Using Quartus II version 12

    - FPGA: EP4CE75F23C8N

    - DDR2 RAM: W971GG6JB-25

    - RAM is connected to Bank7 and Bank8 (thus on the top I/O banks, right?)

    Thanks a lot and best regards

    Christian
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Yep it's clock crossing causing this. That DDR_FIFO_0 component is on the "pll_c0" clock domain meanwhile the SDRAM slave port that it connects to is on the "DDR_sysclk" domain. Switch the DDR_FIFO_0 clock domain to DDR_sysclk and you should not get a clock crossing adapter between the two components and you won't see the waitrequest throttle your master much.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Hi BadOmen

    Many thanks for your help. You were right! Now it works as desired. Thanks to your hint I found this issue also described in the documentation for the ALTMEMPHY.

    Best regards

    Christian
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    This is probably one of the most common mistakes I have seen others make..... including myself from time to time. Unfortunately it's more difficult to spot this mistake in Qsys. In SOPC Builder you would see a bunch of messages about "clock_0", "clock_1", etc... fly by the screen when the system is generating which was a hint if you were running into this.

    In Qsys you can setup the type of clock crossing technique used, for example you can force it to instantiate clock crossing FIFOs instead of the handshake ones that were generated into your system. The handshake clock crossing adapters move only one word of data at a time which is why you were seeing that efficiency problem. The FIFO clock crossing adapters use dual clock FIFOs to move the data between domains and they can handle multiple transactions in flight. This option is only available in Qsys, to get the same behavior in SOPC Builder you would have to use the clock crossing bridge which implements practically the same thing.