Clock domain considerations in VHDL - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare a clock signal in VHDL.

VHDL

signal clk : [1];

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

Astd_logic

Binteger

Cboolean

Dbit_vector

Attempts:

3 left

💡 Hint

Common Mistakes

Using integer or boolean instead of std_logic for clock signals.

The clock signal in VHDL is typically declared as std_logic type.

2fill in blank

medium

Complete the process sensitivity list to trigger on the rising edge of the clock.

VHDL

process([1])
begin
  if rising_edge(clk) then
    -- process body
  end if;
end process;

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

Areset

Benable

Cdata_in

Dclk

Attempts:

3 left

💡 Hint

Common Mistakes

Including signals other than the clock in the sensitivity list for edge detection.

The process must be sensitive to the clock signal to detect edges.

3fill in blank

hard

Fix the error in the clock domain crossing synchronizer process.

VHDL

process([1])
begin
  if rising_edge(clk_a) then
    sync_reg <= data_b;
  end if;
end process;

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

Areset

Bdata_b

Cclk_a

Dclk_b

Attempts:

3 left

💡 Hint

Common Mistakes

Using the source clock instead of the destination clock in the sensitivity list.

The process must be sensitive to the clock domain it is synchronizing to, here clk_a.

4fill in blank

hard

Fill both blanks to complete a two-stage synchronizer for crossing clock domains.

VHDL

process([1])
begin
  if rising_edge(clk_dest) then
    stage1 <= async_signal;
    stage2 <= [2];
  end if;
end process;

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

Aclk_dest

Basync_signal

Cstage1

Dclk_src

Attempts:

3 left

💡 Hint

Common Mistakes

Using the source clock in sensitivity list or assigning async_signal directly to stage2.

The process is triggered by the destination clock clk_dest. The second stage register stage2 captures the value of stage1 to reduce metastability.

5fill in blank

hard

Fill all three blanks to complete a handshake mechanism between two clock domains.

VHDL

process([1])
begin
  if rising_edge(clk_a) then
    if req = '1' then
      ack <= '1';
    else
      ack <= '0';
    end if;
  end if;
end process;

process([2])
begin
  if rising_edge(clk_b) then
    req <= [3];
  end if;
end process;

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

Aclk_a

Bclk_b

Cack

Dreq

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing clocks in sensitivity lists or assigning wrong signals in handshake.

The first process runs on clk_a to generate ack. The second process runs on clk_b and assigns req to synchronize the handshake.

Practice

1. Why is it important to use synchronizers when signals cross different clock domains in VHDL?

easy

A. To reduce power consumption of the circuit

B. To increase the clock frequency of the receiving domain

C. To prevent metastability and ensure reliable data transfer

D. To simplify the VHDL code syntax

Solution

1. Step 1: Understand metastability in clock domain crossing

   When a signal changes asynchronously between two clock domains, the receiving flip-flop can enter an unstable state called metastability.

2. Step 2: Role of synchronizers

   Synchronizers use multiple flip-flops in series to reduce the chance of metastability affecting the receiving domain, ensuring reliable data transfer.

3. Final Answer:

   To prevent metastability and ensure reliable data transfer -> Option C

4. Quick Check:

   Synchronizers prevent metastability = C [OK]

Hint: Synchronizers prevent unstable signals crossing clocks [OK]

Common Mistakes:

• Thinking synchronizers increase clock speed
• Assuming synchronizers reduce power
• Believing synchronizers simplify code syntax

2. Which of the following VHDL code snippets correctly implements a 2-stage synchronizer for a single-bit signal async_sig crossing into clk domain?

easy

A. process(clk) begin if rising_edge(clk) then sync1 <= async_sig; sync2 <= sync1; end if; end process;

B. process(clk) begin if rising_edge(clk) then sync2 <= async_sig; sync1 <= sync2; end if; end process;

C. process(clk) begin if falling_edge(clk) then sync1 <= async_sig; sync2 <= sync1; end if; end process;

D. process(clk) begin if rising_edge(clk) then sync1 <= sync2; sync2 <= async_sig; end if; end process;

Solution

1. Step 1: Identify correct flip-flop sequence

   The first flip-flop captures the asynchronous signal, the second flip-flop captures the first flip-flop's output.

2. Step 2: Check clock edge and assignment order

   Using rising_edge(clk) is standard, and assignments must be in order: sync1 <= async_sig; sync2 <= sync1;

3. Final Answer:

   process(clk) begin if rising_edge(clk) then sync1 <= async_sig; sync2 <= sync1; end if; end process; -> Option A

4. Quick Check:

   Correct order and clock edge = A [OK]

Hint: First flip-flop captures async signal, second captures first [OK]

Common Mistakes:

• Swapping sync1 and sync2 assignments
• Using falling_edge instead of rising_edge
• Assigning signals in wrong order

3. Given the following VHDL code snippet crossing clock domains, what is the expected behavior of sync2 signal after several clock cycles?

signal async_sig : std_logic;
signal sync1, sync2 : std_logic;

process(clk) begin
  if rising_edge(clk) then
    sync1 <= async_sig;
    sync2 <= sync1;
  end if;
end process;

medium

A. sync2 will immediately match async_sig with no delay

B. sync2 will be a stable, synchronized version of async_sig delayed by two clock cycles

C. sync2 will always be the inverse of async_sig

D. sync2 will cause a runtime error due to signal conflict

Solution

1. Step 1: Understand signal propagation through flip-flops

   sync1 captures async_sig at rising edge, sync2 captures sync1 at next rising edge, causing a two-cycle delay.

2. Step 2: Resulting behavior of sync2

   sync2 becomes a stable, synchronized version of async_sig delayed by two clock cycles, reducing metastability risk.

3. Final Answer:

   sync2 will be a stable, synchronized version of async_sig delayed by two clock cycles -> Option B

4. Quick Check:

   Two flip-flop delay = stable sync2 = A [OK]

Hint: Two flip-flops add two clock cycle delay for stable sync [OK]

Common Mistakes:

• Expecting no delay in sync2
• Thinking sync2 inverts async_sig
• Assuming runtime errors from this code

4. Identify the problem in this VHDL code snippet intended to synchronize a single-bit signal async_sig crossing into clk domain:

process(clk) begin
  if rising_edge(clk) then
    sync2 <= async_sig;
    sync1 <= sync2;
  end if;
end process;

medium

A. The signals sync1 and sync2 are not declared

B. The clock edge should be falling_edge(clk) instead of rising_edge(clk)

C. The process is missing a reset signal

D. The assignments are reversed; sync1 should capture async_sig first

Solution

1. Step 1: Analyze assignment order in process

   sync2 is assigned async_sig first, then sync1 is assigned sync2, which reverses the intended synchronizer chain.

2. Step 2: Correct synchronizer order

   Proper synchronizer assigns sync1 <= async_sig; then sync2 <= sync1; to ensure correct data flow and metastability reduction.

3. Final Answer:

   The assignments are reversed; sync1 should capture async_sig first -> Option D

4. Quick Check:

   Assignment order matters = reversed order = D [OK]

Hint: First flip-flop captures async signal, second captures first [OK]

Common Mistakes:

• Changing clock edge unnecessarily
• Assuming reset is mandatory here
• Ignoring signal declarations

5. You need to transfer an 8-bit data bus async_data from an asynchronous clock domain to a clk domain in VHDL. Which method is the safest and most reliable to avoid data corruption?

hard

A. Use a handshake protocol with ready/acknowledge signals between domains

B. Use a single 2-stage synchronizer on each bit of the data bus

C. Directly assign async_data to a register in the clk domain

D. Use a combinational logic block to pass data asynchronously

Solution

1. Step 1: Understand complexity of multi-bit data crossing clock domains

   Multi-bit data can change asynchronously, causing partial updates and data corruption if not handled carefully.

2. Step 2: Choose proper synchronization method

   Handshake protocols with ready/acknowledge signals ensure data is stable and fully transferred before use, avoiding corruption.

3. Final Answer:

   Use a handshake protocol with ready/acknowledge signals between domains -> Option A

4. Quick Check:

   Handshake ensures safe multi-bit transfer = B [OK]

Hint: Use handshake or FIFO for multi-bit async data transfer [OK]

Common Mistakes:

• Using single-bit synchronizers on multi-bit buses
• Direct asynchronous assignments causing glitches
• Relying on combinational logic for async crossing