ddr interface dqs phase shift in UltraScale+ device

[charlie_xie]

Hi, I'm working on an asic-based design which has a ddr interface. I want to imply a phase shift on dqs in order to catputure the data properly.  I'm not going to use the IP provided by Vivado because I need to keep design consistency between ASIC  and fpga . The problem is dqs phase shift.

There are two ways , one is using IDELAY on dqs path, another is using mmcm to get the 90 degree phase shift. Since  Chapter 3 of UG949 says, in Ultrascale devices the IDELAY cannot be used on clock on input clock path,  MMCM seems to be the only way.

This means I have to connect dqs  to clkin1 port of MMCM directly. But from MMCM simulation results, I found that when implemented MMCM phase shift functions, there was a latency at the output clock, which is necessary for MMCM to do calibration,  500ps after clock inputs,  the MMCM began to output clock. The question is ,during the calibration, the data and clock on the input port are real, they are missed during the calibration. Is there any way to remove the lateny, or another way to implement phase shift without latency?

Thanks in advance.

Charlie

[charlie_xie]

Spoiler

@avrumw 

[avrumw · Accepted solution]

What you are proposing is not going to work. The MMCM can only work with a continuous clock, the DQS are gapped and bidirectional, there is no way this is going to work with the MMCM.

As a larger statement, what you are trying to do is not likely to be doable. DDRx-SDRAM interfaces are probably one of the most challenging interfaces in terms of architecture and timing, but yet they are essential for a huge range of systems. As a result, Xilinx has put in very specific architectural features for dealing with DDRx interfaces - in fact, one might argue that the entire design of the "native mode" I/O in UltraScale/UltraScale+ was designed around the implementation of these interfaces, with everything else being secondary to that concern. However, to use them, you pretty much need to use the Memory Interface Generator (MIG) to, at least, generate the Physical Layer of the interface. Trying to implement your ASIC physical layer in the FPGA is probably simply not viable.

I haven't played with the MIG in a while - it used to be possible to generate the Physical Layer only, which would still allow you to (at least in theory) connect to the bank state machines and other logic in your upper levels of your ASIC controller. But this is not going to be an easy thing - even if the MIG allows you to generate the PHY layer, the interface it leaves you with is certainly going to be different than the protocol used anywhere inside your ASIC controller...

Avrum

[charlie_xie]

Thanks Avrum. You are really helpful.