Bus or IOs skew management issue

[Altera_Forum]

Hello dears: 

 As a example, a internal resgister fans out 22 signals to 22 pins. Can I ensure these 22 path getting fix delay? If can, how to get it? The jitter requirement is below 1ns, as smaller as better.  Thanks

[Altera_Forum]

If possible, CPLD is better for me, if not, FPGA is also OK.

[Altera_Forum]

I'm not very expert on this topic, but I think you should use 

set_max_skew -to [get_ports bus_out*] 1 where bus_out* is your 22-signal array Then use report_max_skew to analyse the results for the constrained signals.

[Altera_Forum]

Replicate the output register 22 times(either manually or with assignment) so the I/O output register can be used and it will be fed by a global clock tree. I wrote the following document that might help(it's a different topic, but somewhat related) 

http://www.alterawiki.com/wiki/register_duplication_for_timing_closure That will give you the least amount of skew, and much better than trying to get the router to add/subtract delays to get minimally skew to 22 locations.

[Altera_Forum]

Hello Cris72&Rysc: 

 Thanks for your help!  In fact, I'd like the 22 paths have fix propagation time from inside FPGA to another deivce. It's will be ok whether there are skew on these 22 paths or not.  But, each path's jitter must be very small, blow 1ns would be ok for my case.  I think there is would be issue since there are jitters among diff IOEs. I can't find any information about this jitter in Altera's datasheet.  For one path, there are 2 section, one is inside FPGA, another is outside the FPGA (which is pcb trace - fix prop time). What't i want is how to fix the propagation time inside FPGA include the IOE propagating time?  Thanks

[Altera_Forum]

What do you mean by jitter? The PLL(if used) will add jitter. The clock tree will have some(along with internal noise) but that should be very tiny. You'll also have things like rise/fall variation and PVT variation, which aren't really jitter but might be an issue. There is no real jitter guarantee that I know of, but that's because most people don't care. They have synchronous time budgets they need to meet, and if the data jitters in that budget, it's fine. So most timing analysis is max/min(it's much more complicated than that, but that's the basic goal).

[Altera_Forum]

Hello Rysc: 

 My case is of spercial application.  I will use FPGA to generate a signal which feeds TDC chips. Then if there are hundreds of ps timing variation would be an issue for my case. That's why i need the route inside FPGA of this signal to be fixed like PCB trace.  I hope that i have explained my question clearly.  Thanks

[Altera_Forum]

Got it, but I don't know the intricacies(such as if the delays vary over PVT, does it matter, or is it fine if they all vary together)? Anyway, if you're driving out from a flip-flop, the best method is to use the output flip-flops in the I/O cell. General routing delays in the FPGA will be more subject to variaion, where the global clock tree is designed for low-skew(and jitter should be low).

[Altera_Forum]

--- Quote Start ---  Got it, but I don't know the intricacies(such as if the delays vary over PVT, does it matter, or is it fine if they all vary together)? Anyway, if you're driving out from a flip-flop, the best method is to use the output flip-flops in the I/O cell. General routing delays in the FPGA will be more subject to variaion, where the global clock tree is designed for low-skew(and jitter should be low).  --- Quote End ---     Thanks for your reply.