Pure vs impure functions in VHDL - Trade-offs & Expert Analysis

Overview - Pure vs impure functions

What is it?

In VHDL, pure and impure functions are ways to write reusable blocks of code that return values. A pure function always produces the same output for the same inputs and does not change any signals or variables outside itself. An impure function may depend on or change things outside its inputs, so its output can vary even with the same inputs.

Why it matters

Using pure functions helps make VHDL designs predictable and easier to understand because their behavior is consistent and side-effect free. Without distinguishing pure and impure functions, designs could become unreliable or hard to debug, as functions might change signals unexpectedly or depend on hidden states.

Where it fits

Before learning pure vs impure functions, you should understand basic VHDL syntax, signals, variables, and how functions work in general. After this, you can learn about procedures, processes, and how to write synthesizable VHDL code.

Mental Model

Core Idea

A pure function in VHDL is like a math formula: same inputs always give the same output without changing anything else, while an impure function can peek outside or change things, making it less predictable.

Think of it like...

Imagine a vending machine that always gives the same snack when you press a button (pure function). Now imagine a vending machine that sometimes gives a different snack depending on how many snacks are left inside or if someone else pressed buttons before you (impure function).

┌───────────────┐       ┌───────────────┐
│   Pure Func   │──────▶│ Output depends │
│ (no side-eff) │       │ only on inputs │
└───────────────┘       └───────────────┘

┌───────────────┐       ┌───────────────┐
│  Impure Func  │──────▶│ Output depends │
│ (side-effects)│       │ on inputs +   │
│               │       │ external data │
└───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding VHDL functions basics

Concept: Learn what a function is in VHDL and how it returns a value.

In VHDL, a function is a block of code that takes inputs (called parameters) and returns a single output value. Functions help reuse code and make designs cleaner. For example: function add(a: integer; b: integer) return integer is begin return a + b; end function; This function adds two integers and returns the result.

Result

You can call add(2, 3) and get 5 as output.

Understanding that functions return values based on inputs is the foundation for distinguishing pure and impure functions.

2

Foundation

Side effects and determinism in functions

Concept: Introduce the idea that functions can or cannot change things outside themselves.

A function without side effects does not change any signals, variables, or states outside its own scope. It always returns the same output for the same inputs. A function with side effects might change signals or variables outside itself or depend on them, causing different outputs for the same inputs. Example of side effect: changing a global variable inside a function.

Result

Functions without side effects are predictable; those with side effects are not.

Knowing about side effects helps understand why pure functions are safer and impure functions can cause unexpected behavior.

3

Intermediate

Defining pure functions in VHDL

Concept: Learn the rules that make a function pure in VHDL.

In VHDL, a pure function must: - Depend only on its input parameters. - Not read or write any signals or variables outside itself. - Always return the same output for the same inputs. Example: function multiply(a: integer; b: integer) return integer is begin return a * b; end function; This is pure because it uses only inputs and no external data.

Result

Pure functions are deterministic and side-effect free.

Understanding these rules helps you write reliable and reusable VHDL functions.

4

Intermediate

Recognizing impure functions in VHDL

Concept: Understand what makes a function impure and when to use it.

An impure function in VHDL can: - Read signals or variables outside its inputs. - Depend on global states or time. - Possibly change external variables (though this is not allowed in VHDL functions). Example: impure function get_signal_value return std_logic is begin return some_signal; -- reading external signal end function; Impure functions are needed when you must access signals inside a function.

Result

Impure functions can produce different outputs for the same inputs.

Knowing when to use impure functions helps handle cases where external data is necessary.

5

Intermediate

Syntax difference: pure vs impure keyword

Concept: Learn how to declare pure and impure functions explicitly.

In VHDL, you declare a function as pure or impure using the keywords: pure function func_name(...) return type is begin -- body end function; impure function func_name(...) return type is begin -- body end function; If you omit the keyword, the function is pure by default. Use impure only when needed.

Result

The compiler knows how to treat the function based on this keyword.

Explicitly marking functions helps the compiler optimize and check your code.

6

Advanced

Implications for synthesis and simulation

🤔Before reading on: Do you think impure functions can always be synthesized to hardware like pure functions? Commit to your answer.

Concept: Understand how pure and impure functions affect hardware synthesis and simulation.

Pure functions are easier to synthesize because they behave like combinational logic: same inputs produce same outputs without side effects. Impure functions may depend on signals or states that change over time, making synthesis harder or impossible in some cases. During simulation, impure functions can model complex behaviors but may cause non-deterministic results. Therefore, prefer pure functions for synthesizable logic and use impure functions carefully.

Result

Pure functions map well to hardware; impure functions may not.

Knowing synthesis implications guides writing hardware-friendly VHDL code.

7

Expert

Subtle pitfalls with impure functions and caching

🤔Quick: Do you think the VHDL compiler caches impure function results like pure ones? Commit to yes or no.

Concept: Learn about compiler optimizations and how impure functions can cause unexpected behavior.

VHDL compilers may cache results of pure functions to optimize simulation speed, assuming same inputs yield same outputs. Impure functions disable this caching because outputs can change even with same inputs. If you mistakenly declare an impure function as pure, the compiler might cache wrong results, causing simulation errors. Also, impure functions can cause race conditions if they read signals changing during simulation delta cycles.

Result

Misdeclaring purity can cause subtle bugs and simulation mismatches.

Understanding compiler behavior prevents hard-to-find bugs in complex VHDL designs.

Under the Hood

VHDL functions are evaluated during simulation or synthesis by the tool. Pure functions are treated as mathematical mappings from inputs to outputs without side effects, allowing the tool to optimize by caching results or replacing calls with direct logic. Impure functions require the tool to evaluate them every time because their output may depend on external signals or states, preventing caching and optimization. During simulation, impure functions can read signals that change over time, so their output can vary even with same inputs.

Why designed this way?

The pure/impure distinction was introduced to help tools optimize simulation and synthesis. Pure functions guarantee deterministic behavior, enabling caching and simplification. Impure functions allow access to signals and states needed for complex modeling but at the cost of predictability. This design balances performance and flexibility, avoiding unsafe assumptions about function behavior.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Function    │──────▶│  Pure?        │──────▶│ Cache result  │
│   Call        │       │  (depends only │       │ (yes)         │
│               │       │   on inputs)   │       └───────────────┘
└───────────────┘       └───────────────┘
                             │
                             │No
                             ▼
                      ┌───────────────┐
                      │ Evaluate every│
                      │ time (no cache)│
                      └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think all VHDL functions are pure by default? Commit to yes or no.

Common Belief: All functions in VHDL are pure unless declared otherwise.

Reality: Functions are pure by default only if declared with the pure keyword or no keyword; however, if you use impure keyword, they are impure. Also, some tools treat functions without explicit purity as impure for safety.

Why it matters: Assuming all functions are pure can cause unexpected simulation behavior or synthesis errors if the function actually depends on signals.

Quick: Can an impure function change signals or variables outside itself? Commit to yes or no.

Common Belief: Impure functions can modify signals or variables outside their scope.

Reality: In VHDL, functions cannot modify signals or variables outside themselves; only procedures can. Impure functions can read external signals but cannot write them.

Why it matters: Believing impure functions can change signals leads to incorrect code design and confusion between functions and procedures.

Quick: Do you think impure functions are always bad and should be avoided? Commit to yes or no.

Common Belief: Impure functions are bad practice and should never be used.

Reality: Impure functions are necessary when you need to read signals or states inside a function, especially for modeling or complex calculations that depend on external data.

Why it matters: Avoiding impure functions blindly limits design flexibility and can force inefficient or complicated workarounds.

Quick: Do you think pure functions can access signals inside their body? Commit to yes or no.

Common Belief: Pure functions can read signals as long as they don't modify them.

Reality: Pure functions cannot read signals or variables outside their inputs; doing so makes them impure.

Why it matters: Misunderstanding this leads to incorrect purity declarations and simulation mismatches.

Expert Zone

1

Impure functions can cause simulation delta cycle sensitivity, meaning their output can change within the same simulation time step, which complicates timing analysis.

2

Some synthesis tools treat impure functions differently or may not support them fully, so knowing tool-specific behavior is crucial for production code.

3

Declaring a function pure when it is not can cause the compiler to cache stale results, leading to subtle bugs that are hard to trace.

When NOT to use

Avoid impure functions when writing synthesizable combinational logic; use pure functions instead. For sequential or state-dependent logic, use processes or procedures. If you need to modify signals, use procedures or processes, not functions.

Production Patterns

In production VHDL code, pure functions are used for arithmetic, logical calculations, and data transformations. Impure functions are used sparingly, mainly for reading signals inside functions for complex modeling or testbenches. Teams enforce purity rules to ensure code clarity and synthesis compatibility.

Connections

Mathematical functions

Pure VHDL functions behave like mathematical functions with no side effects.

Understanding pure functions as mathematical mappings helps grasp their deterministic nature and why they are preferred for hardware design.

Functional programming

Pure functions in VHDL share the same principles as pure functions in functional programming languages.

Knowing functional programming concepts clarifies why purity matters for predictability and optimization in hardware description.

Electrical engineering signal flow

Impure functions relate to signal-dependent behavior in circuits, similar to how signals influence hardware components.

Recognizing that impure functions model signal-dependent logic helps connect VHDL coding with real hardware behavior.

Common Pitfalls

#1 Declaring a function as pure but reading signals inside it.

Wrong approach:

pure function read_signal return std_logic is
begin
return some_signal; -- reading external signal
end function;

Correct approach:

impure function read_signal return std_logic is
begin
return some_signal; -- reading external signal
end function;

Root cause:

Misunderstanding purity rules and thinking reading signals is allowed in pure functions.

#2 Using impure functions for combinational logic that should be pure.

Wrong approach:

impure function add(a: integer; b: integer) return integer is
begin
return a + b;
end function;

Correct approach:

pure function add(a: integer; b: integer) return integer is
begin
return a + b;
end function;

Root cause:

Not recognizing that pure functions are better for deterministic combinational logic.

#3 Trying to modify signals inside a function.

Wrong approach:

function change_signal return std_logic is
begin
some_signal <= '1'; -- illegal in function
return some_signal;
end function;

Correct approach:

procedure change_signal is
begin
some_signal <= '1'; -- allowed in procedure
end procedure;

Root cause:

Confusing functions with procedures and misunderstanding VHDL rules about signal assignments.

Key Takeaways

Pure functions in VHDL always produce the same output for the same inputs and do not read or modify signals outside their parameters.

Impure functions can read signals or variables outside their inputs, making their output potentially variable even with the same inputs.

Declaring functions correctly as pure or impure helps the compiler optimize simulation and synthesis and prevents subtle bugs.

Functions cannot modify signals or variables outside themselves; only procedures can perform such assignments.

Using pure functions for combinational logic ensures predictable, synthesizable, and maintainable VHDL code.

Practice

1. Which statement best describes a pure function in VHDL?

easy

A. It always returns the same output for the same inputs and does not modify any external signals.

B. It can modify signals outside its scope and may return different outputs for the same inputs.

C. It only reads external signals but does not modify them.

D. It is a function that uses variables inside a process.

Solution

1. Step 1: Understand pure function behavior

   A pure function in VHDL must always return the same result for the same inputs and cannot change any external signals or variables.

2. Step 2: Compare options with definition

   It always returns the same output for the same inputs and does not modify any external signals. matches this definition exactly, while others describe impure or unrelated behaviors.

3. Final Answer:

   It always returns the same output for the same inputs and does not modify any external signals. -> Option A

4. Quick Check:

   Pure function = consistent output, no side effects [OK]

Hint: Pure means no side effects and consistent output [OK]

Common Mistakes:

• Confusing pure with impure functions
• Thinking pure functions can modify signals
• Assuming pure functions can read external signals

2. Which of the following is the correct way to declare a pure function in VHDL?

easy

A. procedure add(a: in integer; b: in integer);

B. function add(a: integer; b: integer) return integer is pure;

C. function add(a: integer; b: integer) return integer is impure;

D. function add(a: integer; b: integer) return integer;

Solution

1. Step 1: Recall VHDL function declaration syntax

   In VHDL, to declare a pure function explicitly, you add the keyword pure after the function signature.

2. Step 2: Identify correct syntax

   function add(a: integer; b: integer) return integer is pure; correctly uses is pure; to declare a pure function. The procedure declaration is not a function, function add(a: integer; b: integer) return integer is impure; declares an impure function, and function add(a: integer; b: integer) return integer; lacks purity specification.

3. Final Answer:

   function add(a: integer; b: integer) return integer is pure; -> Option B

4. Quick Check:

   Pure function declaration includes 'is pure;' [OK]

Hint: Pure functions use 'is pure;' in declaration [OK]

Common Mistakes:

• Omitting 'pure' keyword for pure functions
• Confusing procedures with functions
• Using 'impure' when pure is needed

3. Consider this VHDL function:

function get_value(x: integer) return integer is
  variable count: integer := 0;
begin
  count := count + 1;
  return x + count;
end function;

What is true about this function?

medium

A. It is impure because it uses a variable that changes each call.

B. It is impure because it modifies an external signal.

C. It is impure because it uses variables inside a function.

D. It is a pure function because it returns a value based on input only.

Solution

1. Step 1: Analyze variable usage inside function

   The local variable count is initialized to 0 each time the function is called, incremented to 1, and x + count always returns x + 1 for the same x.

2. Step 2: Determine purity based on output consistency

   Same inputs always produce the same output with no external modifications, making it pure. The claim about a changing variable ignores reinitialization, using variables inside is allowed, and there are no external signals.

3. Final Answer:

   It is a pure function because it returns a value based on input only. -> Option D

4. Quick Check:

   Local variables reinitialized each call = pure [OK]

Hint: Local variables reset each call, pure function [OK]

Common Mistakes:

• Thinking local variables make function impure
• Confusing external signals with local variables
• Believing the function output changes across calls

4. This VHDL function is intended to be pure:

function multiply(a: integer; b: integer) return integer is pure;
begin
  result := a * b;
  return result;
end function;

What is the error in this code?

medium

A. The function cannot have parameters.

B. The function should be declared impure because it modifies result.

C. The function uses an undeclared variable result.

D. The function lacks a return statement.

Solution

1. Step 1: Check variable declarations inside function

   The function uses result without declaring it as a variable or signal inside the function.

2. Step 2: Understand VHDL variable scope rules

   All variables must be declared before use. Since result is undeclared, this causes a compilation error.

3. Final Answer:

   The function uses an undeclared variable result. -> Option C

4. Quick Check:

   All variables must be declared before use [OK]

Hint: Declare all variables before using them [OK]

Common Mistakes:

• Assuming implicit variable declaration
• Confusing pure/impure with variable declaration errors
• Ignoring missing return statements

5. You want to create a function in VHDL that returns the current value of a global signal clk_count and increments it each call. Which is true about this function?

hard

A. It must be declared impure because it reads and modifies external signals.

B. It can be pure if it only returns the value without incrementing.

C. It can be pure if it uses a local variable to track increments.

D. It must be a procedure, not a function.

Solution

1. Step 1: Understand function interaction with external signals

   Reading and modifying a global signal clk_count means the function has side effects and depends on external state.

2. Step 2: Determine purity based on side effects

   Because the function changes external data, it cannot be pure and must be declared impure.

3. Final Answer:

   It must be declared impure because it reads and modifies external signals. -> Option A

4. Quick Check:

   Modifying external signals means impure function [OK]

Hint: Modifying external signals requires impure functions [OK]

Common Mistakes:

• Thinking local variables can replace external signal changes
• Assuming functions can modify signals without impure keyword
• Confusing functions with procedures for side effects