10-05-2018 02:32 AM
10-05-2018 06:34 AM
How fast is this interface?
Do you have timing constraints on the tx clock and output data?
If you are not propagating the tx clock using an ODDR, how are you outputting this clock?
Why do you think the ODDR adds excess jitter?
Have you looked at signal integrity at the receiving side of your ribbon cable? Many ribbon cables just aren't up to high speed data transfer.
Have you looked at clock to data timing on the receiving side?
10-05-2018 07:16 AM - edited 10-05-2018 08:18 AM
125 MHz, 40 ps jitter TXCLK
yes I have t_setup and t_hold on receiver side but I don't believe in their importance. In fact the ribbon cable for data and SMA for clk are different.
ODDR (logic resouce = more jitter) is for source syncronous design, this became synchonous when i match the right output delay.
In the previous design I connect tx clock to that MMCM with jitter cleaner.
Now I am trying with set_output_delay between output clock of MMCM and tx data bus and fixing the location of MMCM (LOC). I will write results
10-07-2018 01:53 PM
I'm not quite sure what you are trying to accomplish here...
Are you trying to have the FPGA generate a clock with <40ps of jitter? RMS jitter or cycle/cycle jitter.
If you want <40ps cycle/cycle jitter - give up. I am pretty sure there is no way to get a jitter this low. While the MMCM attenuates "large" jitter to something smaller, it has a jitter floor which (I am pretty sure) is WAY above 40ps. If it is 40ps RMS, this isn't actually all that hard to do - as long as you don't do things that are "really bad" for jitter, the output will have less than that.
Jitter inside the FPGA is generated by the clock traveling through the digital logic (and some from the MMCM itself), most of which is coupled through the power supplies (so the ripple on the power supplies matter too). The clock from the IBUF to the MMCM is mostly irrelevant (since the MMCM is a filter), so the rest comes from the route from the MMCM to the OBUF.
Routing the clock from the MMCM to the OBUF can be done different ways - each has different characteristics:
- directly (i.e. no clock buffer) means local routing
- this can change from route to route and since the clock will be in the general routing fabric it will potentially pick up lots of jitter
- use a clock buffer (type to be discussed later) to go directly to an OBUF
- the clock will "jump off" the dedicated clock network to be routed to the OBUF (there is no connection from the clock networks to the OBUF)
- this makes the last part of the clock "locally routed" with the same problems as the other locally routed clock
- through a clock buffer to the ODDR/OSERDES and from there to the OBUF
- this allows the clock to stay on the clock tree all the way to the IOB, where the ODDR/OSERDES and OBUF are located
- since there are no locally routed segments this will be consistent from run to run and will likely have the lowest jitter
So assuming we are going to use an ODDR/OSERDES, which clock buffer is best ...
Routing this clock to a global clock resource is about the worst thing you can do for jitter - the clock traverses the FPGA to the center of the die, along the global clock spine and then back to the edge for the IOB, picking up lots of jitter along the way.
Routing the clock to the BUFH in the same region as the MMCM is almost as bad - the clock still goes to the center of the die and back (but skips the global clock spine). The jitter will be better, but not particularly good.
The best clock buffer to use is the BUFIO. You can use the "High Performance Clock (HPC)" path from the MMCM to the BUFIO/BUFR and use the BUFIO to clock the ODDR/OSERDES. The HPC is a dedicated path designed to be low jitter (high performance!) from the first four outputs of the MMCM to the BUFIO/BUFR. The BUFIO only clocks the IDDR/ISERDES/ODDR/OSERDES and travels only in the IOB column (again, minimal jitter). Of course the BUFIO cannot clock fabric logic, so if you need the clock internally, you also need to use a BUFR; the output if the BUFR, though, is limited to only the clock region of the BUFR.
So if you can live with the limitation that only one clock region is available for your clock, the BUFIO/BUFR combination and the ODDR/OSERDES is probably your best bet.
By the way, the clocking wizard will tell you how much output jitter you can expect for a particular configuration of the MMCM - even if you are going to hand instantiate the MMCM, I recommend you run though the clock wizard (and discard the outputs) so that you can get it to report the jitter of the MMCM outputs.
10-12-2018 05:44 AM
thanks for this marvelous reply. To reduce output jitter the only one solution consists in the routing of MMCM's output clock to BUFIO an then to ODDR in the I/O Tile of the same region.
1) Can I connect a BUFG to the MMCM clock in? The feedback in MMCM should reduce the buffer of the logic before MMCM.
I have two different cables in which flows data and clock, one is coaxial (out-clk), the other is a ribbon cable (out-data).
The receiver must sample correctly the data but the delay insertion (buffers, routing, difference in cable length) is hard to calculate and it probably depends on the implementation. The result is that the receiver samples everytime wrong data and I am sure that is not related to the jitter noise.
2) Have you got a solution to reach the correct alignment?
Thanks a lot,