Function and procedure in packages in VHDL - Deep Dive

Overview - Function and procedure in packages

What is it?

In VHDL, functions and procedures are reusable blocks of code that perform specific tasks. They can be grouped inside packages, which are containers that hold related declarations and definitions. Functions return a value and are used in expressions, while procedures perform actions but do not return a value. Using packages helps organize code and share these blocks across multiple designs.

Why it matters

Without functions and procedures in packages, VHDL code would be repetitive and harder to maintain. Designers would have to rewrite common logic many times, increasing errors and slowing development. Packages allow sharing and reusing code efficiently, making designs cleaner and easier to understand. This improves productivity and reduces bugs in hardware design.

Where it fits

Before learning this, you should understand basic VHDL syntax, data types, and how to write simple processes. After this, you can learn about package bodies, generics, and advanced design reuse techniques like component instantiation and configurations.

Mental Model

Core Idea

Functions and procedures inside packages are like reusable tools stored in a toolbox that you can use anytime in your VHDL design to perform tasks or calculations.

Think of it like...

Imagine a kitchen drawer where you keep different utensils: a knife to cut (function returning a value), and a spoon to stir (procedure doing an action). The drawer (package) keeps them organized and easy to find whenever you cook (write your design).

┌───────────────┐
│   Package     │
│ ┌───────────┐ │
│ │ Function  │ │  <-- Returns a value
│ └───────────┘ │
│ ┌───────────┐ │
│ │ Procedure │ │  <-- Performs actions
│ └───────────┘ │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding VHDL Packages

Concept: Packages group related declarations like types, constants, functions, and procedures for reuse.

A package in VHDL is a container where you declare reusable elements. For example, you can declare a function or procedure prototype inside a package. This package can then be used in multiple design units by including it with a 'use' clause.

Result

You can organize your code better and reuse declarations across different parts of your design.

Knowing that packages act as containers helps you avoid repeating code and keeps your design modular.

2

Foundation

Difference Between Functions and Procedures

Concept: Functions return a value and can be used in expressions; procedures perform actions but do not return values.

Functions have a return type and must return a value. They are called inside expressions. Procedures do not return values but can modify parameters and perform sequences of statements. Both can be declared inside packages.

Result

You understand when to use a function (for calculations) and when to use a procedure (for actions).

Recognizing the difference guides you to write clearer and more appropriate reusable code blocks.

3

Intermediate

Declaring Functions Inside Packages

🤔Before reading on: do you think a function in a package can access signals directly or only parameters? Commit to your answer.

Concept: Functions inside packages are declared with input parameters and a return type, but they cannot access signals directly.

Inside a package, you declare a function with its name, parameters, and return type. The function body is usually placed in the package body. Functions can only use their parameters and local variables, not signals from outside.

Result

You can write reusable calculation blocks that work only with inputs and produce outputs.

Understanding that functions are pure and side-effect free helps avoid design errors and makes code predictable.

4

Intermediate

Declaring Procedures Inside Packages

🤔Before reading on: do you think procedures can modify their parameters? Commit to your answer.

Concept: Procedures can have input, output, and inout parameters and can perform actions that modify these parameters.

Procedures are declared with parameters that can be input, output, or both. They do not return values but can change the values of output or inout parameters. The procedure body is placed in the package body.

Result

You can write reusable action blocks that modify data passed to them.

Knowing how procedures handle parameters allows you to design flexible and efficient code for complex operations.

5

Intermediate

Using Packages with Functions and Procedures

Concept: You include packages in your design units to use their functions and procedures by referencing them with the 'use' clause.

To use functions or procedures from a package, you add 'library' and 'use' statements in your design. Then you can call the functions or procedures by name. This promotes code reuse and cleaner designs.

Result

Your design can call shared functions and procedures, reducing duplication.

Understanding package usage enables modular design and easier maintenance.

6

Advanced

Package Body for Function and Procedure Definitions

🤔Before reading on: do you think function and procedure bodies can be inside the package declaration? Commit to your answer.

Concept: The package body contains the actual code (implementation) of functions and procedures declared in the package header.

The package declaration lists the function and procedure interfaces. The package body provides the detailed code. This separation allows multiple design units to share the same interface but keeps implementation hidden.

Result

You can separate interface from implementation, improving encapsulation.

Knowing this separation helps manage large designs and supports incremental compilation.

7

Expert

Limitations and Best Practices for Functions in Packages

🤔Before reading on: do you think functions in packages can have side effects like changing signals? Commit to your answer.

Concept: Functions in packages should be pure (no side effects) and fast; procedures are used for actions with side effects. Overusing functions with side effects can cause simulation and synthesis issues.

Functions must not modify signals or variables outside their scope. Procedures can modify parameters but should be used carefully. Using pure functions improves simulation speed and synthesis clarity. Also, recursive functions are allowed but can be tricky.

Result

You write safer, more predictable code that synthesizes well.

Understanding purity and side effects in functions prevents subtle bugs and synthesis mismatches.

Under the Hood

When VHDL code is compiled, packages are processed to create a shared library of declarations and definitions. Functions and procedures inside packages are compiled into reusable blocks. Functions are called with parameters and return values immediately, while procedures execute sequences of statements possibly modifying parameters. The separation of package declaration and body allows the compiler to check interfaces before implementation, enabling modular compilation.

Why designed this way?

VHDL was designed to model hardware with clarity and reuse. Separating declarations (package) from implementations (package body) allows multiple designers to share interfaces without exposing internals. Functions are pure to reflect combinational logic, while procedures allow modeling sequential or stateful behavior. This design balances clarity, reuse, and hardware synthesis constraints.

┌───────────────┐       ┌───────────────────┐
│ Package       │       │ Package Body      │
│ ┌───────────┐ │       │ ┌───────────────┐ │
│ │ Interface │ │──────▶│ │ Implementation│ │
│ └───────────┘ │       │ │ Functions &   │ │
│               │       │ │ Procedures    │ │
└───────────────┘       └───────────────────┘
        ▲                         ▲
        │                         │
        │                         │
   Design Units              Compiler
   (use package)             compiles both

Myth Busters - 4 Common Misconceptions

Quick: Can a function inside a package modify a signal outside its scope? Commit yes or no.

Common Belief: Functions can modify signals or variables outside their parameters just like procedures.

Reality: Functions cannot modify signals or variables outside their parameters; they must be pure and side-effect free.

Why it matters: Assuming functions can change signals leads to simulation mismatches and synthesis errors, causing hardware to behave unpredictably.

Quick: Do procedures return values like functions? Commit yes or no.

Common Belief: Procedures return values just like functions but in a different way.

Reality: Procedures do not return values; they only modify parameters passed by reference.

Why it matters: Confusing procedures with functions can cause design errors and misuse of these constructs, leading to incorrect hardware behavior.

Quick: Can you put the full code of functions inside the package declaration? Commit yes or no.

Common Belief: You can write the full function or procedure code inside the package declaration.

Reality: The package declaration only contains interfaces; the full code must be in the package body.

Why it matters: Putting code in the declaration causes compilation errors and breaks modular design principles.

Quick: Are recursive functions commonly used and safe in VHDL? Commit yes or no.

Common Belief: Recursive functions are commonly used and always safe in VHDL designs.

Reality: Recursive functions are allowed but rarely used because they can cause synthesis problems and complex simulation behavior.

Why it matters: Using recursion without care can lead to hardware that is hard to synthesize or simulate correctly.

Expert Zone

1

Functions in packages should be deterministic and free of side effects to ensure consistent simulation and synthesis results.

2

Procedures can be overloaded in packages, allowing multiple versions with different parameter lists, which helps create flexible APIs.

3

The separation of package declaration and body supports incremental compilation and better dependency management in large projects.

When NOT to use

Avoid using functions with side effects or complex state changes; instead, use procedures or processes. For very complex behavior, consider using entities or architectures. Also, do not use recursive functions in synthesis-critical code.

Production Patterns

In real-world designs, packages hold utility functions like math operations, bit manipulations, or protocol helpers. Procedures often implement common sequences like reset logic or data formatting. Overloading and generics in packages enable highly reusable and configurable code libraries.

Connections

Modular Programming

Functions and procedures in packages are a form of modular programming in hardware description languages.

Understanding modular programming concepts from software helps grasp why VHDL uses packages to organize reusable code blocks.

Software Libraries

VHDL packages are similar to software libraries that group reusable functions and procedures.

Knowing how software libraries work clarifies the purpose of packages as shared code containers in hardware design.

Mathematical Functions

VHDL functions resemble mathematical functions: they take inputs and produce outputs without side effects.

Recognizing this connection helps understand why VHDL functions must be pure and deterministic.

Common Pitfalls

#1 Trying to modify a signal inside a function in a package.

Wrong approach:

function increment_signal return integer is
begin
signal_value <= signal_value + 1; -- illegal inside function
return signal_value;
end function;

Correct approach:

function increment_value(input_val : integer) return integer is
begin
return input_val + 1;
end function;

Root cause:

Misunderstanding that functions cannot have side effects or access signals directly.

#2 Defining the full function body inside the package declaration.

Wrong approach:

package my_pkg is
function add(a, b : integer) return integer is
begin
return a + b;
end function;
end package;

Correct approach:

package my_pkg is
function add(a, b : integer) return integer;
end package;

package body my_pkg is
function add(a, b : integer) return integer is
begin
return a + b;
end function;
end package body;

Root cause:

Confusing package declaration with package body roles.

#3 Using a procedure when a function is needed to return a value.

Wrong approach:

procedure get_sum(a, b : integer; result : out integer) is
begin
result := a + b;
end procedure;
-- called as get_sum(2,3,sum); but sum cannot be used in expressions directly

Correct approach:

function get_sum(a, b : integer) return integer is
begin
return a + b;
end function;
-- called as sum := get_sum(2,3);

Root cause:

Not understanding the difference between functions and procedures in returning values.

Key Takeaways

Functions and procedures inside packages help organize and reuse VHDL code efficiently.

Functions return values and must be pure, while procedures perform actions and can modify parameters.

Packages separate interface (declaration) from implementation (body) to support modular design.

Misusing functions or procedures can cause simulation and synthesis errors, so understanding their roles is crucial.

Expert use includes overloading, generics, and careful management of side effects for robust hardware design.

Practice

1. What is the main difference between a function and a procedure in a VHDL package?

easy

A. A procedure returns a value, while a function does not.

B. A function returns a value, while a procedure does not.

C. Both return values but differ in syntax.

D. Neither returns a value; both perform actions only.

Solution

1. Step 1: Understand function behavior

   A function in VHDL always returns a value and can be used in expressions.

2. Step 2: Understand procedure behavior

   A procedure performs actions but does not return a value directly.

3. Final Answer:

   A function returns a value, while a procedure does not. -> Option B

4. Quick Check:

   Function returns value = B [OK]

Hint: Functions return values; procedures do not [OK]

Common Mistakes:

• Thinking procedures return values
• Confusing syntax differences with return behavior
• Assuming both can be used in expressions

2. Which of the following is the correct way to declare a function inside a VHDL package?

easy

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

B. procedure add(a : integer; b : integer) return integer;

C. function add(a, b : integer);

D. procedure add(a : integer; b : integer);

Solution

1. Step 1: Check function declaration syntax

   A function must specify parameters with types and a return type using return.

2. Step 2: Validate options

   function add(a : integer; b : integer) return integer; correctly declares a function with parameters and return type. Options A and B are procedures, and C misses return type.

3. Final Answer:

   function add(a : integer; b : integer) return integer; -> Option A

4. Quick Check:

   Function declaration needs return type = D [OK]

Hint: Functions must declare return type explicitly [OK]

Common Mistakes:

• Using 'procedure' keyword for functions
• Omitting return type in function declaration
• Adding return type to procedures

3. Given the following package body code, what is the output of calling result := math_pkg.multiply(3, 4);?

package body math_pkg is
  function multiply(x : integer; y : integer) return integer is
  begin
    return x * y;
  end multiply;
end math_pkg;

medium

A. 12

B. 7

C. Error: function not found

D. 0

Solution

1. Step 1: Understand function multiply

   The function returns the product of x and y, so multiply(3,4) returns 3*4 = 12.

2. Step 2: Confirm no errors

   The function is correctly declared and defined in the package body, so no errors occur.

3. Final Answer:

   12 -> Option A

4. Quick Check:

   3 * 4 = 12 [OK]

Hint: Multiply returns product of inputs [OK]

Common Mistakes:

• Confusing addition with multiplication
• Assuming function is undefined
• Expecting procedure behavior

4. Identify the error in this package declaration:

package util_pkg is
  procedure display_message(msg : in string);
  function get_length(msg : string) return integer;
end util_pkg;

medium

A. Package missing body keyword.

B. Procedure missing return type.

C. Function parameter missing mode (in/out).

D. Procedure parameter mode is incorrect.

Solution

1. Step 1: Check procedure parameter modes

   Procedure parameters must specify mode (in, out, inout). The procedure parameter msg correctly uses in.

2. Step 2: Check function parameter modes

   Function parameters must also specify mode explicitly. The function parameter msg : string lacks mode, which is required.

3. Final Answer:

   Function parameter missing mode (in/out). -> Option C

4. Quick Check:

   Function parameters need mode = A [OK]

Hint: Always specify parameter mode in functions and procedures [OK]

Common Mistakes:

• Omitting parameter mode in functions
• Confusing package and package body syntax
• Thinking procedures need return types

5. You want to create a VHDL package that includes a function to calculate the factorial of a number and a procedure to print the result. Which of the following is the best approach?

hard

A. Define factorial as a procedure modifying a global variable; print as a function returning string.

B. Define both factorial and print as functions returning integer.

C. Define factorial as a procedure returning integer; print as a procedure with no parameters.

D. Define the factorial as a function returning integer; define the print as a procedure taking integer input.

Solution

1. Step 1: Choose correct return types

   Factorial calculation returns a value, so it should be a function returning integer.

2. Step 2: Choose correct procedure for printing

   Printing is an action without return value, so it should be a procedure taking the integer to print.

3. Final Answer:

   Define the factorial as a function returning integer; define the print as a procedure taking integer input. -> Option D

4. Quick Check:

   Function returns value; procedure performs action = C [OK]

Hint: Use function for calculations, procedure for actions [OK]

Common Mistakes:

• Using procedures to return values
• Defining print as function with return value
• Not passing parameters to procedures