We use synthesizable constructs to create hardware circuits from VHDL code. Non-synthesizable constructs help us test and simulate designs but cannot become hardware.
Synthesizable vs non-synthesizable constructs in VHDL
-- Synthesizable example process(clk) begin if rising_edge(clk) then q <= d; end if; end process; -- Non-synthesizable example process begin wait for 10 ns; assert false report "Test message" severity note; wait; end process;
Synthesizable code can be turned into hardware by synthesis tools.
Non-synthesizable code is used only during simulation and testing.
process(clk) begin if rising_edge(clk) then q <= d; end if; end process;
process begin wait for 10 ns; assert false report "Simulation message" severity note; wait; end process;
signal temp : integer := 0; process(clk) begin if rising_edge(clk) then temp <= temp + 1; end if; end process;
process begin report "Starting simulation"; wait for 20 ns; report "Ending simulation"; wait; end process;
This VHDL code shows a synthesizable flip-flop that copies input d to output q on clock rising edge. It also has a non-synthesizable process that waits 10 ns and prints a message during simulation.
library ieee; use ieee.std_logic_1164.all; entity example is port( clk : in std_logic; d : in std_logic; q : out std_logic ); end example; architecture behavior of example is begin -- Synthesizable process: flip-flop process(clk) begin if rising_edge(clk) then q <= d; end if; end process; -- Non-synthesizable process: simulation message process begin wait for 10 ns; report "Simulation started" severity note; wait; end process; end behavior;
Only synthesizable constructs can be converted into hardware by synthesis tools.
Non-synthesizable constructs like 'wait for' or 'report' are ignored by synthesis but useful for simulation.
Always separate testbench code (non-synthesizable) from your hardware design code (synthesizable).
Synthesizable constructs describe real hardware behavior.
Non-synthesizable constructs help test and simulate but do not become hardware.
Use synthesizable code for design, non-synthesizable for simulation and debugging.
Practice
Solution
Step 1: Identify synthesizable constructs
Synthesizable code must describe hardware behavior, typically using clocked processes without delays or waits.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.Final Answer:
A process with only clocked assignments and no wait statements -> Option DQuick Check:
Synthesizable = clocked process without wait [OK]
- Thinking wait statements are synthesizable
- Confusing assert for hardware logic
- Assuming file I/O can be synthesized
Solution
Step 1: Understand wait statement restrictions
Wait statements likewait until clk = '1';are not synthesizable because hardware cannot implement arbitrary waits.Step 2: Check other options
Options A, B, and C are standard synthesizable constructs: clock edge detection, signal assignments in processes, and concurrent assignments.Final Answer:
A process with a wait until clk = '1'; statement -> Option AQuick Check:
Wait statements = non-synthesizable [OK]
- Assuming wait until is synthesizable
- Confusing sensitivity list with wait statements
- Thinking concurrent assignments are non-synthesizable
process(clk)
begin
if rising_edge(clk) then
if reset = '1' then
q <= '0';
else
q <= d;
end if;
end if;
end process;Solution
Step 1: Analyze reset behavior inside clocked process
The reset check is inside the rising_edge(clk) condition, so reset is synchronous.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.Final Answer:
q synchronously resets to '0' on clock edge when reset is '1' -> Option AQuick Check:
Synchronous reset inside clock edge = q synchronously resets to '0' on clock edge when reset is '1' [OK]
- Thinking reset is asynchronous here
- Assuming q changes immediately without clock
- Ignoring the rising_edge condition
process(clk) begin wait until clk = '1'; q <= d; end process;
Solution
Step 1: Check for wait statement usage
Wait statements inside processes are not synthesizable and cause synthesis errors.Step 2: Verify other syntax elements
The process has a sensitivity list (clk), signal assignment is inside process, and <= is correctly used.Final Answer:
Using wait statement inside a clocked process -> Option CQuick Check:
Wait inside process = synthesis error [OK]
- Ignoring that wait is not synthesizable
- Confusing sensitivity list with wait usage
- Thinking <= operator is wrong here
Solution
Step 1: Identify testbench constructs
Testbenches often usewait forstatements to simulate timing delays, which are non-synthesizable.Step 2: Compare with synthesizable constructs
Options A, C, and D describe synthesizable hardware behavior, not simulation-only code.Final Answer:
A process with wait for 20 ns; to generate clock signals -> Option BQuick Check:
Wait for delays = simulation only [OK]
- Using wait for in synthesizable design code
- Confusing testbench and design code constructs
- Assuming clocked processes are non-synthesizable
Ready to prove it?
Pass the test and this pattern moves unknown
