Synchronisierung von FPGAs

Hello newsreaders,

For a while I have been confronted with the following task which I find quite challenging but unfortuantely didn't manage to solve it, yet. What I want to do is to use 2-4 FPGAs (Xilinx Virtex 2 Pro) together on one printed circuit board (PCB). They are used to process a large amount of incoming serial data (data rates of several GHz's). My idea is to handle that data parallel by the 2-4 FPGAs. But now there arises the problem how to adequately split the data and how to synchronize the FPGAs among one another, in particular? Is it possible or first of all a realistic idea to synchronize multiple FPGAs in the GHz range? How can this be done without much protocoll overhead? I would like to do it without applying an extra transfer protocoll among the FPGAs just for that purpose! Up to this date I didn't find a proper solution, yet. Maybe someone can give me a hint? Any ideas how to solve that problem?

Regards, Leroy Tanner

Reply to
Leroy Tanner
Loading thread data ...

Hi Leroy,

Don't know about FPGAs in the GHz range but if you mean sync down to the nsec maybe I can share some thoughts.

First you have to fully understand how clocks are distributed inside your FPGA. How much delay there is inside, how it is buffered and so on. The data path is another matter. With very critical timing you usually cannot have the FPGA laid out by some automatic router. You need to know exactly which path the data takes. Even the routing to a second bus layer and back to the first can introduce so much error that the whole scheme collapses, unless it is done in exactly the same pattern on all the other data paths that must stay in sync with your first path.

Then you have to make sure that the clock that is fed to the FPGAs from outside is pristine and very well terminated. No overshoots, nothing. Strict adherence to transmission line theory when laying out the traces, no sharp bends, clean square waves.

Also, you'd have to make sure that individual FPGA do not differ from lot to lot or at least find out by how much. If this goes into production it will be inevitable that boards carry FPGAs of same type but with different manufacturing date codes. That can throw you a real curve.

Keep the supplies clean. Easier said than done, for eample if you operate a large RAM bank on the same board. You need to make the current consumption of the board very even. This will sometimes require "dummy cycles" and other tricks since even a large amount of caps can't take the whole brunt.

With respect to clock synchronizing when you encounter a known and well defined need for a shift of a few hundred psec this can also be done. However, that will be a small analog portion and, in complicated cases, something that controls it such as a DSP or a uC.

I have debugged a lot of this stuff on the board level and often designed synchronizing circuitry. We found that the majority of timing issues arose on the board level, be that noise, not so clean clocks, unwanted phase modulation of the clock, other kinds of jitter. If this happens you need an RF expert to give you a hand or at least review the board.

BTW, this is a German newsgroup. However, since you guys are now one common Europe I guess that languages don't matter all that much anymore. Any EEs worth their salt will understand English anyways.

Regards, Joerg

formatting link

Reply to
Joerg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.