Using Forth as a VHDL ( Virtual Hardware Definition Language )
John R. Hart, Testra Corporation


    A set of VHDL extensions to Forth lets programers define hardware in the same language they write software in. Hardware defined in Forth, can be verified by executing the hardware definition words at the command line or by writing special Forth words to test their operation. The use of the same language for hardware and software simplifies the task of swapping hardware and software functions during optimization.


    Computer aided design has become an essential part of product development and there are several different VHDLs being marketed for that purpose, but I wanted the luxury of being able to work on hardware and software in a uniform environment.

    We have been using Forth to define PAL equations for about ten years. The PALs are compiled using a set of extensions to Forth called CARMAP. As programable logic devices grew in complexity, it always seamed easier to modify or add to the CARMAP extensions than to buy an off the shelf compiler, and learn a new language.

    We had been using Forth simulate hardware for years, and with each improvement CARMAP moved closer to being a complete high level design system. In order to work with the large PLDs, a set of special global variable words, and a program to fit the design into the PLD, were added to CARMAP.

    When the upgrade to CARMAP was complete, the compiler could automatically reduce the virtual description used to simulate hardware, into logical pieces, and fit them into the macrocells of the PLD.

Why use Forth to simulate hardware?

1. A software model can be completed much faster than hardware.
2 Application code can be tested before the hardware is designed.
3. It is easy to display or modify internal states.
4. Diagnostic macros can be easily implemented.
5. Resources can be optimized early in the design.

Why use Forth as a VHDL?

1. To reduce the time needed to create the system.
2. So Forth can be the hardware description language.
2. So the project can use one uniform language.
3. To support the extensibility of the design.
4. To enable interactive hardware design.

Designing logic with the Forth VHDL

1. Write a software simulation of the design.
2. Test the design.
3. Convert the software simulation into a hardware definition.
4. Compile the hardware definition into logic equations.
5. Fit the logic equations into the device.
6. Verify that the logic equations work correctly.
7. Route the signals and assign the I/O pins.
8. Convert the routed design into a fusemap.


    The simulation of a design allows the interactive analysis of many aspects of the hardware including complexity, functionally, timing, and performance. If the application program for the proposed hardware is also written in the same language as the hardware, hard and soft components can be interchanged during optimization.

The software model

    The software model is like a black box, it doesn't matter how it works as long as it works correctly. The main advantage of the software model is that structural details of the PLD can be ignored as ideas are evaluated early in the design stage.

The hardware definition

    After the software model has been evaluated, the design is turned into a hardware definition. The hardware definition is an expanded version of the software model. Programs will run a little slower on it, but they should function the same.

    For a design to match up with the device structure it must be partitioned correctly. Partitioning is an intuitive process that is difficult to automate, so information relating to hardware structure needs to be included in the definition.

    The conversion to the hardware definition involves breaking complex functions up into smaller parts that will fit in a single layer of logic. A library of words to expand complex functions could be easily built to aid in this task. Global variables must be created for the output nodes of all the logic blocks, and procedures must be written that will function the same as the components would behave.

    The inputs and outputs of the procedures are passed via the global variables that hold the state of the model. These variables have three parts, the first holds the present state, the second holds the future state and the third holds the don't-care flags. The global variables also contain information about register clocking and propagation delays.

Verification of the model:

    Debugging the simulation of a design will require a set of tools that are "tuned" to the characteristics of the design. In a non-extensible language this might be done using some form of macros, but when debugging a simulation in Forth a lot of the tools exist before the job is even started. Simple things can be interactively tested by keying in and running short programs.

    The simulation process involves executing all of the simulation procedures, and then copping all of the future states into the present state. The relationship of timing and propagation is established by the order the state of the global variables are changed.

Things to considered when creating the hardware model:

1. Truth table size. The size of a truth table is 2^n where n is the number of inputs. A function with more than 20 inputs will take a long time to compile, and it should probably be factored to reduce the number of inputs.

2. Input relationships. The inputs needed for an output can be specified to reduce truth table size.

3. Specify don't-care terms. In many cases there are places in a function table that are not used. If the unused space is flagged as don't-care, a simpler solutions with a reduced number of terms may be possible.

How the logic compiler works (CARMAP)

    The logic compiler converts each of the functions described in Forth into a set of logic equations for each output bit of the function. This is conceptually a simple process that involves expanding the function into a truth table and then reducing the number of terms in the truth table to the minimum.

    The function is mapped into the truth table using only the inputs that are related to the output. After the function has been mapped, the table is scanned for unused inputs. If any unused inputs are found they are removed from the table. Each input that is removed cuts the table size by half.

    The truth table is then converted into logic equations by an exhaustive scanning process that tries all possible combinations of inputs and compares them with the truth table. The first step is to search the table for a true output. When an output is found all sets it resides in are tested for correlation with the other outputs. The largest true set is saved and the bits within it are marked as solved. then the next unsolved output is found and the process repeats until finished.

    The second step of the transformation is to delete the sets in which all elements have more than one solved mark. This gives something close to the ideal two level array.

    The third step is to convert this ideal array into a multi-level array to match gate loading to the fabrication technology. This is accomplished by recursively factoring gates from the sets and oring them together.

CARMAP Word Set:

Variables: (Items)


I/O Definitions:

    IO-GROUP "name"
    INPUT "name" [START ( n -- )] [BITS ( n -- )]
    OUTPUT "name" [CLOCK "name"] [BITS ( n -- ) ] [XORS ( n -- )]
    USES ( m -- ) "name"

    A bit mask that defines what bits are used by an output. A counter is a function where each output bit depends on all of the bits less than it. The USES mask is rotated to the position of the current output bit. The upper bits in the mask are rotated into the lower bits so they will be used in counting functions.

    USEX ( m -- ) "name"

    A bit mask that defines what bits should be tried in an XOR function.

    SELECT ( m -- ) "name"

    A bit mask that defines a set of bits in a fixed position that are used as a selector. The SELECT mask does not rotate.


    CLKMAC ( n io-group_ads -- ) "name" FORGET "io-group_name"

    IOMAC ( n io-group_ads -- ) "name" FORGET "io-group_name"

    IMAC ( n io-group_ads -- ) "name" FORGET "io-group_name"



    MAP[ ( v -- ) n

    MAP ( v a -- )

    ]MAP ( a -- )

    ]: ( -- a )


    >> ( d -- ) "label"

    >>O ( d -- ) "label"

    >>X ( d -- ) "label"

    TRUTH-TABLE: ( io-group_ads -- ) "simulation_word"


    Forth provides a good foundation for a VHDL system because Forth is an extensible virtual interpreter. Most everyone who works with Forth knows it's unique features can enhance software productivity. My experience has shown it to be very useful when working with variable hardware as well.

    The Forth inner interpreter is a very simple list processor that requires only three pointers, two registers and an ALU to run efficiently. Because of Forth's simple structure, a software model can be completed very quickly, and it is easy to adapt it to changes in the instruction set as the design matures.

    People who work with Forth have long known that it is a good application language, our experience has shown us that it's advantages also apply when it used as a VHDL.


VHDL and Verilog fundamentals- expressions, operands and operators.
Douglas J Smith, EDN, 4/10/1997

VHDL & Verilog Syntax & Semantics Handbook.
Johan Sandstrom, Integrated System Design Magazine, Jan 1996

Vhsic Hardware Description Language.
Steven H. Leibson, EDN, 3/16/1989

Getting a handle on HDLs.
Brian Dipert, EDN, 5/7/1998

Adopting VHDL for PLD design and simulation.
Troy Scott, EDN, 4/9/1998

Hug an XOR gate today: An introduction to Reed-Muller Logic.
Clive "Max" Maxfield, EDN, 3/1/1996


1. The extendable Forth core, makes it easy to accommodate extensions to the hardware.
2. One uniform language "Forth" needs to be compatible with the tools that compile, verify and test the design.
3. A virtual model, makes it possible to simulate, test and optimize a design, early in the development cycle.


1. A FIG membership offer that would contain the Forth VHDL along with a demo Forth processor that could be used in the customers product for a small royalty.

2. Part of the membership fee would go to pay for customer support during the trial period.

3. The goal is to have this processor run at two to five MIPS and fit in a low cost PLD. ($3-15$) along with, room for some additional logic.


1. Some of the competing VHDL systems allow "C" to be used in the design process.
2. Universal VHDL systems are expensive.
3. Many PLD manufactures provide simple low cost systems for their parts.
4. By using a standard format for the output files, other tools, such as schematic capture could be used.
5. A Forth VHDL system including, a demo Forth processor implemented in a standard PLD, could be distributed. As this system would be written in Forth the customer would have to learn Forth.

    The logic for the processor is arrived at by building a table that maps the output for all possible input combinations of each section, and then transforming those tables a into a set of gates.

    The first step of this process is to factor the design into parts that are small enough to be mapped into a reasonable amount of memory. Each part is described using a simple program that fills the table with the bit map describing it's behavior.

6. Forth as a simulator to test the viability of the instruction set. The hardware simulator has four main parts:

the inner interpreter to fetch the instructions,
the field extractor to get the operands,
the case statements to branch to the execution modules and,
the data space translators.

7. Forth is used as a compiler for the new processor.

If you have comments or suggestions, email us at
Testra Corporation   1201 N. Stadem Drive  Tempe, AZ 85281  Ph. 480-895-8439  Fax: 480-895-3589