|
|
|
|
|
Xilinx User Community Forums :
General Discussion :
General Technical Discussion :
PCB signal integrety of "T"ed clock for feedback and deskew
|
|
|
|
|
|
|
PCB signal integrety of "T"ed clock for feedback and deskew
|
|
bryan.althouse
Regular Visitor
Posts: 23
Registered: 12-08-2008
Message 1 of 8
Viewed 202 times
|
|
|
I am designing my own board that is roughly based on the ML507. This design includes a synchronous ZBT SRAM chip, just like the ML507. The ML507's FPGA (Virtex5) uses external clock feedback to deskew so that the FPGA and SRAM are clocked with the same phase. I have checked the ML507 gerbers, and it is clear that the SRAM clock trace breaks out of the FPGA BGA, travels half way to the SRAM where it "T"s with one leg continuing onto the SRAM, and the other looping back to a FPGA global clock input. I believe the trace lengths are such that FPGA clock out to feedback input is the same as FPGA clock out to SRAM input. I'm guessing that this is on the order of 2". I have great concern about the signal integrity of this T'ed clock. There are no external termination resistors, and the FPGA's clock output pin is a LVCMOS33, not a DCI standard. Clearly, Xilinx has designed this under the assumption that the trace is small enough to be treated as a lump element rather than a transmission line. I would like to make this determination for my self, but I am finding it difficult to estimate what the rise time of this clock will be. I can't find this information in any of the Xilinx documents. This clock output is constrained with SLEW = FAST and DRIVE = 12. Assuming a trace length of 2", a rough calculation shows that a rise time of less than 2.16 ns will result in transmission line behavior. The clock frequency is 125 Mhz, which is only an 8 second period. Without knowing any details of the IOB driver itself, I think it is quite likely that the rise time could be close to or less than this lumped vs. transmission line threshold. I have thought of 2 ways to eliminate this concern. - Use a second FPGA output for feedback purposes, use 50 ohm controlled impedance traces, and use DCI outputs for series termination. I think this is not done because there could be different capacitive loads on the two clock nets which would result phase error in the deskew. Is this true?
- Use controlled impedance and parallel termination. Route 50 ohm controlled impedance from the FPGA output. At the T, change to 100 ohm controlled impedance on both legs. At the trace ends, place 100 ohm parallel resistors.
I encourage any and all comments. Here is another question about the ML507. Does anyone know why Xilinx used series 47 ohm resistors on the SRAM's data bus, but no series resistors to the linear BPI flash which shares a subset of the same data bus? Are there any guidelines for the routing and layout of a FPGA with SRAM and FLASH?
Thanks!
Bryan |
|
|
|
11-06-2009 10:57 AM
|
|
|
|
|
|
Re: PCB signal integrety of "T"ed clock for feedback and deskew
|
|
drjohnsmith
Expert Contributor
Posts: 270
Registered: 07-09-2009
Message 2 of 8
Viewed 183 times
|
|
|
Hi well I'd like to hear from the bord designer on that . Having done similar boards for companies, one could be cynical, in that it worked, so it got left ! But, are we certain it's running at 125 MHz in the referance design, and it's FAST , 12ma 3v3 ? It could be that the designer has 'wait states' in the access timing, time to wait for the ringing to settle ? It's the edge speed that I'd be interested in. 5cm is certainly the sort of area I'd expect to be worrying about 100 MHz plus signals with a fast edge. A sine wave would not be a problme ! maybe that is what the designer is assuming ! I hope the control signals are better terminated.
|
|
|
|
11-08-2009 12:20 PM
|
|
|
|
|
|
Re: PCB signal integrety of "T"ed clock for feedback and deskew
|
|
williambhunter
Visitor
Posts: 18
Registered: 10-25-2009
Message 3 of 8
Viewed 178 times
|
|
|
Unless I am missing something ( and that is certainly possible), this seams a bit hackish. They obviously have gotten away with it since the boards seem to work. I haven't done any calculations, but that distance seams real short to be having problems at that frequency. L > "rise time"/ (2 x (prop rate)), FR4 has a prop rate (at 50 ohms) of 150 ps/inch, 2" x (2 x (150 ps/inch)) > tr, tr < 0.6 ns So you would not need to worry about the termination unless the rise time was less than .6 ns, which is fairly safe. Check my calculations before using, I've been concentraiting on FPGA design lately, so it has been a while since I used these rules. If you wanted to be conservative, the better way of handling this is to have a 1 to 2 clock driver, and drive one output back to the FPGA and the other to the SRAM. You still have to play the game of making the traces equal length.
|
|
|
|
11-08-2009 06:50 PM
|
|
|
|
|
|
Re: PCB signal integrity of "T"De clock for feedback and deseed
|
|
bryan.althouse
Regular Visitor
Posts: 23
Registered: 12-08-2008
Message 4 of 8
Viewed 168 times
|
|
|
The equation I like to use is: L= Tr/D (1) Where L is the electrical length (in inches), Tr is the (10-90%) rise time in ps, and D is FR4 Delay in ps/in. I was taught that you should consider a trace as transmission line if its length is greater than 1/6th of the electrical length of the signal. Conversely, in order to treat the trace as a lump element we must satisfy: Lt < L/6 (2) Where Lt is the length of the trace. Combining equations (1) and (2), we get: 6Lt < Tr/D (3) Solving (3) for Tr, we get: Tr > 6*Lt*D This inequality must be satisfied if we are to ignore transmission line effects. In this problem, I'm not sure what the rise time is, that is why I have solved the equation for it. I think the trace length is close to 2", and I've been using a D of 180ps/in. Tr > 6*2*180 = 2.16ns Since 2.16ns is a large portion of the 8ns period of a 125 Mhz clock, I come to the (somewhat lame) conclusion that is dangerous to ignore transmission line effects. It would be much better to know the actual rise time. Maybe you need to use IBIS modes for that? Does anyone know of a free or cheap tool to do IBIS modeling? I also thought of the clock driver/buffer solution. For that matter, you could simply use two FPGA outputs from the same +/- pair to ensure the same routing delay. I suspect that Xilinx has not taken this approach due to the potential of different capacitive loading to introduce phase error in the deskew. Both approaches are vulnerable in this respect. To answer drjohnsmith, I am positive that the ISE design is constrained with FAST, 12mA, and LCMOS33. Also, it seems to me that the clock's signal integrity is of utmost importance. Without a clean clock, the control signals are useless. I appreciate your comments! Bryan
|
|
|
|
11-09-2009 07:24 AM
|
|
|
|
|
|
Re: PCB signal integrity of "T"De clock for feedback and deseed
|
|
drjohnsmith
Expert Contributor
Posts: 270
Registered: 07-09-2009
Message 5 of 8
Viewed 164 times
|
|
|
Hi so you have an fpga driving an Sram, and some flash ? any thing else on the bus ? Is that correct ? can you let us know what parts and speed grade, and I'll have a think on things.
|
|
|
|
11-09-2009 09:45 AM
|
|
|
|
|
|
|
|
Re: PCB signal integrity of "T"De clock for feedback and deseed
|
|
drjohnsmith
Expert Contributor
Posts: 270
Registered: 07-09-2009
Message 7 of 8
Viewed 147 times
|
|
|
Hi The one clock goes to the Flash and the SRAM ? I'm amazed as the SRAM can run with a 200 MHz clock, whilst the flash can only run with a 50 odd MHz clock. So I guess you run the SRAM at 50 odd MHz as well then ? Have I that correct ? Seems strange to me. Is the flash being used in asynchronous mode ? so the clock is ignored ?
|
|
|
|
11-10-2009 01:41 PM
|
|
|
|
|
|
Re: PCB signal integrity of "T"De clock for feedback and deseed
|
|
bryan.althouse
Regular Visitor
Posts: 23
Registered: 12-08-2008
Message 8 of 8
Viewed 131 times
|
|
|
You're right, I wasn't clear on this. The Flash gets its own, separate, clock. I'm not sure of the rate. The SRAM clock is the one I'm worried about. It is 125 Mhz and it has the feedback for deskew. The Flash and SRAM share the data and address bus.
|
|
|
|
11-11-2009 05:58 AM
|
|
|
|
|
|
|
|
|
|
