cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
317 Views
Registered: ‎02-11-2019

The magic serdesstrobe signal

If you post-route simulate a design in ISE, and grab the serdesstrobe at a bufpll source, then grab it at the other end, after it presumably had to route to an oserdes2,  you will find that both signals in the simulated ouptut are the same. There is no routing delay.  This can be a problem, becuase the IOCLK signal which is used with it, does have a routing delay.

In the FPGA editor, the serrdesstrobe is shown to have a 1.8ns routing delay, while the IOCLK has 1.5ns. 

But in ISE post route simulation, the signal is "magic".  Or hidden.  Not sure which.

Even worse, there's a cryptic comment in UG382 page 31, stating that "The SERDESSTROBE resolves the BUFG routing delays"

This is NOT a good thing, unless you aren't using a DCM_CLKGEN to alter the system speed.  If you need that (for instance, as a DIMM controller that reads the dimm module speed), the SERDESSTROBE will phase, and your output can skip a bit relative to other system timing.   I'm not even sure if the signal is reliable, since it can phase in post route sim, so that the setup and hold are clearly illegal relative to the oserdes2.  Also, the datasheet doesnt' show the setup and hold, and diagrams in the xilinx documentation show a dotted line for the serdesstrobes, like they weren't really routed anywhere.

Does anyone have documenation on how the SERDESSTROBE actually works?  Is the timing of it "resolved" during compile, based on the clock rate?  Can a constraint be used to tell the signal to adjust from the clock, not from the compile?

How can I see what controls the timing of this?  Is th epost route simulation list of constants for the device,  representative of a compiled alignment?  The docs seem to imply that the pulse is adjusted by the bufpll at run time.  Doesn't seem like it is.

 

0 Kudos