Posted by Michael Posner on March 15th, 2013
UFC: Cables Vs. PCB Traces
With the new HAPS-70 all cable based interconnect architecture we often get asked about overall raw performance of the cables vs. PCB traces. Below is the data on the raw cable and new HapsTrak 3 connector performance. This in itself shows that the cable and connector architecture are cable of running at speeds well in excess of what is typically seen on an FPGA-based prototype.
Of course designers have been using PCB traces for years and like my late grandfather they are very stubborn. Unless you provide them the raw data which proves the assertion they never change their minds on what they perceive as the best solution. This blog is designed to provide the data to let a designer make up their own mind on the effect of a cable vs. PCB direct trace based interconnect architecture. Warning, it gets pretty technical from here on…….
There are two influences of FPGA-Based Prototyping performance that must be discussed separately. One is signal quality and data rate, which affects the transmission speed of signals over a High Speed Time Domain-Multiplexed link. The other is latency, which affects globally synchronous performance.
First signal quality:
All PCB traces suffer from crosstalk. Crosstalk can be reduced by routing all traces as micro-strips with lots of space around each trace, and surrounding GND planes on both sides of a signal (A GND-sig-GND stack). The other problem with PCB traces is attenuation. It can be countered by using wider traces, which takes more room and also imposes even larger spacing between traces to keep the crosstalk down. The sheer number of signals in an FPGA packages prevents a designer from using such technologies for the bulk of the signal routing. To reduce the number of planes in the PCB, it’s possible to use GND-sig-sig-GND stacks, which will introduce crosstalk between signals on adjacent layers. This is unavoidable if you want to route more than a hundred or so signals between FPGAs on a reasonable PCB.
The cables Synopsys uses are high performance ribbon coax cables. They have excellent performance data (see above), with superior characteristics in terms of crosstalk and signal velocity (length of signal path versus latency). There is no question about this, the raw data cannot be argued. Our HapsTrak 3 connectors add some impedance discontinuities and very little crosstalk. So wide on-board micro-strip traces without connectors could have performance on par with the cable, but without the flexibility. (Fixed direct connects can’t be tailored to your design partition). Also, there would likely be much fewer such high performance traces than cable traces, due to PCB constraints mentioned earlier.
Even so, measurements and simulations show that our connector-cable combo will in outperform the FPGA anyway, so direct PCB routes won’t pay off in significantly higher data rates, because the FPGA sets a hard upper limit.
Our 25 and 50 cm cables have latencies of around 1400ps and 2500ps. Add this to the trace lengths on the FPGA Modules, which are around 1500ps (between FPGA and connector). This gives about 4-5ns of trace delay between FPGAs. In comparison, you could perhaps make at least some direct PCB traces that are 2ns long (optimistically), shaving 3ns off the trace length.
But the total clock cycle time is not only constrained by the trace length:
- Clock skew and uncertainty is ~1ns.
Clock-to-out of the FPGA is at least 2.5ns.
Setup time is ~1ns.
- So the absolute minimum clock cycle time is:
- 5+1+2.5+1 ns = 9.5 using cables (realistically)
2+1+2.5+1 ns = 6.5ns using traces (optimistically).
- 5+1+2.5+1 ns = 9.5 using cables (realistically)
The difference could still seem significant at a first glance, but hold on, there’s more:
The calculation requires all FPGAs have flip flops on the edges, which implies that all partitioning cuts are made between pairs of flip flops in the design (unrealistic). It also assumes that signal multiplexing isn’t needed. Say that signal multiplexing isn’t needed, but add an optimistic 10 ns of worst-case user logic path to the equations, and you get 19.5 for cables vs. 16.5 for PCB traces. The difference isn’t that big anymore. And for less optimistic user logic timing, the difference will be even smaller.
If you use globally synchronous multiplexing of signals (traditional signal multiplexing), the additional latency will affect the mux’ing frequency and will eventually kill performance. But if instead use the Synopsys HAPS HSTDM, the mux’ing frequency will be decided by the max data rate, where the cable excels, and you will get much more capacity out of the interconnect at a given system frequency.
Proof, there is no “order of magnitude difference” in performance, signal quality or latency between cables and PCB traces. PCB Traces as we know are good and cables provide the higher flexibility that FPGA-based prototypes need in order to be customized to specific design requirements.
UFC Cables Vs. PCB Traces Winner: Synopsys High Performance Coax Cables
So, anyone like to challenge this data?