Workaround for wrongly assigned DQS pin for DDR SDRAM controller in Cyclone IV FPGAs

[Altera_Forum]

(I don't have any specific questions to ask in this post. I just want to share my experiences of working around this problem.) 

 My company made a board which features a cyclone IV FPGA (EP4CE55F23I7) and a 32MB SDRAM (with 16-bit data bus). The plan is to have a NIOS II processor running on this FPGA, so we need to have an SDRAM. A mistake during PCB design is that UDQS (or DQS[1]) pin was assigned to a wrong pin: it was assigned to pin A20, while it should have been assigned to B13.  (If we open the Pin Planner from Quartus tool, we can see that pin A20 is NOT a DQS pin. B13 is.)  I didn't realize this mistake until I built and tried compiling a small system consisting of: 

• A NIOS-II processor 
• On-chip RAM and boot ROM 
• 8-bit GPIO port 
• DDR SDRAM controller 

  (I am using Quartus 9.1 SP2)  THe Quartus tool reported error for wrong pin assignment for UDQS. Error msg is like this:    --- Quote Start ---  Error: altmemphy pin placement was unsuccessful  Error: The assigned location PIN A20 for DQS pin "mem_dqs_to_and_from_the_sdram[1]" is not a legal location  --- Quote End ---    PCB is already made, and rework is not possible. My colleague in charge of PCB is reluctant to re-spin (more money and time needed). So we wanted to have some work-arounds inside the FPGA bitmap.  We actually tried two possible work-arounds: [LIST=|INDENT=1] [*]Use only low 8-bit of the data interface between FPGA and external SDRAM (hence UDQS is not needed). I re-built the HW and wrote some test SW to test SDRAM write/read access. 

• SDRAM is working. 
• But the problem with this method is that half of the SDRAM space is left wasted (usable space reduces from 32 MB to 16 MB); 
• Also bandwidth between processor and SDRAM is also halved given the same memory clock frequency. For this, I tried increasing memory clock frequency. I increased the frequency from our nominal 104 MHz to 128 MHz, and tested it to be working also. This compensates, to some extent, the bandwidth loss due to halved size of memory. However, it failed when I increased it to 150 MHz. 

  [*]Still use all 16-bit data interface. In this case, I still need UDQS, and I need UDQS to be at a illegitimate pin A20. [/LIST]  For the second workaround, I modified SDRAM controller RTL generated by Quartus and replicated some logic. To be specific, in Technology Map Viewer (post-mapping), I traced from LDQS (or DQS[0]) pin back to the place where this signal is generated . THen I went to the corresponding RTL file (in my case, it is a verilog RTL file named *_phy_alt_mem_phy.v). Here I can see the modules that generate DQS[0] and DQS[1]. Then I replicated the logic generating DQS[1], and change its output from DQS[1] to my UDQS.  By doing this, there are three DQS signals generated in my FPGA bitmap: DQS[0], DQS[1], and my UDQS. 

• Pin assigned for DQS
• Pin assigned for DQS
• Pin assigned for my UDQS in my Quartus project is A20. And A20 is connected to external SDRAM. 

  So in the end, the two DQS signals that external SDRAM actually see are DQS[0] and my UDQS.  I generated and wrote some SW to test this bitmap. The SDRAM read/write is working at 104 Mhz, which is absolutely a good sign. My colleague reminded me that, I can be sure that it is really working only after we run real SW on this board and see no issue. Let's see how it fares in the long run :)   ( THe way I test SDRAM read/write access is that I write C code in NIOS II Eclipse IDE and run/debug it. In the C code, I write some values (say, 0x AAAAAAAA, or 0x 55555555, etc) to the whole range of SDRAM address space, and then read back. I compare read back value against what I wrote. If all matching, I consider pass; otherwise, fail).

[Altera_Forum]

Your second workaround is very inventive and, IMHO, will work 100%. 

In Cyclone IV the DQS strobes are not used to strobe in the read data coming from the DDR device. In stead a PLL-generated clcok is used to capture these read data. Writing some selected values for a memory test is a bit simple, if you truly want to test your memory you need to generate quite complicated patterns to exercise the silicon at its fullest. But to verify whether Altera's IP is functioning it will suffice.

[Altera_Forum]

Thanks for sharing and glad that you found a work around for your system. Regarding checking your solution fully, my suggestion is to create a test system with your modified controller and the Avalon-MM Traffic Generator and BIST Engine, and keep it running across the temperature range, watching the status bits somehow (SignalTap, probes, custom logic, etc.). 

 As some additional information: what I ran into while modifying the ALTMEMPHY to work with LPDDR was that the primary statement in the generated files which causes the fitter to complain about the DQ/DQS signals is the embedded DQ_GROUP clause within phy_alt_mem_phy.v (search for DQ_GROUP). This attribute statement causes the fitter to enforce the pin placement and I/O standard to match it's expected values/rules. Without that statement, the fitter no longer performs those checks and presumably there is some (negative) trade-off for not using the DQ/DQS group, but certainly at low performance points (I have gone up to 150MHz) the resulting system works fine.