No Sync Data Paths in Derived Clock Domain

From this alteraforum post:

If you do use a ripple or gated clock to drive a derived clock domain, then have no synchronous data paths going to or from the derived clock domain.

Treat all cross-domain data paths as asynchronous paths. Use metastability synchronization registers, handshake signals, etc. to transfer data to or from the derived clock domain. The Quartus II Design Assistant has some design-rule checks for data paths crossing between asynchronous clock domains.

Tell the Quartus II software not to analyze timing on the asynchronous cross-domain data paths. In TimeQuest, use set_clock_groups or set_false_path timing exceptions. You can use set_false_path directly on the data paths, but TimeQuest can more efficiently process set_clock_groups or set_false_path between clock names, preventing timing analysis of all data paths crossing between the domains in both directions for set_clock_groups and in the single direction specified for set_false_path. Use create_generated_clock to create a derived clock name that can be used in the timing exception commands. For TimeQuest, you need to create the generated clock anyway if the derived clock is a ripple clock.

Use global routing for the derived clock to minimize skew for data paths within the domain. If all cross-domain data paths are treated as asynchronous, then the additional clock skew induced by the global buffer for the cross-domain paths does not matter.

Add picture from clipboard (Maximum size: 1 GB)