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

Overview - Synthesizable vs non-synthesizable constructs

What is it?

In Verilog, synthesizable constructs are code parts that can be turned into real hardware circuits by synthesis tools. Non-synthesizable constructs are used only for simulation and cannot be made into hardware. Synthesizable code describes actual hardware behavior, while non-synthesizable code helps test or verify designs.

Why it matters

Knowing the difference helps you write Verilog that can be built into chips or FPGAs. Without this, you might write code that works in simulation but fails when making real hardware, wasting time and resources. It ensures your designs are practical and manufacturable.

Where it fits

Before this, you should understand basic Verilog syntax and hardware concepts like registers and gates. After this, you can learn about synthesis tools, timing constraints, and testbench creation.

Mental Model

Core Idea

Synthesizable constructs describe real hardware circuits, while non-synthesizable constructs only simulate behavior and cannot become hardware.

Think of it like...

It's like writing a recipe for a cake (synthesizable) versus writing notes about how you tasted the cake (non-synthesizable). The recipe can be followed to make a cake, but the notes only help understand or test the cake.

┌─────────────────────────────┐       ┌─────────────────────────────┐
│     Synthesizable Code       │──────▶│   Hardware Circuit Output   │
│  (can be built into chips)  │       │  (real gates and registers) │
└─────────────────────────────┘       └─────────────────────────────┘
          ▲
          │
┌─────────────────────────────┐
│ Non-Synthesizable Code       │
│ (simulation only, no hardware)│
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Verilog as Hardware Description

Concept: Verilog code describes hardware components and their connections.

Verilog lets you write code that looks like software but actually describes circuits. For example, 'reg' means a storage element, and 'wire' means a connection. This code can be turned into gates and flip-flops.

Result

You see that Verilog code can represent physical parts like memory and logic gates.

Understanding that Verilog is not just software code but a hardware blueprint is key to grasping synthesis.

2

Foundation

What Synthesis Tools Do

Concept: Synthesis tools convert synthesizable Verilog into hardware gate-level designs.

Synthesis tools read your Verilog and create a circuit made of logic gates and flip-flops. They ignore code that can't be turned into hardware, like delays or file operations.

Result

You learn that only certain Verilog constructs become real hardware after synthesis.

Knowing synthesis tools' role helps you write code that can be physically built.

3

Intermediate

Common Synthesizable Constructs

🤔Before reading on: do you think 'if-else' statements in Verilog are synthesizable? Commit to your answer.

Concept: Certain Verilog constructs like 'always' blocks with registers and combinational logic are synthesizable.

Examples of synthesizable code include 'always @(posedge clk)' blocks for flip-flops, 'assign' statements for wires, and 'if-else' for conditional logic. These map directly to hardware elements.

Result

You can identify code that synthesis tools will convert into gates and registers.

Recognizing synthesizable patterns lets you design hardware behavior correctly.

4

Intermediate

Non-Synthesizable Constructs Explained

🤔Before reading on: do you think 'initial' blocks can be synthesized into hardware? Commit to your answer.

Concept: Some Verilog features like 'initial' blocks, delays, and file I/O are for simulation only and cannot be synthesized.

'initial' blocks run once at simulation start but have no hardware equivalent. Delays like '#10' pause simulation time but don't exist in real circuits. File operations help testbenches but can't be hardware.

Result

You understand which code parts are for testing and simulation, not hardware.

Knowing non-synthesizable constructs prevents writing code that fails in real hardware.

5

Intermediate

Mixing Synthesizable and Non-Synthesizable Code

Concept: You can write both types in a project but must separate them carefully.

Testbenches use non-synthesizable code to check your design, while the design itself uses synthesizable code. Mixing them incorrectly can cause synthesis errors or unexpected behavior.

Result

You learn to organize code so only hardware parts are synthesized.

Separating simulation-only code from hardware code is essential for successful design and testing.

6

Advanced

Synthesis Tool Limitations and Warnings

🤔Before reading on: do you think synthesis tools always catch all non-synthesizable code? Commit to your answer.

Concept: Synthesis tools may silently ignore or warn about unsupported constructs, which can cause bugs.

Some synthesis tools skip non-synthesizable code without errors, leading to missing hardware parts. Others give warnings or errors. Understanding tool behavior helps catch mistakes early.

Result

You become aware of synthesis tool quirks and the need to check reports carefully.

Knowing synthesis tool behavior helps avoid subtle bugs and ensures your design matches your intent.

7

Expert

Advanced Synthesis: Inferring Hardware from Code

🤔Before reading on: do you think all synthesizable code maps one-to-one to hardware gates? Commit to your answer.

Concept: Synthesis infers hardware structures from code patterns, sometimes optimizing or changing implementation details.

For example, a 'case' statement might become a multiplexer, but synthesis can optimize it differently based on constraints. Some code can infer RAM or DSP blocks. Understanding inference helps write efficient hardware.

Result

You grasp that synthesis is not just translation but intelligent hardware generation.

Understanding inference and optimization lets you write code that leads to better hardware performance and resource use.

Under the Hood

Synthesis tools parse Verilog code and build an internal representation of hardware components and connections. They analyze control flow and data flow to infer registers, combinational logic, and memories. Non-synthesizable constructs are ignored or cause errors. The tool then maps this representation to technology-specific gates and cells.

Why designed this way?

Verilog was created to describe hardware behavior, not just software. Separating synthesizable from non-synthesizable code allows designers to simulate complex behaviors and test designs without confusing hardware implementation. This separation also lets synthesis tools optimize hardware generation while supporting rich simulation features.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Verilog Code  │──────▶│ Synthesis     │──────▶│ Hardware      │
│ (Synthesizable│       │ Tool parses   │       │ Circuit       │
│ & Non-Synth.) │       │ & infers HW   │       │ (Gates, Regs) │
└───────────────┘       └───────────────┘       └───────────────┘
          │
          ▼
┌─────────────────┐
│ Simulation Engine│
│ (runs all code, │
│ including non-   │
│ synthesizable)   │
└─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think 'initial' blocks are synthesizable into hardware? Commit yes or no.

Common Belief: 'initial' blocks can be used to initialize hardware registers in synthesis.

Reality: 'initial' blocks are ignored by synthesis tools and only run during simulation.

Why it matters: Using 'initial' to set hardware values leads to uninitialized registers in real circuits, causing unpredictable behavior.

Quick: Do you think delays like '#10' affect real hardware timing? Commit yes or no.

Common Belief: Delays in Verilog code control hardware timing directly.

Reality: Delays only affect simulation timing and have no effect on actual hardware.

Why it matters: Relying on delays for hardware timing causes designs that fail to meet timing requirements in real circuits.

Quick: Do you think all 'always' blocks are synthesizable? Commit yes or no.

Common Belief: Any 'always' block in Verilog is synthesizable.

Reality: Only 'always' blocks with synthesizable constructs (like clocked or combinational logic) are synthesized; others may be ignored or cause errors.

Why it matters: Misusing 'always' blocks can lead to missing hardware or synthesis failures.

Quick: Do you think synthesis tools always warn about non-synthesizable code? Commit yes or no.

Common Belief: Synthesis tools always detect and warn about non-synthesizable code.

Reality: Some tools silently ignore unsupported code, leading to missing hardware without clear warnings.

Why it matters: This can cause subtle bugs where parts of the design are missing in the final hardware.

Expert Zone

1

Some synthesizable constructs can infer different hardware depending on synthesis options and target technology, affecting performance and area.

2

Non-synthesizable code can sometimes be conditionally included using synthesis directives to aid debugging without affecting hardware.

3

Synthesis tools may optimize away seemingly important code if it doesn't affect outputs, so understanding tool optimizations is crucial.

When NOT to use

Avoid using non-synthesizable constructs in design code meant for hardware. Instead, use testbenches or verification languages like SystemVerilog or UVM for simulation-only features. For hardware description, rely on synthesizable constructs and vendor-specific primitives when needed.

Production Patterns

In production, designs separate synthesizable RTL code from testbenches. Designers use synthesis pragmas and constraints to guide hardware generation. Verification environments use non-synthesizable constructs extensively for stimulus and checking. Code reviews and automated checks ensure no non-synthesizable code leaks into hardware modules.

Connections

Hardware Description Languages (HDLs)

Synthesizable vs non-synthesizable constructs are a core concept in all HDLs like VHDL and SystemVerilog.

Understanding this distinction in Verilog helps grasp similar concepts in other HDLs, enabling cross-language hardware design skills.

Software Compilation

Synthesizing Verilog is like compiling software code into machine code, but for hardware circuits.

Knowing how synthesis translates code to hardware gates is similar to how compilers translate code to CPU instructions, deepening understanding of both processes.

Project Management in Engineering

Separating synthesizable and non-synthesizable code parallels separating design and testing phases in engineering projects.

Recognizing this separation improves workflow organization and reduces errors in complex hardware projects.

Common Pitfalls

#1 Using 'initial' blocks to set register values expecting hardware initialization.

Wrong approach:

initial begin
reg1 = 1'b0;
end

Correct approach:

always @(posedge clk or negedge reset_n) begin
if (!reset_n) reg1 <= 1'b0;
else reg1 <= next_value;
end

Root cause:

Misunderstanding that 'initial' blocks only run in simulation and do not synthesize into hardware reset logic.

#2 Using delays like '#5' to control hardware timing.

Wrong approach:

assign out = #5 in;

Correct approach:

Use clocked logic and timing constraints instead of delays for hardware timing control.

Root cause:

Confusing simulation time delays with real hardware timing, which depends on clocks and physical properties.

#3 Mixing file I/O operations inside design code intended for synthesis.

Wrong approach:

initial begin
$readmemh("data.hex", memory);
end

Correct approach:

Use file I/O only in testbenches, not in synthesizable modules.

Root cause:

Not separating simulation-only constructs from hardware description code.

Key Takeaways

Synthesizable constructs in Verilog describe real hardware and can be turned into circuits by synthesis tools.

Non-synthesizable constructs are for simulation and testing only and do not become hardware.

Understanding the difference prevents design errors that work in simulation but fail in real hardware.

Synthesis tools translate code into gates but may optimize or ignore unsupported constructs silently.

Separating design and test code clearly is essential for successful hardware development.

Practice

1. Which of the following Verilog constructs is non-synthesizable and used only for simulation?

easy

A. Module instantiations

B. Initial blocks (initial)

C. Continuous assignments (assign)

D. Always blocks (always)

Solution

1. Step 1: Understand the role of initial blocks

   initial blocks run once at simulation start and are not synthesizable into hardware.

2. Step 2: Compare with synthesizable constructs

   always blocks, assign statements, and module instantiations describe hardware and are synthesizable.

3. Final Answer:

   Initial blocks (initial) -> Option B

4. Quick Check:

   initial = Non-synthesizable [OK]

Hint: Remember: initial blocks only simulate, never synthesize [OK]

Common Mistakes:

• Confusing always with initial
• Thinking assign is non-synthesizable
• Assuming module instantiations are simulation-only

2. Which of the following is the correct syntax for a synthesizable always block sensitive to the positive edge of clock clk?

easy

A. always @(clk or reset) begin ... end

B. always @(clk) begin ... end

C. always @(negedge clk or posedge reset) begin ... end

D. always @(posedge clk) begin ... end

Solution

1. Step 1: Identify correct edge sensitivity

   Synthesizable clocked logic uses posedge clk or negedge clk to trigger on clock edges.

2. Step 2: Check syntax correctness

   always @(posedge clk) is correct; always @(clk) triggers on any change, which is not typical for clocked logic.

3. Final Answer:

   always @(posedge clk) begin ... end -> Option D

4. Quick Check:

   Use posedge clk for clock edge sensitivity [OK]

Hint: Use posedge or negedge for clock edges [OK]

Common Mistakes:

• Using level sensitivity instead of edge sensitivity
• Mixing clock and reset signals incorrectly
• Omitting begin and end for multiple statements

3. What will be the output of the following Verilog code snippet during simulation?

reg [3:0] count;
initial begin
  count = 0;
  #5 count = 4'b1010;
end
always @(posedge clk) begin
  count <= count + 1;
end

Assuming clk toggles every 1 time unit starting at 0.

medium

A. Count stays 0 until time 5, then becomes 10 and increments every clock cycle

B. Count increments every clock cycle starting from 0, then changes to 10 at time 5

C. Count increments every clock cycle starting from 0, ignoring the initial block

D. Count remains 0 throughout simulation

Solution

1. Step 1: Analyze initial block effect

   The initial block sets count to 0 at time 0, then to 10 at time 5 (delay #5).

2. Step 2: Analyze always block behavior

   The always block increments count on every positive clock edge, but the non-blocking assignment means the update happens after the clock edge, so the delayed assignment at time 5 overrides the count value at that time.

3. Final Answer:

   Count stays 0 until time 5, then becomes 10 and increments every clock cycle -> Option A

4. Quick Check:

   initial #delay executes after clock edges [OK]

Hint: Delayed initial affects count after clock increments [OK]

Common Mistakes:

• Ignoring the initial block's delayed assignment
• Assuming count increments from 10 immediately
• Confusing blocking and non-blocking assignments

4. Identify the error in the following Verilog code snippet that prevents synthesis:

always @(posedge clk) begin
  integer i;
  for (i = 0; i < 4; i = i + 1) begin
    data[i] = i;
  end
end

medium

A. Using an integer variable inside an always block for synthesis

B. Declaring a loop variable inside the always block

C. Using blocking assignment (=) instead of non-blocking (<=) inside always block

D. Using a for loop inside an always block is not synthesizable

Solution

1. Step 1: Check variable declarations and loop usage

   Declaring integer i inside the always block is allowed for synthesis as loop variable.

2. Step 2: Identify assignment type issue

   Using blocking assignment = inside clocked always block causes unintended behavior; non-blocking <= is required for registers.

3. Final Answer:

   Using blocking assignment (=) instead of non-blocking (<=) inside always block -> Option C

4. Quick Check:

   Use non-blocking (<=) in clocked always blocks [OK]

Hint: Use <= for registers inside clocked always blocks [OK]

Common Mistakes:

• Thinking loop variables cannot be declared inside always blocks
• Believing for loops are non-synthesizable
• Ignoring difference between blocking and non-blocking assignments

5. You want to create a synthesizable Verilog module that counts the number of times an input signal sig is high during clock cycles, but also print the count value for debugging during simulation. Which approach correctly separates synthesizable and non-synthesizable constructs?

hard

A. Use an always @(posedge clk) block to increment count and an initial block with $display to print count

B. Use an always @(posedge clk) block to increment count and a separate always block with $display to print count

C. Use a continuous assignment to increment count and initial block to print count

D. Use a task to increment count and a function to print count

Solution

1. Step 1: Identify synthesizable counting logic

   Counting on clock edges must be in an always @(posedge clk) block using non-blocking assignments.

2. Step 2: Identify non-synthesizable debugging code

   Printing with $display is simulation-only and must be placed in an initial or separate simulation-only block.

3. Final Answer:

   Use an always @(posedge clk) block to increment count and an initial block with $display to print count -> Option A

4. Quick Check:

   Separate hardware logic and simulation prints [OK]

Hint: Put printing in initial, counting in clocked always [OK]

Common Mistakes:

• Trying to print inside synthesizable always block
• Using continuous assignment for counting
• Confusing tasks/functions for simulation prints