Hardware-software interface design

Shared variables between hardware and software

ASICs are building blocks of larger systems. Typically, the operation of the ASIC in the system is controlled by a host microprocessor. Consequently, most ASICs contain a microprocessor interface. Through this interface, the host microprocessor can access a number of variables in the ASIC. These variables are physically implemented in hardware registers, but are logically shared between the hardware and software. This means that both the software and the hardware can access these variables. Therefore, these shared variables constitute the hardware-software interface of the ASIC.

Hardware-software communication mechanisms

The host software and the ASIC hardware can exchange information through a variety of communication mechanisms . For example:

• The software can configure the ASIC by writing into configuration registers.
• The software can obtain information about ASIC operation by reading status and counter registers.
• The ASIC can notify the software about certain events by setting bits in interrupt registers.

Variable access mechanisms

The software can access the shared variables using a variety of access mechanisms . Frequently used access mechanisms include the following:

• Read-write access (for example, for configuration variables)
• Read-only access (for example, for status variables)
• Variables that are automatically cleared by the hardware on a software read (often used for counter variables)
• Bits that are set by the hardware and cleared by the software (for example, for interrupt bits and semaphores)

By choosing the appropriate access mechanism for a variable, the hardware-software communication can be facilitated.

The memory map

The shared variables in the hardware-software interface are typically specified by a memory map in the ASIC specification. A memory map is a tabular representation. A memory map can grow to a considerable size. The following figure shows a small extract from an example memory map:

In a memory map, the allocation of variables to address and bit field locations is specified explicitly. These allocations are performed by the specification engineer.

The memory map methodology

The memory map serves as a specification for both the software and the hardware team.

For both hardware and software designers, it is good practice to use the names of the variables instead of hard-coding addresses and bit fields in their application code. Application code which refers to variable names is much clearer and much less sensitive to changes than code containing hard-coded numbers.

Typically, a software engineer will encapsulate the mappings from names to addresses in a C header file, and a VHDL hardware engineer will encapsulate them in a VHDL package. Header files and packages may also contain supporting functions that implement the access mechanism of a variable.

Problems with the memory map methodology

Today's system-on-chip ASICs pose new design challenges. It is not uncommon to see ASIC specs in which the memory map occupies more than 50 pages with hundreds of variables. The memory map methodology is not well suited for hardware-software interface design of such complexity.

The difficulties of the memory map methodology are discussed in more detail below.

A flat, low-level representation of the shared variables

Conceptually, the hardware-software interface is likely to contain functional hierarchy: some variables belong together, like members of a structure or an array. However, there is no way to express such a functional hierarchy in a memory map.

Likewise, the hardware-software interface variables conceptually have abstract types like integers, booleans and enumerated types, but in the memory map these are all coerced into a bit-level representation.

The memory map is a flat, low-level representation which fails to take advantage of the abstractions in the hardware-software interface.

Manual address allocation

The allocation of variables to addresses in the memory map is done manually by the specification engineer.

This is not a trivial task. For efficient hardware decoding, it can be advantageous to leave gaps in the memory map between groups of related variables, so that address ranges are powers of 2. On the other hand, address locations should not be wasted unnecessarily. These are conflicting requirements, and it is hard to meet and maintain them manually.

Moreover, the specification engineer will tend to group variables together (or even put them at the same address location) according to his conceptual understanding of the device. However, this grouping may not coincide with the optimal allocation of variables to sub-components in the architecture. This may cause major problems with the implementation.

Manual development of VHDL packages and C header files for the address map

Although the memory map fully specifies the mapping from variable names to addresses, the development of C header files and VHDL packages for this specification is typically a manual task.

Moreover, as these developments are commonly done by different engineers in different development teams, there is a problem of guaranteeing, verifying and maintaining consistency.

Management of engineering changes

As shown above, the memory map methodology implies many manual tasks. Going through all these tasks once is difficult enough, but managing engineering changes can become an engineering nightmare. Unfortunately, real projects inevitably see a large amount of such engineering changes.

The VCI Compiler methodology

VCI Compiler is a tool that supports a design methodology that overcomes the problems of the memory map methodology.

VCI Compiler starts from a high-level model of the hardware-software interface variables, and automates the interface design process all the way down to the software and hardware APIs.

The features of VCI Compiler are discussed in more detail below.

A high-level model of the hardware-software interface

The input to VCI Compiler is the declaration of the shared variables. The variables are declared using high-level types, such as integers, booleans, and enumerated types. They can be hierarchically grouped into records (similar to C structures), and records can be grouped into tables (similar to C arrays).

Record and table variables can be allocated to a Virtual Component (VC). The concept of a VC enables design reuse of chip components with their own hardware-software interface. There can be any number of VC declarations. The VC declarations specify the device architecture and the variable allocations at a high level.

Automated optimal address allocation

VCI Compiler fully automates the address allocation task. It does this in a clever way by using specialized allocation algorithms. The compiled address allocation results in fast and small decoding hardware, but at the same time minimizes the used address range.

Generation of VHDL packages and C header files for the address map

VCI Compiler generates C header files and VHDL packages for the address map. These files hide the address allocation details from the hardware and software designers. The designers can simply import them in their application code and write application code symbolically, by referring to the names of the shared variables. In addition, the VHDL packages contain supporting subprograms, that implement the variable access mechanisms.

Fast and easy engineering changes

As the input of VCI Compiler is a single high-level file, it is easy to make engineering changes. It is equally easy to automatically and consistently propagate the impact of changes into the hardware and the software design, by merely running the tool again.

Moreover, the output of VCI Compiler is structured in such a way that the impact of subsequent runs on application code is minimized. The generated code is encapsulated in C header files and VHDL packages. Existing application code will typically continue to work unmodified (except, of course, when the declaration of a variable has been deleted.)

The VCI Compiler design flow

The productivity gains from the use of VCI Compiler can be enormous. Moreover, they can be achieved without major investments: it is actually very easy to integrate the tool into a VHDL-based ASIC design flow. This has been a crucial design option and is largely influenced by Easics' experience as an ASIC design services company.

VCI Compiler is designed to work in a VHDL design context on the hardware side, and a C/C++ design context on the software side. The generated VHDL is fully compliant with the VHDL standard and is compliant with the Synopsys synthesis subset. The generated C is compliant with the gnu C compiler.

The use of the VCI Compiler methodology facilitates verification. Easics has developed a generic VCI bus driver model which couples a VHDL simulator to a software process via standard Unix pipes. This model uses the C interface of the VHDL simulator. In effect, this technique turns a standard VHDL simulator into a full-featured hardware-software cosimulation environment.

 

Modeling test benches in software languages such as C++ or python is both more powerful and meaningful than modeling them in VHDL. A software test bench can even contain application code as it will run in the system.