SDRAM routing with FPGA

Power Islands can be bad for EMI. Make sure you bridge the island with lots of small caps.

There are tiny little resistor networks. I think they are about the size of an 805 resistor, but they have 4 resistors on them. I don't know the manufacturer off-hand, but I have used them on SBC's. Maybe take a look at CTS.

Could you please draw the complete clock schematic for me? I don't understand from your wording. In general, put resistors close to the clock driver, and put a shunt capacitor near the clock load.

If the clock is coming from the FPGA, and going to a buffer, how much delay does the buffer add? You would probably need to use a so-called zero delay buffer (PLL) unless you can create an offset copy of the clock inside the FPGA (similar to a DCM in the Xilinx line).

Another option is to generate the clock inside the FPGA (if that is what you are doing), feed it to a low-skew buffer, and use three of the buffer's outputs: One goes BACK to the FPGA, one goes to SDRAM 1, and another goes to SDRAM 2. These would all have matched lengths. Inside the FPGA, you would use the clock which comes in from the low-skew buffer in all logic which interfaces with the SDRAM.

There is always overshoot (and undershoot and ringback) on SDRAM data and address lines. I can't remember whether 900mV is too much. You should look at the IBIS model for the SDRAM parts. I think the max overshoot is actually built-in to the model. Or look at the datasheet. Likewise for the FPGA. If the FPGA allows you to specify drive strength, start with the weakest one available.

You can calculate approximate impedance if you know the distance from signal to plane and trace width. Even on a non-controlled impedance board, you can probably get the impedance you want within 20% just by specifying the thickness of the laminate between plane and signal.

Good luck.

--Mac

Thanks for your reply Mac, definitely helpful.

---- Power Islands can be bad for EMI. Make sure you bridge the island with lots of small caps.

-----

Good tip!

----------- There are tiny little resistor networks. I think they are about the size of an 805 resistor, but they have 4 resistors on them. I don't know the manufacturer off-hand, but I have used them on SBC's. Maybe take a look at CTS.

----------

Ok, I wasn't aware of these.. I was sure something had to be made for this purpose since terminations are used everywhere, and probably can't consume as much space as I was seeing....

-------------- Could you please draw the complete clock schematic for me? I don't understand from your wording. In general, put resistors close to the clock driver, and put a shunt capacitor near the clock load.

If the clock is coming from the FPGA, and going to a buffer, how much delay does the buffer add? You would probably need to use a so-called zero delay buffer (PLL) unless you can create an offset copy of the clock inside the FPGA (similar to a DCM in the Xilinx line).

Another option is to generate the clock inside the FPGA (if that is what you are doing), feed it to a low-skew buffer, and use three of the buffer's outputs: One goes BACK to the FPGA, one goes to SDRAM 1, and another goes to SDRAM 2. These would all have matched lengths. Inside the FPGA, you would use the clock which comes in from the low-skew buffer in all logic which interfaces with the SDRAM.

----------

Ok, let me clarify this. I have one PLL out pin from the FPGA going to a Clock buffer under the FPGA (It's a TI CDCVF2310). The pin to pin skew is < 100ps, which I didn't think was significant enough to worry about here. Two outputs from the buffer then go to the SDRAM ICs, one each... and these lines are matched. I terminated them at the load with a series R and parallel C, but I will change that to the R at the source per your advice. Another option I saw was to directly drive the SDRAMs with the PLL out pin, but then I knew I would have balancing issues on each line to the SDRAM since I don't have controlled impedance, and it's tricker than just point to point. Also, the modules are on opposite sides of the board, so the split would have to be at the driver (which I believe isn't good??).

I like your idea about feeding the clock back and using that however... maybe I could try it with just the clock buffer, and if I run into problems, at least I have this as an option?

------------- There is always overshoot (and undershoot and ringback) on SDRAM data and address lines. I can't remember whether 900mV is too much. You should look at the IBIS model for the SDRAM parts. I think the max overshoot is actually built-in to the model. Or look at the datasheet. Likewise for the FPGA. If the FPGA allows you to specify drive strength, start with the weakest one available.

---------------

Agreed; there will always be some overshoot. I am using IBIS models for the FPGA, Clock buffer and the SDRAM... but I am new at SI simulation, so I wasn't aware the max/min parameters were actually specified in the model. I will look at this. Also, I was using typical drive strenght, but I will definitely use weak since it makes more sense.

I guess my biggest issue is the terminators; whether to include them or not. Considering I am releasing the board tonight, I don't think I have much option anymore (except the clock line change) :)

Thanks for your help!

I forgot to ask... out of curiosity, what's the shunt cap at the end of the clock line for (at the load)? I understand the resistor, but I thought AC terminations were done in series with a resistor?

I agree about the skew. I am more concerned with the delay. The min is 1.5 ns, and the max is 3.5 ns. Since your entire clock period is only 10 ns, that is significant. Frankly, I don't think this will work. The problem is that the clock inside the FPGA will be from 1.5 to 3.5 ns out of phase with the clock received by the SDRAM chips. Usually the goal is for everybody to see the clock edges at the same time (match trace lengths from the driver to all loads).

By the way, the clock chip has built-in 25 Ohm series termination.

No, I think it would be OK. Just put a resistor in series with the trace going to each clock.

What you may be forced to do, if the design has already been submitted, is Do Not Populate the buffer, and jumper the PLL signal to both buffer outputs using the buffer pads.

You mean add the trace from the buffer back to the FPGA, but ignore the signal inside the FPGA (unless you find that it doesn't work)? Sure. Why not. But I'm pretty sure it's not going to work with that buffer there, sorry to say.

I hope you had time to do this prior to submitting! ;-)

--Mac

PS, I wouldn't mind hearing about how things went when you bring this design up.

It is for signal integrity and EMI control. The series resistor limits the maximum output current, and helps match the impedance of the trace, and the shunt capacitor can eliminate overshoot. Also, if you find that your timing is just a little bit off the cap can help you fix it.

For example, if you have 10 clock loads all around a board, and you find that one of them is getting the clock just a little bit earlier than all the others, you can increase the cap size until the rising edge is in sync with all the others. Of course there is a limit to how much you can stretch out the edge...

This saved my butt once. My prototype batch of SBC's would blue screen when running the Microsoft Hardware Compatibility Test (typically after a few hours). By using a bigger cap at one of the SDRAM clocks I was able to fix the problem without any layout changes.

--Mac

Thanks again Mac.

Here I was thinking I was being proactive and smart putting that buffer in, and now you tell me that it won't work :) I put in a way to bypass nearly everything on that board, EXCEPT the PLL output directly to the buffer outputs... so it will have to be done by hand :( I submitted last nite, and am waiting for approval on the gerbers, so maybe I should hope for thm rejecting the files so I can fix it :)

This board is essentially a prototype... although it would be nice if all were good the first time. So I didn't add terminations on any data/address lines.. just the clocks. Their electrical length were small enough such that I didn't think it was necessary.

Regarding SI, I don't have a scope... which sucks. But now that I am moving into >100MHz realm, it's about time I get one. What, in terms of scope BW, is usually enough for watching SDRAM-style signals? If I'm running the clock at 133M, obviously I need a BW larger... but how much larger to be safe... I don't have a large budget, I would say $1K. But I'm having a hard time differentiating between the types out there. Correct me if I'm wrong, but I want a 'one-shot' bandwidth to be greater than 133M (for eg.), correct? Because some scopes state repetative capture BW of like 400M, but a one shot of only 150M. Are there any other useful parameters to keep an eye out for? I figure I should at least be able to see the 1-2ns rising edges produced on the board.....

This board is a low-cost embedded SoC linux development board, so I will definitely keep you posted on how it comes up. I really appreciate the help!

I guess I should be careful of what I ask for :) The order was rejected, and the customer service rep is being the biggest pain in the ass. Apparently, my gerbers wo'nt open when I have used both Protel and

ahh the joys of customer service.