FPGA delay generator

I'm debugging a short delay generator with much higher resolution *right now* so I have some sensitivity for your issues. The biggest problem you may have with FPGA implementation of a delay generator is the jitter spec. The ECL outputs are not something you will find on standard eval boards.

Expect to design your own board or have one designed for you to meet your specifications. The FPGA can do much of the hard work but interfacing to low-jitter ECL should involve some external registers times by a jitter-free clock to deliver the final ECL signals. ______

Currently I am designing very accurate delay generator, which will be based on FPGA . This delay generator should have similar technical requirements with DG535

The major Delay Generator requirements are

· 2 ns (1ns is desired, but 2ns will be also ok) time resolution on delayed channel (it means that time differences between any delayed channels can be set in 2 ns steps) · maximal 50 ps - 60ps (RMS) jitter on each output. · 14 delayed ECL channels · Two high speed (PECL) inputs (500 Mz ECL clock signal and ECL trigger) · Configurable via standard bus (Ethernet/USB/Serial bus) · Internal trigger with variable rate (DDS) · Internal clock oscillator · Clock master or slave

Does anybody know for commercial available FPGA boards (preferred ISA (PC104) or PCI (PC104 plus) standards) that can be suitable for my requirements? Sutiable FPGA for my design is V5 or Stratix 2 GX.

Thank you and Regrads, Amir

You might want to look at our Hollybush1 product. We have a LVDS oscillator module position, and module, that is capable of generating clocks up to 700 Mhz into the Spartan-3 on that board. The Spartan-3 on than board will realistically operate at input clock of 250-270 MHz (single rate) on the I/O and 500 Mhz DDR style with careful design. Maybe a bit faster if you are lucky. That will give at least 2nS resolution and more may be possible with phased clocks or using clock enables if the clock enable logic can be made to go fast enough.

We will also have a V4 FX12 module for this board in design shortly that will be capable of higher clock rates and hence resolution. Hollybush1 can take an add on module with up to something like 110 I/O connecting to the Spartan-3 available.

Longer term we are looking at a PC104 equivalent as a product. We are already doing customer specific PC104 derivatives of Hollybush1 so when we get a free engineering slot it will get done and released as a Enterpoint product.

John Adair Enterpoint Ltd. - Home of Hollybush1. The PC104+ Spartan-3 Development Board.

Currently I am designing very accurate delay generator, which will be based on FPGA . This delay generator should have similar technical requirements with DG535

The major Delay Generator requirements are

· 2 ns (1ns is desired, but 2ns will be also ok) time resolution on delayed channel (it means that time differences between any delayed channels can be set in 2 ns steps) · maximal 50 ps - 60ps (RMS) jitter on each output. · 14 delayed ECL channels · Two high speed (PECL) inputs (500 Mz ECL clock signal and ECL trigger) · Configurable via standard bus (Ethernet/USB/Serial bus) · Internal trigger with variable rate (DDS) · Internal clock oscillator · Clock master or slave

Does anybody know for commercial available FPGA boards (preferred ISA (PC104) or PCI (PC104 plus) standards) that can be suitable for my requirements? Sutiable FPGA for my design is V5 or Stratix 2 GX.

Thank you and Regrads, Amir

amko schrieb:

How are you trying to build the delay generator? I see immediately how you can get a resolution of 80ps in a Virtex-4, but I fail to see you can have a low input to output jitter in a clocked design. If you sample the input signal with a GHz clock and use that to generate that clock to generate a delayed ouput you are going to have

1ns jitter in your delay, don't you?

Unless you are you doing something fancy like this:

Kolja Sulimma

If you sample the input signal with a GHz clock and use that to generate that clock to generate a delayed ouput you are going to have

1ns jitter in your delay, don't you

Yes, it is true. But I woul like to implement oversampled method what means four times shifted 1GHz (500MHz) clock signal. then error will be

250 ps.

We will also have a V4 FX12 module for this board in design shortly that will be capable of higher clock rates and hence resolution. Hollybush1 can take an add on module with up to something like 110 I/O connecting to the Spartan-3 available

I see this board with Spartan 3 and I think that with this board are possiable problems with jitter. Do you have any jitter measurment on Spartan 3 I/O pins, that you arrived on connectors.

I don't understand where the there are issues of jitter unless you use a DCM in which case you will have issues with all Xilinx FPGAs and to varying extent other vendors too. The point of our board is that you can have a high speed clock with low jitter and not necessarily using the DCM which does have jitter of some 10s of picoseconds. If you have a look at a ICS8442 and it's spec that is the chip we use for our LVDS clock module. Utimately your clock source is highly important if jitter is the issue. Other factors like power supply and decoupling will be possibly an issue.

What you may thinking about is either bond out flight time which does vary from pin to pin and more so on the Spartan-3 FG packages than the Flip-Chip packaged Virtex-4, Otherewise there may be an internal routing delay variation. The latter varies by usually small amounts but can be checked in tools. I believe flight time figures are available for the Spartan-3 but I don't have them with me at present.

On trace lengths we do have I/O pairs of signals on Hollybush1 generally tracked to have match lengths to about 0.1mm variation. this is principally for LVDS operation but also useful for applications like yours.

John Adair Enterpoint Ltd. - Home of Broaddown2. Spartan-3 board now with added V4.

Since that I should add still LVDS/ECL or LVDS/NIM converters/drivers what will results in additional jitter. Can you guarantee that jitter on your LVDS (high speed links) is less than 50ps. What about external trigger uncertainly domain. For this case I probably need very accurate input comparator. Spartan 3 DCM period Jitter is +/150ps.

John Adair schrieb:

Even with a zero jitter 1GHz clock the generated delay will jitter 1ns. The output will arrive anytime in a clock period, but the output will be generated a fixed time after a clock edge. The delay is the difference between input and output. It will have +-500ps error.

The 50ps jitter in the DG535 spec really means that the delay is fixed with 50ps accuracy, not only that the output time can be predicted with

50ps accuracy.

Kolja Sulimma

If you design an interface board, supply that interface with the very-low jitter clock for sampling *on that board* (to reduce trigger uncertainty) and to reregister the output from the development FPGA board to knock your jitter back down to the low levels you want. Where your ECL/LVDS interface occurs is up to you.

To reduce jitter that is caused by unsynchronized triiger and 1GHz clock, I think to use oversampling method. It means 1GHz clock will be shifted four or eight times and used for sampled input trigger. In this way jiiter (error) will be reduced for 4-8 times. Amir

Using a LVDS buffer can be one way to achieve a simple comparitor providing the level is within common mode range. Tie one end to the level you want. if you are going to use a very accurate comparitor general pickup of noise will introduce jitter and general development may not be what you want.

If you are that worried about jitter I certainly would not use a DCM in the clock structure. The LVDS wire pairs in boards don't have inherent jitter themselves only the chips at either end. The local noise at a FPGA that may introduce jitter will depend on your design and it's implementation within the FPGA amongst other factors and I doubt if anyone on this group could give you jitter guarantees as absolute numbers without a design implementation measurement. All you can do is start with the best clock you can and do everything else as best practise.

John Adair Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex4 Development Board.

The DG535 jitter is spec'd at 60 ps trigger-to-output and is often not that good in units I've measured. Accuracy is spec'd at +-1.5 ns, interesting given the speed of the output edges.

I know of a few ways to get low delay jitter:

SRS generates delay using counters clocked by a crystal oscillator at

80 MHz, followed by an analog ramp vernier delay. At every trigger, a front-end circuit measures the time offset from the trigger to the local clock, as an analog signal, and applies it to the vernier to correct for the 1-clock jitter. This adds a lot of insertion delay, requires precise ramp calibrations, and has s/h drift problems for longer delays.

Signal Recovery (formerly EG&G) uses the fiendishly clever interrupted-ramp technique, Pepper's patent. Imagine a simple trigger+analog-ramp+comparator delay generator, very accurate and jitter-free for short delays. Now interrupt, freeze, the ramp for N cycles of a crystal-controlled clock. That extends the delay by the freeze time and adds no jitter, even though the freeze clock is unrelated to the trigger. The only serious problem is analog drift of the ramp capacitor during the freeze interval, similar to the SRS drift issue.

Several companies make (or made) a number of DDGs based on starting an oscillator at trigger time, using a digital counter for coarse delay, and an analog vernier for fine delay. To maintain jitter performance for long delays, the timing oscillator must be phase-locked to a good crystal oscillator while maintaining the original phase offset. HP, copied by LeCroy and BNC, used a heterodyne PLL technique to accomplish this. My company uses a DSP system: after the triggered oscillator has started, we digitize its waveform using a flash ADC clocked by the crystal oscillator, figure out the phase difference, and close a digital servo loop onto the oscillator. Our technique is (he says modestly) clearly the best.

Both of these have jitters in the single digits of ps for delays into the tens of us, and longterm jitter limited only by the phase noise of the xo. Both use ecl for the critical signal path.

This one runs all the fast stuff through the fpga...

which adds a lot of jitter from crosstalk, ground bounce, and fpga delay variations as a function of tiny power supply changes and millikelvin temperature noise, still under 50 ps.

John