DDR2 pin assignment

[Altera_Forum]

This is a very long shot, probably nobody will answer this, but here I go just in case. 

 In Quartus II 11.1, for an EP4CGX50CF23C7 (F484 package, speed grade 7), I instantiated an altmemphy interface to a Micron DDR2, assigning DQ1 to Y7 and the fitter gives the following error:   Error (165011): altmemphy pin placement was unsuccessful Error (165050): The assigned location PIN Y7 for DQ pin "mem_dq[1]" is not a legal location   How can this be possible, if Y7 is specifically marked as good for a DQ signal (says DQ3B ) for X8/X9 and X16/X18 in the http://www.altera.com/literature/dp/cyclone-iv/ep4cgx50.pdf pinout document?

[Altera_Forum]

ddr pins work with the other ddr pins. 

it should be assigned with same group of dq-pins and dqs pins. however, if you want to know which location should be good for your system. remove pin assignment and compile the project. and use back-annotate. it automatically assign certain pin. and you can change your schematic..... if it is not done yet.  you can write ddr logic by yourself.( that is tough stuff ) if your schematic is done, you can find another way to fix the problem.

[Altera_Forum]

Thanks for the answer akira. Unfortunately the schematic is done... even the layout... even the board ! (well, just a prototype)  

 Not sure what you mean by 'it should be assigned with the same group of dq-pins and dqs pins', but just to clarify, all dq and dqs are in the same bank (3), and they are all in pins marked as DQ, DQS, and DM respectively in the pin list for this device.

[Altera_Forum]

From what I can tell right now, for every DQS, there are limited options for DQ and DM lines. The problem is that in the board they are scrambled (DQ's for DQS0 are within the options of DQS1 and viceversa), so only a few are 'correct'. I tried relaxing the timing requirements of the memory, and even reducing the frequency, but it makes no difference, the fitter will complain anyway. Even the DMs are swapped. This is completely undocumented from what I've read, only found when synthesizing and fitting (development was backwards due to time constraints). 

 Does anybody know a way around this ??   My only idea right now is to use the ones I have correct and leave the other pins with pullups. Will complicate the design internally and halve the effective bandwidth and capacity but it is better than nothing.   Regarding the DM (data masks), I figure they can stay low all the time and simply not mask anything, which is fine.   Not sure if there will be an issue regarding the registers in the memory that altmemphy may try to configure... don't know enough about this.    Any info on any of this would be useful.

[Altera_Forum]

The Cyclone IV handbook has a section on External Memory Interfaces that I believe is pretty clear on having specific DQ/DQS groups. I don't say that to be mean, but am wondering if it's not clear enough? 

I am also a huge advocate of building a framework for the design before building the board. I know that's difficult to do, but I've seen more than enough cases where it costs more time in the end. Again, I don't mean to be mean. Finally, please file an SR to see if there is any way to disable this check. Since this is probably just a test board now, that might free up any restrictions. Note that Stratix devices have dedicated paths and logic in silicon that absolutely require the pairing of a DQ with its DQS, but looking at the CIV datasheet, I don't see anything similar. It may be this is more of a software check, in which case maybe you can get a workaround. A longshot, but would help if it works. Good luck.

[Altera_Forum]

I got bitten by that same snake. 

As Cyclone IV (and III) has no DLL there is absolutely no reason why the DQ, DQS and DM pins would be fixed to certain locations (of course other observations like SSN an DDR registers enter into the equation). AltmemPHY uses a phase-shifted PLL clock to capture the read data (DQS are only driving out). But it probably was deemed too much work to re-do the IP and the documentation proper.

[Altera_Forum]

Yes, the handbook has instructions on using the Pin Planner for finding this out. Better would be for the pinout documents to label the DQ and DM pins in a way that relates them with their respective DQS pin, instead of just being generic (they only specify bank). Perhaps there is a reason for this, but it is definitely misleading. 

 I've submitted a SR for this.

[Altera_Forum]

The other possibility is that it was analyzed/tested with these I/O, and they might have better SSN, so the user might as well use them. An error is good in that it gets the user's attention so they can fix it before board layout, but is very bad after board layout. File an SR, say the board has been laid out, it's only a test, and is there any way around it. It's a hail mary, but worth a try. (For all I know, there may be a physical reason for this requirement, although it doesn't seem so on first glance...)

[Altera_Forum]

So far in the SR the information that I have received is: 

   --- Quote Start ---    We don't have the accessibility to disable the software check for the legality of these pin assignment. This Quartus II is develop by the engineering team. Unless a special patch is design for special case but this will have to go into special request.    --- Quote End ---     I am now inquiring if the interface is still useable, if the pins are assigned in a way that Quartus lets the compile go through, since altmemphy does some initialization and calibration when it starts. The idea is that the pins that were routed properly will still work, provided the DMs are stuck to low.