Noise in DDR FPGA implementation

[gregoireg]

I have a DDR memory Winbond w9425g6kh (https://www.winbond.com/resource-files/w9425g6kh_a02.pdf) connected to a Lattice MachXO3 (http://www.latticesemi.com/~/media/LatticeSemi/Documents/DataSheets/MachXO23/DS1047-MachXO3-Family-Data-Sheet.pdf?document_id=50121).

Unfortunately, this chip has no hardware DDR support (there is some gDDR but it's not bi-directionnal). I had to implement my whole DDR design for command and data.

It synthesizes and there is no timing error up to 130MHz. Above 96MHz, I start to see some noise on the real hardware. Here is an example of a written/read pattern to DDR from the FPGA with some noise at 108MHz (at 96MHz, it's perfect):

Code: [Select]

01 23 45  67  89 AB CD EF 01 23  45  67 89 AB CD EF
01 23 45 *65* 89 AB CD EF 01 23  45  67 89 AB CD EF
01 23 45  67  89 AB CD EF 01 23  45  67 89 AB CD EF
01 23 45  67  89 AB CD EF 01 23 *C5* 67 89 AB CD EF
01 23 45  67  89 AB CD EF 01 23  45  67 89 AB CD EF


Obviously, the more I increase the frequency, the more I see errors. Depending of the frequency and the implementation, the noise can be anywhere. In other words, it doesn't seem to be related to a specific pin.

Any idea of how I could fix my problem? Here are a few remarks:

- there is no timing error reported by the "Place & Route Design" engine of Lattice Diamond up to 130MHz.

- There is no error in the simulation. Up to 96MHz, everything is perfect on real hardware.

- I have the following pin settings:
IOBUF PORT "ddr_Clk" IO_TYPE=LVCMOS25D PULLMODE=NONE SLEWRATE=FAST ;
IOBUF PORT "ddr_Dq[0]" IO_TYPE=LVCMOS25 PULLMODE=NONE SLEWRATE=FAST ;
IOBUF PORT "ddr_Dq[15]" IO_TYPE=LVCMOS25 PULLMODE=NONE SLEWRATE=FAST ;
IOBUF PORT "ddr_Dqs[0]" IO_TYPE=LVCMOS25 PULLMODE=NONE SLEWRATE=FAST ;
IOBUF PORT "ddr_Dqs[1]" IO_TYPE=LVCMOS25 PULLMODE=NONE SLEWRATE=FAST ;

- There is a 2V5 voltage divider (resulting in 1.25V) on VREF of the DDR chip.

- The routing between MachXO3 and DDR is "pretty" clean and homogeneous. Chips are on different side of PCB just back to back. There is the same via type for all the traces. The maximum difference of traces length is <250mil. I calculated that at 125MHz, it's a maximum 2.5% deviation. I don't think that I'm running at a speed high enough to see some hardware-related problem.

I'm looking for generic advice what to look for and change. I'm expecting:
- any idea of pin configuration (http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/MO/MachXO3sysIOUsageGuide.ashx?document_id=50125). Slewrate seems to help but not opendrain.
- any advice how to isolate the problem
- any recommendation of more timing constraint

[ace1903]

As a embedded software developer I would try it to find if it is really noise or maybe limitation of eye opening of the signal.
Will approach the problem with longer sequences of same data, like 512 zeros then 512 0x01 bytes ,then 512 0x02 bytes up to 512 0xFF.
Think that some bit pattern is incorrectly decoded due to small eye opening.

If errors are not related to data then maybe adding some capacitors can make design better.
Post pictures of the hardware maybe we will get some ideas what can be culprit for errors..

[gregoireg]

I have not done precisely this pattern but my main objective is to store image and the problem appears more when data bits are changing, meaning that a large area of same color seems less impacted.

My feeling is that DDR is SSTL_2 with a "small" swing around 1.25V while LVCMOS goes up and down between 0 and 2.5V. I know that I'm never going to go up to 200MHz but I was hoping for better than 96MHz.

There seem to be some options for each pin of MachXO3 (for instance pF load, slewrate (already used)...) and I was wondering how I could force a cleaner signal to avoid the wrong bits.

[asmi]

First of all, I would suggest you to find out if the issue is with reading or writing. For that try writing something into the memory and then reading 10 times from the same address and see if you're getting the same values every time. If you are - then them problem is with writing, otherwise it's reading.
I actually expect the issue to be happening during reading, because LVCMOS input requires much larger swing that what SSTL output is supposed to provide. Conversely, SSTL input should have no problems reading LVCMOS levels as they are much farther away than what SSTL is supposed to handle.
I'd also check for the crosstalk by looking at the layout and sending-receiving a pattern such that 1 and 0 would fly on neighboring traces, followed by just a single 0->1->0 transition to identify exact track which is causing the problem.

[Ice-Tea]

I thought trace lenght mismatch within a data lane was far less? Have you checked layout guidelines?

[gregoireg]

What bothers me is that I have just changed a routing strategy setting in Lattice Diamond and now, everything is working well at 108MHz. I never managed to get something working above 96MHz before. This Lattice software is just a giant blackbox regarding routing and you don't know what's going under the hood while the simulation is totally fine.

[OwO]

If changes in internal routing affect I/O timing, that means you didn't use the IOB flipflops which would explain why the interface is marginal. You must have at least 2 stages of flipflops on all inputs and outputs, one IOB flipflop and one fabric flipflop (because the two are far away). If you simply infer two flipflops the tools will automatically pack one of them into the IOB.

[gregoireg]

I don't understand this last comment and I think that it's important in my situation. Can anyone explain it to me?

This link https://www.cnblogs.com/free123/p/10237047.html seems to talk about the same thing.

A recommendation of settings (specific to Lattice Diamond) and even better some synthesis comments would certainly be helpful.

My guess is to leave "Auto" for "IO Registering" in the general settings and add some synthesis comments on the DQ/DQS wires.

[nctnico]

What bothers me is that I have just changed a routing strategy setting in Lattice Diamond and now, everything is working well at 108MHz. I never managed to get something working above 96MHz before. This Lattice software is just a giant blackbox regarding routing and you don't know what's going under the hood while the simulation is totally fine.

Look for setting timing constraints. I don't know about lattice specifically but you probably have to set constraints for inputs and outputs in respect to the clock. This may include setting delays so you align the clock edges with the data. This will require working out the timing on paper first and then set the timing constraints accordingly.

[OwO]

I don't know about lattice tools but on Xilinx and Altera tools you can view the post-map schematic, which will tell you if you have an IOB flipflop on the pins or not. The first thing you need to verify is that the design actually has at least two flipflops in series on every pin. You can check this using the post-synthesis schematic.

[mfro]

What timing constraints did you specify for the interface? I would try and decrease the valid window to the minimum margin that allows to still meet timing.

Not familiar with the Lattice toolset, I suppose it will work similar like the Intel/Altera tools where the fitter will use any degree of freedom you are willing to give it and stop its optimization attempts as soon as it meets timing with the given constraints. Tighter timing constraints will increase the effort the fitter invests, tighten the data eye and improve e.g. alignment of indivudual bits.