{"id":328,"date":"2016-05-17T10:00:20","date_gmt":"2016-05-17T17:00:20","guid":{"rendered":"http:\/\/www.verilogpro.com\/?p=328"},"modified":"2022-09-29T00:46:01","modified_gmt":"2022-09-29T07:46:01","slug":"clock-domain-crossing-design-part-3","status":"publish","type":"post","link":"https:\/\/www.verilogpro.com\/clock-domain-crossing-design-part-3\/","title":{"rendered":"Clock Domain Crossing Design – Part 3"},"content":{"rendered":"\n

In Clock Domain Crossing (CDC) Design – Part 2<\/a>, I discussed potential problems with passing multiple signals across a clock domain, and one effective and safe way to do so. That circuit, however, does hot handle the case when the destination side logic cannot accept data and needs to back-pressure the source side. The two feedback schemes in this article add this final piece.<\/p>\n\n\n\n

The concepts in this article are again taken from Cliff Cummings’ very comprehensive paper Clock Domain Crossing (CDC) Design & Verification Techniques Using SystemVerilog<\/a>. I highly recommend taking an hour or two to read through it.<\/p>\n\n\n\n

Multi-cycle path (MCP) formulation with feedback<\/h3>\n\n\n\n

How can the source domain logic know when it is safe to send the next piece of data to the synchronizer? It can wait a fixed number of cycles, which can be determined from the synchronizer circuit. But a better way is to have logic in the synchronizer to indicate this to the source domain. The following figure illustrates how this can be done. Compared to the MCP without feedback circuit, it adds a 1-bit finite state machine (FSM) to indicate to the source domain whether the synchronizer is ready to accept a new piece of data.<\/p>\n\n\n\n

MCP synchronizer with feedback<\/a><\/figure><\/div>\n\n\n\n

The 1-bit FSM has 2 states, 2 inputs, and 1 output (besides clock and reset).<\/p>\n\n\n\n

  • States: Idle, Busy<\/li>
  • Inputs: src_send, src_ack<\/li>
  • Output: src_rdy<\/li><\/ul>\n\n\n\n

    The logic is simple. src_send<\/i> causes the FSM to transition to Busy, src_ack<\/i> causes the FSM to transition back to Idle. src_rdy<\/i> output is 1 when Idle, and 0 when Busy. The user logic outside the synchronizer needs to monitor these signals to determine when it is safe to send a new piece of data.<\/p>\n\n\n\n