08-17-2018 05:53 AM
I am working on a high bandwidth Interface controller to use HyperRAM PSRAM memory. Which is in essence an 8 bit wide bidirectional DDR bus clocked by the master (FPGA) and an additional strobe and chip select signal.
I am using 4 phase shifted clocks: 0°,180° for IDDR2s and data ODDR2s and 90°,270° for the ODDR2s producing the clock outputs.
However I am struggling with setting up the timing constraints for the IO, as place and route fails to meet a 0ns (?) requirement for the paths DQ<0..7> (IO Pads) to IDDR2_DQ<0..7> (corresponding IDDR2 instance).
How do I correctly specify input and output timing constraints for a bidirectional pin in respect to an internal clock signal (genererated by PLL)?
Thanks in advance.
08-17-2018 06:16 AM
08-17-2018 08:12 AM
It always helps is you show both your constraints and the detailed failing path report.
But as a start, take a look at this post on constraining source synchronous edge aligned DDR input interfaces. While your interfaces are both inputs and outputs, the concepts explored here will apply...
08-17-2018 08:21 AM - edited 08-17-2018 08:21 AM
Oh - I just noticed that this is on the Spartan Family forum - so this means (presumably) a Spartan-6 on ISE.
What speed are you trying to obtain, and (as @jheslip asked) are you attempting to capture this interface statically or dynamically?
Static capture on the Spartan-6 is pretty limited in terms of frequencies, and high speed I/O interfaces are always complicated. You need to make sure that your goals are realistic; the devices you reference can do 166MHz in a DDRx type interface (with dynamic strobes and such). DDRx type interfaces (i.e. DDR3) are very difficult to do with the Spartan-6 I/O, which is one of the primary reasons for Spartan-6 having the built-in dedicated memory controllers (which probably can't work with these devices, since they aren't true DDR3 devices). Even if you do try to do them with conventional I/O, they are almost always done through the MIG IP core, which (again) probably won't work with these devices.
What you are trying to do here has the possibility of being VERY difficult (if not impossible).
08-20-2018 04:37 AM
Yes, I'm using a Spartan 6 (xc6slx16-2csg225).
There is no dynamic calibration involved in the interface, if this is what you are asking. The signals from the memory chip are synchronous to the CK/#CK input clock. Would you advice to use some kind of calibration?
Do I need to put all pins on the same half bank to achieve better performance?
It seems I am running against the wall using the Spartan 6 in my application:
It would not only require an interface speed beyond 100Mhz to buffer the input in time. It is also already running quite hot(>60°C outside waterproof enclosure) from capuring the input data (2 sensors with 2x 680Mbps LVDS lanes each).
In therms of realistic goals: Would you expect to be able to reach at least around 70MHz with this approach, or what can expect?
Would it help to switch to low end a 7 series device (e.g. low density Spartan 7) for both power draw (or more crucially heat dissipation) and a higher bandwidth Hyperbus implementation? What interface bandwidth/frequency could I reasonably expect to reach with the new devices?
08-20-2018 09:07 AM
70MHz DDR is a 7.14ns data eye. The timing of this interface with respect to the clock input is pretty bad (1.0 to 5.5ns), which eats 4.5ns of this 7.14ns data eye, leaving only 2.64ns of window. This may or may not be achievable - you will have to do some serious work to prove this interface...
You would have a far better chance of meeting timing using the RWDS strobe, (+/- 0.45ns skew in the fastest speed grade), but clocking something on a strobe is complicated (and it is even more complicated to get this data into a continuous clock domain).
Furthermore, ISE is terrible at timing interfaces like this - the constraint format (UCF) is very limited for describing "advanced" timing.
So, yes, you would be better off with a 7 series device - they are faster, and Vivado is far more capable than ISE for this kind of timing constraints. But I still won't guarantee that this is easy (or even doable)...
Are you sure this is the right device to use? Why not use a conventional DDR3-SDRAM (rather than this self refreshed RAM)? While DDR3-SDRAM is more complicated, you can use either the built-in memory controller in Spartan-6 or the MIG IP in the 7 series to drive it - this takes all the interface and constraint problems "off your plate"...
08-22-2018 02:10 AM
The memory has been integrated in short notice as an afterthought, in case we need it. The small size and low PCB complexity made it look like a good fit (quite packed PCB, only 19mm wide). Turned out we need it for basic operation and the chip can't handle the interface as easily as we hoped for (live and learn).
I found a project on github for a low bandwidth, portable implementation(no PLL phase shifting or DDR IO) of a HyperRam Controller and used it initially for basic functional testing:
I've tried to increase the the frequency to 136MHz (which equates to a 34MHz/68MBps bus speed, as the phase shift is done by dividing the input clock) without problems. I guess it will get dicey quickly if I try to get much higher.
The repository also includes a more hardware optimized implementation (similar to what I've tried for the Spartan6) for 7 series devices (hr_pll.zip). In the header of hyper_xface_pll.v the contributor reports to have reached 90MHz/180MBps. I guess that will be as good as it could get for the Spartan 7 without breaking an arm and a leg.
For now I will have to make do with what I have and make the prototypes working with some workarounds. I will consider migrating for the next design iteration, also to lower the power consumption and heat dissipation.
I will also reconsider the memory options like standart DRAM (if I can fit it on the board), two HyperRam chips side by side or some other memory which fits PCB size and bandwidth requirements(170MBps) to buffer 2MB of input stream data before forwarding it at a lower rate, or even use an FPGA with sufficient BlockRam.
08-22-2018 02:19 AM
Ok, I had a look at the 7 series lineup: Devices which would offer enough BlockRam (large Artix and Kintex) come in packages wider than the outer case diameter. I won't dare to ask the price.
03-07-2020 08:12 AM
HyperBus looks very similar to DDR SDRAM, just one byte lane. Does Xilinx have this on their roadmap for support in 7-series MIG? I've attempted to "roll" our own interface, but it is proving to be difficult. I do not have a free running clock because of using RWDS as clock edge. How do I transfer from "RWDS" clock domain to internal clock domain?
If we spin a board now, I will have RWDS on SRCC or MRCC. But if Xilinx could provide support, I have a feeling RWDS would be on a DQS pin. How do we get access to Xilinx magic behind the scenes for PHASER and IN_FIFO?
There is a third party HyperBus core available today, but I do not think they are PVT tolerant.