Quartus® Prime Pro Edition User Guide: Platform Designer

ID 683609
Date 4/01/2024
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

4.7.3. Reducing Logic Utilization With Multiple Clock Domains

You specify clock domains in Platform Designer on the System View tab. Clock sources can be driven by external input signals to Platform Designer, or by PLLs inside Platform Designer. Clock domains are differentiated based on the name of the clock. You can create multiple asynchronous clocks with the same frequency.

Platform Designer generates Clock Domain Crossing (CDC) logic that hides the details of interfacing components operating in different clock domains. The interconnect supports the memory-mapped protocol with each port independently, and therefore hosts do not need to incorporate clock adapters in order to interface to agents on a different domain. Platform Designer interconnect logic propagates transfers across clock domain boundaries automatically.

Clock-domain adapters provide the following benefits:

  • Allows component interfaces to operate at different clock frequencies.
  • Eliminates the need to design CDC hardware.
  • Allows each memory-mapped port to operate in only one clock domain, which reduces design complexity of components.
  • Enables hosts to access any agent without communication with the agent clock domain.
  • Allows you to focus performance optimization efforts on components that require fast clock speed.

A clock domain adapter consists of two finite state machines (FSM), one in each clock domain, that use a hand-shaking protocol to propagate transfer control signals (read_request, write_request, and the host waitrequest signals) across the clock boundary.

Figure 178. Clock Crossing Adapter


This example illustrates a clock domain adapter between one host and one agent. The synchronizer blocks use multiple stages of flipflops to eliminate the propagation of meta-stable events on the control signals that enter the handshake FSMs. The CDC logic works with any clock ratio.

The typical sequence of events for a transfer across the CDC logic is as follows:

  • The host asserts address, data, and control signals.
  • The host handshake FSM captures the control signals and immediately forces the host to wait. The FSM uses only the control signals, not address and data. For example, the host simply holds the address signal constant until the agent side has safely captured it.
  • The host handshake FSM initiates a transfer request to the agent handshake FSM.
  • The transfer request is synchronized to the agent clock domain.
  • The agent handshake FSM processes the request, performing the requested transfer with the agent.
  • When the agent transfer completes, the agent handshake FSM sends an acknowledge back to the host handshake FSM. The acknowledge is synchronized back to the host clock domain.
  • The host handshake FSM completes the transaction by releasing the host from the wait condition.

Transfers proceed as normal on the agent and the host side, without a special protocol to handle crossing clock domains. From the perspective of an agent, there is nothing different about a transfer initiated by a host in a different clock domain. From the perspective of a host, a transfer across clock domains simply requires extra clock cycles. Similar to other transfer delay cases (for example, arbitration delay or wait states on the agent side), the Platform Designer forces the host to wait until the transfer terminates. As a result, pipeline host ports do not benefit from pipelining when performing transfers to a different clock domain.

Platform Designer automatically determines where to insert CDC logic based on the system and the connections between components, and places CDC logic to maintain the highest transfer rate for all components. Platform Designer evaluates the need for CDC logic for each host and agent pair independently, and generates CDC logic wherever necessary.