Some time ago there was discussion about phase noise (jitter) introduced by
XILINX FPGA DLL's
Here is an other question:
What phase noise (jitter) is introduced by a regular logic element of XILINX
FPGA (e.g. SPARTAN2)?
What is the timing uncertainty introduced by XILINX CLB trigger?
I prefer to look at this as "what is the jitter noise floor" in a CMOS FPGA?
Getting in, and getting out of the FPGA is the biggest problem, followed by the
internal distribution of the clock signals.
This is something we have carefully characterized, as we are the 'FPGA Lab'
responsible for the verification of the design.
To get in, get onto a BUFG (global clock resource) and then get out (by using
the DDR clock forwarding FF's) is about 35 to 55 ps P-P (nothing else
If you have an another BUFG operating, the jitter goes up to 55 ps to 65 ps P-P.
If you then have 10% of all nodes in a 2V3000 all toggle at the same time on the
same clock domain (BUFG), the jitter measured is ~ 150 ps P-P on an
ansynchronous clock domain.
The primary means of jitter is the coupling through the ground, which affects
the slicing level of all of the logic.
Use of LVDS input buffers, and output buffers helps for the external jitter
contributors, but does nothing for the internal contributors.
150 ps P-P of jitter in a design was ignored up until recently. With DDR
(double data rate) logic designs, and clock periods of 4 ns in some designs, the
half clock period is 2 ns, and 150 ps becomes a significant part of the timing
Thank you for valuable information.
So, if I want to reduce the jitter on XILINX output to something like 10
ps - I have to use some external triggers, clocked by extremely pure
And here the next question appears:
who manufactures low noise triggers?
Is that true, that regular ALS logic flip-flops are introducing 15 - 20 ps
I guess, of course, there are some better triggers, - at least for expensive
What kind of triggers?
"Austin Lesea" <austin...@xilinx.com> wrote in message
If you treat the registers as analog elements - clean planes, nice clearance on
the traces to reduce crosstalk - you should get the clean edges you desire. But
they'll never be more clean than the clock source that drives the registers -
that *must* be clean.
>I prefer to look at this as "what is the jitter noise floor" in a CMOS FPGA?
>Getting in, and getting out of the FPGA is the biggest problem,
> followed by the internal distribution of the clock signals.
>This is something we have carefully characterized, as we are the
>'FPGA Lab' responsible for the verification of the design.
>To get in, get onto a BUFG (global clock resource) and then get
>out (by using the DDR clock forwarding FF's) is about 35 to 55 ps
>P-P (nothing else happening).
>If you have an another BUFG operating, the jitter goes up to 55 ps
>to 65 ps P-P.
This reminds me of a story about the TTL 74S124 (I think that is the
number) dual oscillator. I was told that it was almost impossible
to use both, as they will phase lock if at all possible.
As I remember, phase locked oscillations were first discovered
by Huygens putting multiple pendulum clocks on the same wall.
You wouldn't expect the coupling to be large, but apparently enough.
OK, web search and I find:
So, might one expect problems with multiple, non-synchronous oscillator
inputs to the same FPGA?
"Alex Sherstuk" <sher...@iname.com> wrote in message news:<%uSO7.69056$RI2.38425920@news2>...
Funny, and neat and true story about the clocks.
When I was hired at Xilinx, one of the first experiments I did was to make many ring
oscillators. I went on to prove that they would phase lock, if and only if, they shared a
well for some of the pmos transistors, or if they had adjacent lines (capacitive coupling)
of a certain length.
If they were built is CLB's that did not share any wells, or used interconnect that was not
actually physically adjacent, then they did not couple.
The rings tend to oscillate +/- 10% due to variations in the die, they are not easy to get
This led to a number of design techniques which are used to minimize coupling, as coupling
of any kind adds cross talk induced delay variations (a.k.a JITTER), which is a bad thing to
Yes, currently there are such things as "single" D-triggers 74LVC1G79,
74LVC1G80 (from TI, Toshiba, and others).
Their usage would minimize cross-talk as a source of jitter.
But what about thermal and other radiotechnical noises in trigger circuits?
What is internal noise of a modern trigger?
P.S. Of course, I am intending to use clean enough master clock source -
something like 5ps jitter.
"John_H" <johnha...@mail.com> wrote in message
I've been meaning to measure the Virtex-II clock distribution and
DDR output register phase noise directly on an HP 3048A under various
conditions, but haven't been able to locate a suitable FPGA test board
that also has at least 16, preferably 32, pairs of LVDS outputs to
measure the data line skew.
The most promising one I'd found was the Insight Microblaze board,
whose color glossy mentions 16 bits of LVDS out, but am awaiting detail
from Insight on the LVDS and clock connectors & PCB routing thereof.
- SMA connector pairs ( or a suitable balanced connector ) to at least
one LVDS global clock input & output
- 16-32 bits of controlled impedance, balanced LVDS output pair runs,
sourced from the same bank ( or at least the same side of the chip ),
routed to a suitable connector
Contact your FAE.
The total clock skew in a 2V6000 is +/- 60 ps to any IOB, anywhere (using DDR
The flight time of the package is +/- 40 ps. If you need to equalize the flight
times for the package by trace lengths on the pcb, we offer a map of the flight
times per pin, in 5 mm length increments. Compensating for the clock tree is not
The FAE has access to the timing budgets, SPI POS 4 IP core literature, our own
LVDS serdes solutions cores, and all preliminary timing information.
The sample window, when using the variable phase shift to place the clock in the
center of the data is being characterized fully right now, and will be available
shortly. The number includes the clock tree skew, and jitter from the DCM, as
well as the sample window of the input FF's, and a system jitter budget for other
activity, but needs a little more work yet before we publish it (have to make
such small measurements in a tester environment on thousands of parts!).
The next data sheet will contain such information for clock and data forwarding
Xilinx rep/FAE : XC2V40 board in San Jose labs
nothing available for customer use
Xilinx rep/FAE : nothing available for customer use
Avnet Xilinx FAE : no such animal
Insight Xilinx FAE : awaiting technical detail
Could you at least confirm or deny the existence, if not
the customer availability, of the "16 bit LVDS demo board"
mentioned in the VHDL source files for XAPP-265 ?
snippet from top16.vhd:
-- Top level design for 16 bit Xilinx LVDS demo board version 1
Brian Davis wrote:
> Austin Lesea wrote:
> > Contact your FAE.
> Been there. Done that.
Please email me at aus...@xilinx.com and tell me who your FAE is.
> March '01:
> Xilinx rep/FAE : XC2V40 board in San Jose labs
> nothing available for customer use
Yes. That was true.
> Oct/Nov. '01:
> Xilinx rep/FAE : nothing available for customer use
> Avnet Xilinx FAE : no such animal
> Insight Xilinx FAE : awaiting technical detail
Yes, that was true, too.
> Could you at least confirm or deny the existence, if not
> the customer availability, of the "16 bit LVDS demo board"
> mentioned in the VHDL source files for XAPP-265 ?
It exists now, and it is being "finished." Marketing Apps will get
really mad at me if I say anything more. And, with good reason, as they
have to bless the pcb, the documentation, and the rest before they go
live with it.
> snippet from top16.vhd:
> -- Top level design for 16 bit Xilinx LVDS demo board version 1
We recognize now that we did not have the all of the necessary
collateral pcb's ready like we did at the launch of Virtex for Virtex
There are at least 12 pcbs that can be built for any product release,
and we will do a better job in the future.
About a year ago we had to design an evaluation platform using
Virtex-E to source 624Mb/s 28-bit parallel data (2 14-bit buses) to
drive our high-speed dual DAC. This was a lot of grief and effort, and
had problems with skew on the data bus in spite of using a customised
Xilinx-supplied parallel LVDS macro.
One necessary feature to remove I/O and track/cable delays (since the
DAC had to be the clock master for jitter reasons) was that we took
the 312MHz clock out from the DAC as the DLL input clock, then sourced
a 312MHz clock from the Virtex (DDR clock synchronised to the data)
and looped it into the DAC and back out to the Virtex as the PLL
reference clock, so the DLL took out the delays.
Will this be possible on the Xilinx LVDS demo board, and when will the
board be available? I'm asking this because I know at least one
customer is using an Altera Mercury board (also not released yet?) to
source data, because there wasn't anything similar available from
Does the board use SMA connectors (so we could connect it directly)?
Is there any possiblility of a board with wider LVDS output (eg, 32
bit) being made available in the future?
Mixed Signal Division
Advanced Communications Group