Clock domain crossing awareness in Verilog - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare a flip-flop that captures data on the rising edge of clk.

Verilog

always @(posedge [1]) begin
  q <= d;
end

Drag options to blanks, or click blank then click option'

Arst

Bclk

Cdata

Dnegedge clk

Attempts:

3 left

💡 Hint

Common Mistakes

Using reset signal instead of clock edge.

Using falling edge instead of rising edge.

The flip-flop captures data on the rising edge of the clock signal clk.

2fill in blank

medium

Complete the code to instantiate a two-stage synchronizer for crossing from clk_a to clk_b domain.

Verilog

reg sync_[1]_1, sync_[1]_2;
always @(posedge clk_b) begin
  sync_[1]_1 <= signal_a;
  sync_[1]_2 <= sync_[1]_1;
end

Drag options to blanks, or click blank then click option'

Adata

Bclk

Crst

Dsig

Attempts:

3 left

💡 Hint

Common Mistakes

Using clock or reset names instead of signal name.

Using inconsistent names for the two flip-flops.

The synchronizer uses two flip-flops named with the signal name, here sig, to reduce metastability.

3fill in blank

hard

Fix the error in the code to safely transfer a pulse from clk_a to clk_b domain using a handshake.

Verilog

reg pulse_a, pulse_b;
always @(posedge clk_a) begin
  if (reset) pulse_a <= 0;
  else pulse_a <= [1];
end

Drag options to blanks, or click blank then click option'

Apulse_b

Bpulse_a

C1'b1

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Assigning pulse_a to itself causing no change.

Assigning pulse_b which is in another clock domain.

To generate a pulse, assign 1'b1 to pulse_a when needed, not the other signals.

4fill in blank

hard

Fill both blanks to complete a Gray code counter for safe multi-bit clock domain crossing.

Verilog

always @(posedge [1]) begin
  if (reset) gray_count <= 0;
  else gray_count <= gray_count [2] 1;
end

Drag options to blanks, or click blank then click option'

Aclk

B+

C^

D-

Attempts:

3 left

💡 Hint

Common Mistakes

Using addition instead of XOR for Gray code.

Using wrong clock signal name.

The Gray code counter increments by XORing the current count with 1 on the clock clk.

5fill in blank

hard

Fill all three blanks to implement a handshake signal crossing from clk_a to clk_b domain.

Verilog

reg [1]_a, [1]_b;
always @(posedge clk_a) begin
  [1]_a <= request;
end
always @(posedge clk_b) begin
  [2] <= [1]_a;
  ack <= [2];
end

Drag options to blanks, or click blank then click option'

Areq

Breq_sync

Creq_a

Dack_sync

Attempts:

3 left

💡 Hint

Common Mistakes

Using the same name for signals in different clock domains.

Mixing request and acknowledgment signal names.

The handshake uses req_a in clk_a domain, synchronized as req_sync in clk_b domain, and acknowledgment ack_sync.

Practice

1. What is the main purpose of using a synchronizer in clock domain crossing?

easy

A. To safely transfer signals between different clock domains

B. To increase the clock frequency

C. To reduce power consumption

D. To generate a new clock signal

Solution

1. Step 1: Understand clock domain crossing

   Signals crossing from one clock domain to another can cause timing errors if not handled properly.

2. Step 2: Role of synchronizers

   Synchronizers, typically two flip-flops in series, help avoid metastability by safely transferring signals between different clock domains.

3. Final Answer:

   To safely transfer signals between different clock domains -> Option A

4. Quick Check:

   Synchronizer = Safe signal transfer [OK]

Hint: Synchronizers prevent timing errors between clocks [OK]

Common Mistakes:

• Thinking synchronizers increase clock speed
• Confusing synchronizers with power-saving methods
• Assuming synchronizers generate clocks

2. Which Verilog code snippet correctly implements a 2-flip-flop synchronizer for a single-bit signal async_signal crossing into clk domain?

easy

A. reg sync_0, sync_1; always @(posedge clk) begin sync_1 <= async_signal; sync_0 <= sync_1; end

B. reg sync_0, sync_1; always @(posedge clk) begin sync_0 <= async_signal; sync_1 <= sync_0; end

C. reg sync_0, sync_1; always @(posedge async_signal) begin sync_0 <= clk; sync_1 <= sync_0; end

D. reg sync_0, sync_1; always @(negedge clk) begin sync_0 <= async_signal; sync_1 <= sync_0; end

Solution

1. Step 1: Identify correct clock edge and signal assignment

   The synchronizer must sample the asynchronous signal on the positive edge of the destination clock (clk), so posedge clk is correct.

2. Step 2: Check flip-flop chaining order

   The first flip-flop captures async_signal, the second captures the output of the first. This is correctly done as sync_0 <= async_signal; then sync_1 <= sync_0;.

3. Final Answer:

   reg sync_0, sync_1; always @(posedge clk) begin sync_0 <= async_signal; sync_1 <= sync_0; end -> Option B

4. Quick Check:

   Correct clock edge and flip-flop order = reg sync_0, sync_1; always @(posedge clk) begin sync_0 <= async_signal; sync_1 <= sync_0; end [OK]

Hint: Use posedge clk and chain flip-flops in order [OK]

Common Mistakes:

• Using negedge instead of posedge
• Swapping flip-flop assignments
• Triggering on async_signal edge

3. Given the following Verilog code snippet crossing a signal data_in from clk_a domain to clk_b domain using a 2-flip-flop synchronizer, what is the expected output of data_sync after several clock cycles?

reg sync_0, sync_1;
always @(posedge clk_b) begin
  sync_0 <= data_in;
  sync_1 <= sync_0;
end
assign data_sync = sync_1;

medium

A. The code will cause a synthesis error

B. data_sync will always match data_in immediately

C. data_sync will never change from initial value

D. data_sync will be a delayed and synchronized version of data_in

Solution

1. Step 1: Understand synchronizer behavior

   The 2-flip-flop synchronizer delays the asynchronous input by two clock cycles of clk_b and reduces metastability risk.

2. Step 2: Analyze output data_sync

   data_sync reflects data_in but delayed and synchronized to clk_b domain, not immediate.

3. Final Answer:

   data_sync will be a delayed and synchronized version of data_in -> Option D

4. Quick Check:

   Synchronizer output = delayed synchronized signal [OK]

Hint: Synchronizer delays and syncs signals, no immediate match [OK]

Common Mistakes:

• Expecting immediate signal match
• Assuming no delay in synchronization
• Thinking code causes synthesis error

4. Identify the problem in this Verilog code crossing a multi-bit signal data_bus[7:0] from clk_a to clk_b domain:

reg [7:0] sync_0, sync_1;
always @(posedge clk_b) begin
  sync_0 <= data_bus;
  sync_1 <= sync_0;
end

medium

A. The clock edge should be negedge instead of posedge

B. The code is correct and safe for multi-bit crossing

C. Multi-bit signals require handshake or FIFO, not simple flip-flop synchronizers

D. Missing reset signals causes metastability

Solution

1. Step 1: Recognize multi-bit signal crossing issues

   Multi-bit signals crossing clock domains can cause data corruption if bits change at different times.

2. Step 2: Understand proper methods for multi-bit crossing

   Simple flip-flop synchronizers are not safe for multi-bit buses; handshake protocols or FIFOs are needed.

3. Final Answer:

   Multi-bit signals require handshake or FIFO, not simple flip-flop synchronizers -> Option C

4. Quick Check:

   Multi-bit crossing needs handshake/FIFO [OK]

Hint: Use handshake or FIFO for multi-bit signals [OK]

Common Mistakes:

• Assuming flip-flops alone are safe for buses
• Changing clock edge without reason
• Ignoring metastability risks

5. You need to transfer a 16-bit data word from clk_fast domain to clk_slow domain safely. Which method best ensures data integrity and avoids metastability?

hard

A. Use a handshake protocol with data valid and acknowledge signals

B. Directly assign the data bus without synchronization

C. Use a 2-flip-flop synchronizer on each bit individually

D. Use asynchronous reset on the data bus

Solution

1. Step 1: Consider multi-bit data crossing challenges

   Transferring 16-bit data across clock domains risks partial updates and metastability if not handled properly.

2. Step 2: Evaluate synchronization methods

   Using handshake protocols with valid and acknowledge signals ensures complete and safe data transfer between different clock domains.

3. Final Answer:

   Use a handshake protocol with data valid and acknowledge signals -> Option A

4. Quick Check:

   Handshake ensures safe multi-bit crossing [OK]

Hint: Handshake protocols ensure safe multi-bit crossing [OK]

Common Mistakes:

• Trying to synchronize each bit separately
• Ignoring synchronization and assigning directly
• Relying on asynchronous reset for crossing