Synthesizable vs non-synthesizable constructs in VHDL - Trade-offs & Expert Analysis

Overview - Synthesizable vs non-synthesizable constructs

What is it?

In VHDL, synthesizable constructs are code parts that can be directly turned into hardware by synthesis tools. Non-synthesizable constructs are used only for simulation or testing and cannot be made into real hardware. Understanding the difference helps you write VHDL code that works both in simulation and on actual chips. This topic explains which VHDL features create hardware and which are just for checking designs.

Why it matters

Without knowing which parts of VHDL code can be made into hardware, you might write code that works in simulation but fails when building a real circuit. This wastes time and resources. Knowing the difference ensures your designs are practical and implementable, saving effort and avoiding costly mistakes in chip design.

Where it fits

Before this, you should understand basic VHDL syntax and how to write simple hardware descriptions. After this, you will learn about synthesis tools, timing constraints, and how to optimize VHDL code for hardware implementation.

Mental Model

Core Idea

Synthesizable constructs describe real hardware components, while non-synthesizable constructs are only for simulation and cannot become physical circuits.

Think of it like...

Think of synthesizable constructs as blueprints for building a house, while non-synthesizable constructs are like notes or sketches used only during planning but never part of the actual building.

┌─────────────────────────────┐
│        VHDL Code            │
├──────────────┬──────────────┤
│ Synthesizable│ Non-Synthesizable│
│ Constructs   │ Constructs    │
│ (Hardware)   │ (Simulation)  │
│              │              │
│ - Logic gates│ - Testbenches │
│ - Flip-flops │ - File I/O    │
│ - Registers  │ - Wait statements│
└──────────────┴──────────────┘

Build-Up - 7 Steps

1

Foundation

What is VHDL synthesis

Concept: Introduce the idea that VHDL code can be converted into hardware circuits.

VHDL is a language used to describe hardware. Synthesis is the process where special software reads VHDL code and creates a real hardware design, like logic gates and flip-flops. Not all VHDL code can be turned into hardware; only certain parts are synthesizable.

Result

You understand that synthesis turns VHDL code into physical circuits.

Understanding synthesis is key because it separates code that builds hardware from code that only simulates behavior.

2

Foundation

Basic synthesizable constructs

Concept: Learn which VHDL elements can be synthesized into hardware.

Synthesizable constructs include signals, variables, processes with clocked logic, combinational logic using if-else or case statements, and simple arithmetic. For example, a process triggered by a clock edge describes a flip-flop. These constructs map directly to hardware components.

Result

You can identify simple VHDL code that will become hardware.

Knowing these basic constructs helps you write code that synthesis tools can understand and implement.

3

Intermediate

Common non-synthesizable constructs

Concept: Recognize VHDL features that cannot be made into hardware.

Non-synthesizable constructs include file reading/writing, text output, wait statements without clocks, and certain loops that depend on runtime values. These are useful for testbenches and simulation but have no hardware equivalent.

Result

You can spot code that will fail synthesis or is only for simulation.

Distinguishing these constructs prevents writing code that looks correct but cannot be implemented in hardware.

4

Intermediate

Testbenches and simulation-only code

Concept: Understand the role of non-synthesizable code in testing designs.

Testbenches use non-synthesizable constructs to simulate inputs, check outputs, and control simulation time. They often use wait statements, file I/O, and assertions. This code helps verify hardware behavior before building it but is never part of the final hardware.

Result

You see how simulation-only code supports design verification.

Knowing the purpose of testbenches clarifies why some code is excluded from synthesis.

5

Intermediate

Synthesis tool limitations and pragmas

🤔Before reading on: do you think all VHDL code is treated equally by synthesis tools? Commit to yes or no.

Concept: Learn that synthesis tools have rules and sometimes need hints to handle code correctly.

Synthesis tools support a subset of VHDL and may ignore or error on unsupported constructs. Designers use pragmas or attributes to guide synthesis, like marking signals as don't-care or specifying timing. Understanding tool limitations helps write compatible code.

Result

You know synthesis tools have boundaries and ways to control synthesis behavior.

Recognizing tool constraints helps avoid surprises and ensures your code synthesizes as intended.

6

Advanced

Mixed synthesizable and non-synthesizable code

🤔Before reading on: can synthesizable and non-synthesizable code coexist in the same VHDL file? Commit to yes or no.

Concept: Explore how to organize code that contains both hardware description and simulation-only parts.

VHDL files often contain both synthesizable code (for hardware) and non-synthesizable code (for testing). Designers separate these using configurations, generate statements, or conditional compilation. This keeps hardware code clean and simulation code flexible.

Result

You understand how to manage mixed code for practical design workflows.

Knowing how to separate concerns improves design clarity and prevents synthesis errors.

7

Expert

Subtle synthesis pitfalls and workarounds

🤔Before reading on: do you think a wait statement inside a process is always non-synthesizable? Commit to yes or no.

Concept: Reveal tricky cases where synthesis tools interpret code differently than simulation.

Some constructs like wait statements are non-synthesizable in general, but synthesis tools may accept limited forms (e.g., wait on clock). Also, loops with variable bounds or complex data types may cause synthesis failures. Experts use coding styles and tool-specific pragmas to work around these issues.

Result

You gain insight into advanced synthesis challenges and solutions.

Understanding these subtleties prevents hidden bugs and improves hardware reliability.

Under the Hood

Synthesis tools parse VHDL code and translate synthesizable constructs into hardware components like gates, flip-flops, and multiplexers. They ignore or error on non-synthesizable constructs because these have no hardware equivalent. The tools build a netlist representing the circuit, which is then used for physical chip design.

Why designed this way?

VHDL was created for both simulation and hardware description, so it includes features for testing and debugging that don't map to hardware. Separating synthesizable and non-synthesizable constructs allows designers to write flexible code for both purposes without mixing concerns.

┌───────────────┐      ┌───────────────┐
│ VHDL Source   │─────▶│ Synthesis Tool│
└───────────────┘      └──────┬────────┘
                              │
          ┌───────────────────┴────────────┐
          │                                │
  ┌───────────────┐                ┌───────────────┐
  │Synthesizable   │                │Non-Synthesizable│
  │Constructs     │                │Constructs      │
  └───────────────┘                └───────────────┘
          │                                │
          ▼                                ▼
  ┌───────────────┐                ┌───────────────┐
  │Hardware Netlist│                │Simulation Only │
  └───────────────┘                └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Is every VHDL process synthesizable? Commit to yes or no.

Common Belief: All VHDL processes can be synthesized into hardware.

Reality: Only processes that follow certain rules (like clocked processes without wait statements) are synthesizable; others are for simulation only.

Why it matters: Assuming all processes synthesize leads to code that fails during hardware implementation, causing delays.

Quick: Can wait statements be used in synthesizable code? Commit to yes or no.

Common Belief: Wait statements are allowed in synthesizable VHDL code.

Reality: Wait statements are generally non-synthesizable except in very limited forms supported by some tools.

Why it matters: Using wait statements incorrectly causes synthesis errors or unexpected hardware behavior.

Quick: Does simulation behavior always match synthesized hardware? Commit to yes or no.

Common Belief: Simulation results perfectly match the behavior of synthesized hardware.

Reality: Simulation can include non-synthesizable constructs and timing models that do not exist in hardware, so results may differ.

Why it matters: Relying solely on simulation without understanding synthesis differences can cause bugs in the final hardware.

Quick: Are file I/O operations synthesizable? Commit to yes or no.

Common Belief: File reading and writing in VHDL can be synthesized into hardware.

Reality: File I/O is purely for simulation and cannot be implemented in hardware.

Why it matters: Mistaking file I/O as synthesizable wastes effort and causes synthesis failures.

Expert Zone

1

Some synthesis tools accept limited non-standard constructs as synthesizable, but relying on these reduces portability.

2

The use of attributes and pragmas can control synthesis behavior, but misuse can cause subtle bugs or inefficient hardware.

3

Complex data types like records and arrays require careful coding to ensure synthesizability, as not all toolchains support them fully.

When NOT to use

Avoid using non-synthesizable constructs in code intended for hardware implementation. Instead, separate testbench code or use hardware description constructs only. For complex simulation needs, use dedicated simulation languages or environments.

Production Patterns

In real projects, designers separate synthesizable code into modules and keep testbenches in separate files. They use synthesis directives to optimize hardware and rely on continuous integration to catch synthesis issues early.

Connections

Hardware Description Languages (HDLs)

Synthesizable constructs are a core concept shared across HDLs like VHDL and Verilog.

Understanding synthesizability in VHDL helps grasp similar concepts in other HDLs, enabling easier cross-language design.

Software Compilation

Synthesis in VHDL is like compiling software code into machine code, translating high-level instructions into low-level operations.

Seeing synthesis as compilation clarifies why some code constructs are invalid or optimized away.

Project Management

Separating synthesizable and non-synthesizable code parallels separating production code and test code in software projects.

This connection highlights the importance of code organization and modularity for maintainability and correctness.

Common Pitfalls

#1 Using wait statements inside synthesizable processes.

Wrong approach:

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

Correct approach:

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

Root cause:

Misunderstanding that wait statements pause simulation but cannot be implemented as hardware triggers.

#2 Including file I/O operations in hardware code.

Wrong approach:

process
file f : text open read_mode is "input.txt";
begin
readline(f, line);
end process;

Correct approach:

-- File I/O only in testbench, not in synthesizable code
-- Hardware code uses signals and ports only

Root cause:

Confusing simulation-only features with hardware description constructs.

#3 Writing loops with variable bounds that depend on runtime values.

Wrong approach:

for i in 0 to variable_limit loop
-- logic
end loop;

Correct approach:

for i in 0 to constant_limit loop
-- logic
end loop;

Root cause:

Synthesis tools require fixed loop bounds to generate hardware; variable bounds cause synthesis failure.

Key Takeaways

Synthesizable constructs in VHDL describe hardware components that synthesis tools can implement physically.

Non-synthesizable constructs are used only for simulation and testing and cannot become real hardware.

Understanding the difference prevents writing code that works in simulation but fails in hardware implementation.

Organizing code to separate synthesizable and non-synthesizable parts improves design clarity and tool compatibility.

Advanced synthesis requires awareness of tool limitations, pragmas, and subtle coding rules to avoid hidden bugs.

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