Synthesizable vs non-synthesizable constructs in VHDL - Visual Side-by-Side Comparison

Concept Flow - Synthesizable vs non-synthesizable constructs

Start VHDL Code

↓

Check Construct Type

↓

Synthesizable

↓

Can be mapped

↓

onto hardware

↓

Generate Hardware

↓

End

The flow shows how VHDL code is checked to see if it can be turned into hardware (synthesizable) or only used for simulation (non-synthesizable).

Execution Sample

VHDL

process(clk)
begin
  if rising_edge(clk) then
    q <= d;
  end if;
end process;

This code shows a synthesizable process that copies input d to output q on clock rising edge.

Execution Table

Step	Code Line	Construct Type	Action	Result
1	process(clk)	Synthesizable	Start process triggered by clock	Process waits for clock event
2	if rising_edge(clk) then	Synthesizable	Check clock rising edge	Condition true on clock edge
3	q <= d;	Synthesizable	Assign d to q	q updated with d value
4	end if;	Synthesizable	End if block	Process continues
5	end process;	Synthesizable	End process	Process completes one cycle
6	assert false report "Error" severity note;	Non-Synthesizable	Simulation only	Used for debugging, no hardware
7	wait for 10 ns;	Non-Synthesizable	Simulation delay	Pauses simulation, no hardware
8	end;	N/A	End of code	Execution stops

💡 Reached end of code or non-synthesizable constructs used only in simulation

Variable Tracker

Variable	Start	After Step 3	Final
q	undefined	d value	d value
clk	undefined	rising edge detected	rising edge detected
d	input value	input value	input value

Key Moments - 3 Insights

Why can't 'wait' statements be synthesized into hardware?

'wait' statements pause simulation time but hardware runs continuously; see execution_table row 7 where 'wait for 10 ns;' is non-synthesizable.

Is an 'assert' statement synthesizable?

'assert' is used for simulation checks and debugging only, not for hardware; see execution_table row 6.

Why is the process with 'if rising_edge(clk)' synthesizable?

Because it models hardware clocked behavior that can be implemented physically; see execution_table rows 1-5.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is a non-synthesizable construct first used?

A Step 3

B Step 2

C Step 6

D Step 4

💡 Hint

Check the 'Construct Type' column for 'Non-Synthesizable' starting from step 6.

According to variable_tracker, what is the value of 'q' after step 3?

A d value

B input value

C undefined

D rising edge detected

💡 Hint

Look at the 'q' row under 'After Step 3' in variable_tracker.

If the 'wait for 10 ns;' statement is removed, what changes in the execution_table?

A Step 3 changes to non-synthesizable

B Step 7 disappears, simulation delay removed

C Step 6 becomes synthesizable

D No change at all

💡 Hint

Step 7 is the 'wait' statement marked non-synthesizable; removing it removes that step.

Concept Snapshot

Synthesizable constructs model hardware and can be turned into circuits.
Non-synthesizable constructs run only in simulation (e.g., wait, assert).
Processes with clock edges are synthesizable.
Simulation-only code helps test but not build hardware.
Always check if code maps to hardware before synthesis.

Full Transcript

This visual execution shows how VHDL code is divided into synthesizable and non-synthesizable parts. Synthesizable code, like a process triggered on a clock's rising edge, can be turned into hardware circuits. Non-synthesizable code, such as 'wait' or 'assert' statements, only runs during simulation and cannot be implemented in hardware. The execution table traces each step, showing when hardware-related actions happen and when simulation-only constructs appear. Variable tracking shows how signals like 'q' update during execution. Key moments clarify common confusions about why some constructs cannot be synthesized. The quiz tests understanding by asking about specific steps and variable values. This helps beginners see clearly which parts of VHDL code build hardware and which are for simulation only.

Practice

1. Which of the following VHDL constructs is synthesizable and can be implemented in hardware?

easy

A. Use of assert statements for debugging

B. A process containing wait for 10 ns; statements

C. File I/O operations like reading from a text file

D. A process with only clocked assignments and no wait statements

Solution

1. Step 1: Identify synthesizable constructs

   Synthesizable code must describe hardware behavior, typically using clocked processes without delays or waits.

2. Step 2: Analyze each option

   A process with only clocked assignments and no wait statements uses clocked assignments without waits, so it is synthesizable. Options A, B, and D use waits, assertions, or file I/O, which are non-synthesizable.

3. Final Answer:

   A process with only clocked assignments and no wait statements -> Option D

4. Quick Check:

   Synthesizable = clocked process without wait [OK]

Hint: Synthesizable means no waits or file I/O, just clocked logic [OK]

Common Mistakes:

• Thinking wait statements are synthesizable
• Confusing assert for hardware logic
• Assuming file I/O can be synthesized

2. Which VHDL syntax is not synthesizable?

easy

A. A process with a wait until clk = '1'; statement

B. Concurrent signal assignment outside any process

C. Signal assignment inside a clocked process

D. Using rising_edge(clk) inside a process

Solution

1. Step 1: Understand wait statement restrictions

   Wait statements like wait until clk = '1'; are not synthesizable because hardware cannot implement arbitrary waits.

2. Step 2: Check other options

   Options A, B, and C are standard synthesizable constructs: clock edge detection, signal assignments in processes, and concurrent assignments.

3. Final Answer:

   A process with a wait until clk = '1'; statement -> Option A

4. Quick Check:

   Wait statements = non-synthesizable [OK]

Hint: Wait statements inside processes are never synthesizable [OK]

Common Mistakes:

• Assuming wait until is synthesizable
• Confusing sensitivity list with wait statements
• Thinking concurrent assignments are non-synthesizable

3. What is the output behavior of this VHDL process when synthesized?

process(clk)
begin
  if rising_edge(clk) then
    if reset = '1' then
      q <= '0';
    else
      q <= d;
    end if;
  end if;
end process;

medium

A. q synchronously resets to '0' on clock edge when reset is '1'

B. q asynchronously resets to '0' when reset is '1'

C. q changes immediately when reset is '1', ignoring clock

D. q never resets because reset is ignored

Solution

1. Step 1: Analyze reset behavior inside clocked process

   The reset check is inside the rising_edge(clk) condition, so reset is synchronous.

2. Step 2: Understand output assignment timing

   q is assigned '0' only on clock edge when reset is '1', otherwise q follows d on clock edges.

3. Final Answer:

   q synchronously resets to '0' on clock edge when reset is '1' -> Option A

4. Quick Check:

   Synchronous reset inside clock edge = q synchronously resets to '0' on clock edge when reset is '1' [OK]

Hint: Reset inside rising_edge means synchronous reset [OK]

Common Mistakes:

• Thinking reset is asynchronous here
• Assuming q changes immediately without clock
• Ignoring the rising_edge condition

4. Identify the error in this VHDL code snippet that prevents synthesis:

process(clk)
begin
  wait until clk = '1';
  q <= d;
end process;

medium

A. Signal assignment outside process

B. Missing sensitivity list in process

C. Using wait statement inside a clocked process

D. Incorrect use of <= operator

Solution

1. Step 1: Check for wait statement usage

   Wait statements inside processes are not synthesizable and cause synthesis errors.

2. Step 2: Verify other syntax elements

   The process has a sensitivity list (clk), signal assignment is inside process, and <= is correctly used.

3. Final Answer:

   Using wait statement inside a clocked process -> Option C

4. Quick Check:

   Wait inside process = synthesis error [OK]

Hint: Wait statements inside processes cause synthesis errors [OK]

Common Mistakes:

• Ignoring that wait is not synthesizable
• Confusing sensitivity list with wait usage
• Thinking <= operator is wrong here

5. You want to write a testbench to verify a VHDL design. Which construct is non-synthesizable but useful for simulation only?

hard

A. A clocked process with if rising_edge(clk) condition

B. A process with wait for 20 ns; to generate clock signals

C. Concurrent signal assignment for output signals

D. Signal assignment inside a synchronous reset process

Solution

1. Step 1: Identify testbench constructs

   Testbenches often use wait for statements to simulate timing delays, which are non-synthesizable.

2. Step 2: Compare with synthesizable constructs

   Options A, C, and D describe synthesizable hardware behavior, not simulation-only code.

3. Final Answer:

   A process with wait for 20 ns; to generate clock signals -> Option B

4. Quick Check:

   Wait for delays = simulation only [OK]

Hint: Use wait for delays only in testbenches, not hardware [OK]

Common Mistakes:

• Using wait for in synthesizable design code
• Confusing testbench and design code constructs
• Assuming clocked processes are non-synthesizable