Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21594 Discussions

Mobile DDR-SDRAM for Cyclone IV E

Altera_Forum
Honored Contributor II
1,510 Views

Hello Guys, 

 

I am currently trying to implement a mobile DDR-SDRAM PHY layer for Cyclone IV E. I previously implemented a DDR-SDRAM controller using the ALTMEMPHY with my own controller and it is working nicely. 

At the moment, in order to reduce the power consumption of the device I am working on, I have to change the external memory for a mobile DDR. 

I don't want to spend money on buying a mobile DDR IP core and would like to do it myself. The ALTMEMPHY does not support mobile DDR as in these types of memory we have to use the DQS for the read capture, which is not used in the ALTMEMPHY. There is no DLL on cyclone IV E either to delay the DQS. 

Does anyone knows how to make such a controller and what are the steps to follow to get there? I only need the PHY layer (data path for DQ & DQS) as I already have the controller implemented (generating read/write commands and initialization). The targeted bandwidth is 133MHz. 

 

If I am not clear, do not hesitate to ask me more questions! Thanks a lot to everybody for your help.
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
758 Views

I'm afraid that you are a bit out of luck. The Mobile DDR SDRAM specifies the use of DQS for read operation. In contrast with std. DDR2 device the tAC spec is very wide ( 2 to 8 ns in stead of +/- 600 ps) and hence does not allow to use a (fixed or adjustable) clock phase of the PLL to read the incoming data. Even a DLL (as in Cyclone II) will not help because you still need to transfer the captured data into the processing clock domain, and the 'wide' tAC spec doesn't help here.

0 Kudos
Altera_Forum
Honored Contributor II
758 Views

Indeed, the tAC spec is very wide and complicates the problem here. But there are some expensive mobile DDR IP cores that can run on Cyclone IV E. So there must be a way to get there. 

Is it possible to calibrate the required delay of DQS for read capture at startup and then keep the same delay for the rest of the time? Or is tAC constantly changing over time? 

 

From what I have seen, the available IP cores seem to be using a fixed delay on DQS. I guess it is just a matter of calibrating then? 

 

thanks,
0 Kudos
Altera_Forum
Honored Contributor II
758 Views

In theory you can train the phase offset of the read clock to capture the data in the middle of the DQS signals. You would have to track it over the Voltage and Temperature variations during operation (as AltmempPHY does). As the capture clock has an undefined phase to the internal process clock, you will need to insert a dcfifo in the read path (as AltmemPHY does ...) adding some latency. 

I have been dabbling a bit a writing my own PHY for DDR2 and this is already complicated in timing, the training algorithm adds a lot of complexity (in UniPHY Altera even added a NIOS II CPU to do this!). 

I'm afraid that you're stuck with 'six of the one or half a dozen of the other'
0 Kudos
Altera_Forum
Honored Contributor II
758 Views

In a DDR/DDR2 controller, I guess that it is only necessary to train the phase offset once as this offset will be quite stable during operation. I guess this is what the ALTMEMPHY is doing during calibration. 

But in a mobile DDR controller, this phase offset will change (quite a lot) with the temperature and voltage changes. Then I guess the only way to implement a mobile DDR phy is to have an external temperature sensor and dynamically adjust the phase offset? 

Is my understanding correct? Do you know how the voltage and temperature compensation works? 

 

thanks a lot for your help,
0 Kudos
Altera_Forum
Honored Contributor II
758 Views

The AltmemPHY tracks a 'mimic' clock for variations. I a Mobile design I would try to track the DQS signals. But things get complicated and finally one has to decide: 'build or buy'. Or go back to std DDR2 or perhaps DDR3 (in case of single device there should be little difference, although I haven't studied the DDR3 specs to that depth). 

Using an external temperature/voltage sensor compensation will take a lot of calibrating, I assume?
0 Kudos
Altera_Forum
Honored Contributor II
758 Views

Hello, 

 

Thanks for all your anwsers. I finally decided to dive in and implement my own PHY layer for mobile DDR. 

It is working quite well at the moment, running at 133MHz. 

 

Thanks!
0 Kudos
Altera_Forum
Honored Contributor II
758 Views

 

--- Quote Start ---  

Hello, 

 

Thanks for all your anwsers. I finally decided to dive in and implement my own PHY layer for mobile DDR. 

It is working quite well at the moment, running at 133MHz. 

 

Thanks! 

--- Quote End ---  

 

 

Can you share your mobile ddr IP? 

Thanks!
0 Kudos
Reply