Visible to Intel only — GUID: bhc1417745086210
Ixiasoft
Visible to Intel only — GUID: bhc1417745086210
Ixiasoft
2.6.1.1.2. Clock Crosser
The working principle of the clock crosser is to let the crossed-over data stabilize first before indicating that the data is valid in the latched clock domain. Using such structure, the data bits must not skew for more than one latched clock period. The timing constraint file applies a common timing check over all the clock crossers irrespective of their latched clock domain. This is over-pessimistic for signals crossing into the CSR clock, but there are no side-effects, like significant run-time impact and false violations, during the internal testing. If your design runs into clock crosser timing violation paths within the IP and the latched clock domain is csr_clk, you can dismiss the violation manually or by editing the .sdc file if the violation is less than one csr_clk period.
The timing constraint file uses the set_net_delay to constraint the fitter placement and set_max_skew to perform timing check on the paths. For a project with very high device utilization, Altera recommends that you implement addition steps like floor planning or Logic Lock to aid the place-and-route process. The additional steps can give a more consistent timing closure along these paths instead of only relying on the set_net_delay.
A caveat of using set_max_skew is that it does not analyze whether the insertion delay of the path in concern exceeds a limit. In other words, a path could meet skew requirement but have longer than expected insertion delay. If this is not checked, it may cause functional failure in certain latency-sensitive paths. Therefore, a custom script (alt_em10g32_clock_crosser_timing_info.tcl) is available for you to check that the round-trip clock crosser delay is within expectation. To use this script, manually add it to the user flow and run it. To ensure that the IP core operates correctly, the results must be positive (no error).