Slowing FPGA Transition Times

[dknguyen]

Is there anything FPGA configuration setting or manipulation of the clock edges for FPGAs that allow you to slow down the transition times to relax termination requirements when you aren't trying to run the FPGA at very fast clock speeds? I'm curious about all FPGAs in general, but I plan to use the Spartan 3A-DSP.

Does anyone also have any idea what happens on a daisy-chained bus when each device has a series termination resistor? This paper:
https://www.electro-tech-online.com/custompdfs/2010/07/xmsnLine_notes.pdf
only talks about series termination at the source. It also says "In order to satisfy Kirchhoff’s laws, a voltage wave of the opposite polarity propagates back down the line, canceling the original wave." and I'm having trouble figuring out exactly why that is for transients.

EDIT: I hunted around on some EDA boards and they mentioned something about selecting IO standards with slower transition times? And that it's bad practice to do things like add capacitors-to-ground to the line, or add RC filters to slow the transition time (which is rather impractical anyways since you have hundreds of IO running around). Especially for the capacitors-to-ground it since it seems like it could easily start to increae heat on the drivers. Anyone care to elaborate or add their own thoughts?

 

[crutschow]

If you are trying to run the FPGA at fast clock speeds, then you likely need the fast transition times to maintain signal integrity. It's poor practice to try to degrade the signal just to allow for poor transmission line design.

If your read further, the statement "In order to satisfy Kirchhoff’s laws, a voltage wave of the opposite polarity propagates back down the line, canceling the original wave." refers to having a short circuit at the far end of the line. The next paragraph talks about the far end being open circuit (b), which is the case for a typical digital bus application.

On a daisy chained bus, only one output source is active at a time, the other outputs are in a high impedance state. Thus the line only sees the series termination of the active output. (A series termination is only used at the output, not the input).

For added explanation look at the paragraph on Pg. 5-6 titled Series Termination (of Transmission Lines) in this.

 

[dknguyen]

I was wanting to run the FPGA at slower clock speeds for more relaxed timing requirements during routing and the system itself isn't all that fast anyways. But if the transition times of the FPGA are fixed for realy high clock speeds, then I have to deal with terminations that ultimately aren't needed. These things can run at like 250MHz but I only really expect to need MCU speeds really...50MHz tops, usually 25MHz.

 

[crutschow]

A reasonable rule-of-thumb for transmission line effects being a problem on a circuit board is when the transmission line length in inches is greater than 3 times the signal rise-time in ns.

You could slow the signal rise and fall times by adding a series source resistor of about 100 ohms with a small capacitor to ground. For example 50pF would give a rise/fall time of about 5ns.

 

[BrownOut]

Hi dknguyen, There are ways to slow down the transistion times of the I/O's if that's what you want to do. You can set slew rates on most FPGA I/O pins. You would set the slew rate in the .UCF file for your project. If you need more help, I'll try to look up how to do that.

 

[dknguyen]

THanks, that all I Needed to know...for now...

...

 

[Mikebits]

When I worked at Qualcomm Inc. It was standard practice by all engineers to use a series resistor on the source and a RC shunt on the termination. If a a daisy chain was in the picture the source series resistor was still used and the RC shunt was placed at the end of the chain See attachments.
Note: we only did this on critical nets that drove edge triggered devices such as clocks, read/write etc. data lines and address bits not such a concern as it is assumed they are stable already. This technique is really not used to slow slew rates, but rather ringing overshoot and undershoot associated with high speed signals.
During signal quality test using DSO and low inductance ground lead probe of critical nets, if the Series R was found to not be needed we would use a 0 ohm resistor, if the shunt was not needed we would make it DNI (Do not install).

And yes I do recall when using Xilinx Virtex parts, we could set the slew rate of the I/O. I am sure each FPGA manufacturer has their own way of setting that feature.

Also see Howard Johnson;s comments (Renowned High speed logic designer)
http://www.sigcon.com/Pubs/news/2_24.htm

 

[dknguyen]

Yes, I am just trying to decide whether to have series resistor termination placeholders or not. Especially since I don't know and can't measure the characteristic impedance of the trace beforehand. I might just end up slowing the slew rate and limiting the clock speed.

I was considering making stackable modules but that brings up termination problems since now you have daisy chains and series resistors won't work anymore. It'd be easy enough to build a simple module to plug into the top of the stack that provides parallel termination for such a case though, but that still leaves an unterminated stub betwee the B2B connector and FPGA pin.

Vague question, but If I turned slew rate to maximum and just stayed around MCU speeds, what is the likliehood that I'd have to inspect all the signal lines with an oscilloscope to make sure there was no ringing and that termination might be needed? It's not really standard procedure to do on "most" microcontroller projects. I'm just trying to gauge just how big of a problem it might be.

Mikebits-
is that series R still present with the parallel termination in the daisy chain just to relax the matching requirements of the parallel termination? I read that parallel terminations are more sensitive to placement than series terminations because in any case series termination will dampen ringing on the entire line.

 

[Mikebits]

Mikebits-
is that series R still present with the parallel termination in the daisy chain just to relax the matching requirements of the parallel termination? I read that parallel terminations are more sensitive to placement than series terminations because in any case series termination will dampen ringing on the entire line.

I will start with the placement question. Placement is not real critical but it is always best to place the shunt termination as close to the termination point as possible. For your first question; in general practice I have always laid the pads for series and RC shunt terminations and ended up either using a 0 ohm for series with RC or some series R and DNI for the shunt. Only in case with really long ugly lines have I needed both. Adding 0805 pads is cheap, easy, and uses little space. Simpler to plan ahead, and stuff a zero ohm or make a DNI than re-fab the board.

 

[Mikebits]

I was considering making stackable modules but that brings up termination problems since now you have daisy chains and series resistors won't work anymore. It'd be easy enough to build a simple module to plug into the top of the stack that provides parallel termination for such a case though, but that still leaves an unterminated stub betwee the B2B connector and FPGA pin.

Are you saying that you plan to run High speed signals from board A to board B via connectors? This opens a whole new can of worms.

 

[dknguyen]

I will start with the placement question. Placement is not real critical but it is always best to place the shunt termination as close to the termination point as possible. For your first question; in general practice I have always laid the pads for series and RC shunt terminations and ended up either using a 0 ohm for series with RC or some series R and DNI for the shunt. Only in case with really long ugly lines have I needed both. Adding 0805 pads is cheap, easy, and uses little space. Simpler to plan ahead, and stuff a zero ohm or make a DNI than re-fab the board.

Yeah, this is a really expensive project so I certainly don't want things like that happening when it could have been averted by allowing placeholders for termination components on the board. The one problem I see is that having 3 component placeholders for ~100 I/O and clock pins coming out of the B2B connectors might cause routing issues as well as reliability issues (in the sense that if something went wrong like a bad solder job somewhere it'd be hard to hunt down). If it works though, each board would cost around the same what you could buy them for and it'd be exactly what I want (though I found one that is half the price but obviously it has a serious weakness in it's clocking scheme).

If it doesn't work though :S. I'm somewhat banking on the flexibility of FPGAs allowing me to work around little problems by just not using messed up pins. As long as I don't make a mistake routing the configuration, power or clock circuits I will still have a useful module. Mixed up, bridged, or cross IO pins won't really matter since they all run to a generic B2B connector for a baseboard and worse comes to worse I just won't use those miswired pins. I'm trying to decide whther I should add some SRAM. I've never wired it before but as long as it doesn't interfere with the power, config, or clock circuits for the FPGA I can just not use the SRAM if it's miswired.

Are you saying that you plan to run High speed signals from board A to board B via connectors? This opens a whole new can of worms.

Well the boards are all going to be identical so the same pin of each FPGA will be connected to that same pin on every other FPGA, as well as the baseboard. The speeds are going to be fairly slow (25-50MHz tops, probably more like 25MHz). The one exception might be if I mounted it to a NTSC/PAL digitizer baseboard for video overlay which would be the fastest I would ever go. I'm basically wanting to use this as a more beefed up microcontroller (an embedded microcontroller with parallel hardware resources to take care of the nasty things like floating point, digital filters). Ultimately I'd like to use these for video overlay if I can ever figure out how to do that in VHDL, but everything below that is pretty run-of-the-mill. At this point I think I would desparately try to keep all video signals going to one and only one FPGA module instead of spreading the processing among multiple modules because of the high speed signalling issues. But that's pretty far into the future.

 

[Mikebits]

The one problem I see is that having 3 component placeholders for ~100 I/O and clock pins coming out of the B2B connectors might cause routing issues as well as reliability issues (in the sense

Now remember, not all lines are critical, only ones that edges causes a flop to transition. So standard data line are not such a big deal. Terminating 100 I/O lines is crazy. Decide in advance what your critical line are and design accordingly.

Now sending signals from board to board is scary to me, normally when this happens line drivers and receivers are used. You will get impedance mismatches at each termination such as board A to connector A, Connector A to connector B, and connector B to termination. If you compound this with multiple terminations such as daisy chain as you have mentioned, you are looking at some nasty butt ugly signals that no RC shunt will fix.

I am assuming we are still talking high speed lines such as 25 - 50MHz.

 

[Mikebits]

You can have the greatest design in the world, but fail to follow layout rules, your design will be garbage. We had an RF engineer that would design a masterpiece schematic, but never followed through with layout and his boards would always have problems. Since he was such a good designer he was relieved of the layout duty and that job was given to another engineer.

So lesson here is, layout is a big part of design work. Sorry if that was preachy...

 

[dknguyen]

Yeh Layout takes way more time than anything else. I'm planning to go with a 12 layer board right now so hopefully routing will be easier and help relief RF problems (or just running it slow). I'm not sure how critical it is right now at the speeds I want to run it at (or rather the transition times).

THe reason I'm considering stacking is that if it doesn't work...well...I just don't stack them. The only difference in that case would be that the top-side B2B connector would be unused which introduces about...what? a 5mm stub at the end of the transmission line after the trace that runs to the FPGA pin? I *don't think* that would cause much difference.

How nice it would be to just go to an impedance controlled board.

Oh, BTW, is there "a minimum speed" for FPGAs? I don't see anything that points either way though that might be because FPGAs are normally implemented to run as fast as possible. Or are they a fully static design like (what seems to be) most MCUs? I think FPGAs can run at very slow speeds, but I'm under the impression embedded MCUs have minimum clock requirements though I have no idea why.

(Let's ignore DCM, PLL, and DLL minimum input frequency requirements for now. I'm using my own external PLL which goes down to about...24kHz...but will probably never run it at that speed.

 

[Mikebits]

I have used programmable logic as slow as 1 PPS. Slow should never be a problem.

 

[dknguyen]

Excellent. I might just forego the external RAM. Such a pain to figure out what all the strobes, select, and decoding lines are. Bleh. It's not like I'm ever going to use the embedded MCU for major processing, not with parallel hardware available. I just mainly need it for decision branching and running serial periphreals because I'm too lazy to make my own stand-alone IP cores and all the ones available are made to run with an embedded MCU.

Stacking...we shall see...but really the issue is more termination than stacking. If stacking doesn't work I just don't stack.