Turbocharge your soft designs

Moving to an FPGA-based, soft-centric approach to design offers loads of advantages for creating today’s innovative and connected products. One of the less obvious ones is boosting the performance of your design using hardware acceleration – moving software algorithms and functions into hardware.

It’s another powerful feature built into Altium Designer that makes the most out of the potential of FPGAs. Along with simply boosting throughput, the advantage can be used to down-spec the processor (and possibly FPGA) and exploit the associated cost savings. It all comes down to the software algorithms you’re using and what you ultimately decide will deliver the best design outcome. Because Altium Designer effectively lets you move functions in and out of hardware at will, the performance gains (or losses) can be assessed empirically, and in real time.

Hardware acceleration

In many processor systems, the embedded processor has to handle computationally-intensive algorithms. These algorithms place a significant load on the processor, which can compromise the design’s performance.

The result is you need to move to a higher spec processor or different FPGA device (with the associated redesign) in order to meet design performance goals. But the performance of this type of design can be significantly enhanced if these algorithms are moved to hardware, as circuits in the FPGA fabric itself, and that's where Altium Designer's C-to-Hardware (CHC) technology comes in...

Many computational algorithms that are straightforward to code and debug in software are inherently parallel in nature. Encryption algorithms, image manipulation and signal processing are just some examples. As pure software entities, these functions place heavy demands on the processor.

However, FPGA devices are also parallel by nature, offering the ability to perform multiple operations simultaneously. To move computationally-intensive functions out of the software domain and into the hardware realm – through the use of C-to-Hardware compilation technology – not only eases the burden on the processor, but can also give your design a substantial boost in the speed department.

In Altium Designer, hardware acceleration is made possible using the C-to-Hardware Compiler (CHC), which takes standard untimed ISO-C source code and produces a synthesizable hardware file (RTL). This RTL description is translated into FPGA hardware that implements the required function. A 'soft' processor in the FPGA design accesses these hardware functions through use of an Application-Specific Processor (ASP).

The Application Specific Processor

Altium Designer's ASP peripheral component is essentially used as a 'container' for C source functions that are implemented in hardware through use of the CHC technology.

The ASP peripheral, wired into an FPGA design just like any other component, enables a host processor to access and 'communicate' with the hardware-compiled functions within it. The functions themselves populate the ASP once the design project has been compiled and synthesized.

When a hardware function is called – from within the embedded code running on the processor – the processor simply transfers values for that function's parameters to the ASP peripheral, starts the function and waits for it to return. If the hardware function delivers a return value, this will be read back by the host processor, to be used by the calling software routine.

This diagram (above) shows how the ASP peripheral concept is used in a design. Here, the two functions – set_tabs and rotate – shown in the C source code file will be translated to hardware circuits by the C-to-Hardware Compiler. Note that interconnect and arbitration components have been left out of the illustration for clarity (you can see them in the OpenBus diagram, shown below).

WB_ASP - Wishbone Application
Specific Processor component
(schematic and OpenBus versions).

In the above diagram, notice that the ASP has a memory interface which is connected to the same memory as the soft processor. Variables that are common to both software and hardware functions are allocated in this shared memory. In terms of addressing, a software function can simply pass a pointer value – to a variable (data object) stored in the shared memory – as a parameter to a called hardware function.

To use the ASP component in an OpenBus System document, it can be found in the Peripherals region of the OpenBus Palette panel. For a schematic document, the WB_ASP component can be found in the FPGA Peripherals (Wishbone) integrated library.

Features of the ASP component:

  • Ability to specify which C source functions are to be implemented in hardware
  • Ability to export hardware functions to software (callable by software functions)
  • Ability to specify global variables to be allocated in hardware
  • Ability to globally control hardware generation and use of hardware functions from software
  • Completely configurable from the OpenBus System document (or schematic sheet)
  • Wishbone-compliant


Shown here in an OpenBus design, the ASP component (circled) interfaces between the code running on the processor and the functions implemented in the FPGA fabric. Click for a larger view.

Choosing functions

It's important to understand that while virtually all C programs can be converted to FPGA-based digital hardware by the C-to-Hardware Compiler, it is the characteristics of a source function that ultimately determines whether the Compiler can create an efficient hardware component, or whether it's better to execute that function on a processor core. The Compiler can only create a small and fast hardware core if the C source code is parallelizable.

Although functions that are destined for implementation in hardware can be 'identified' directly at the source code level, Altium Designer provides a more friendly, straightforward and intuitive interface as part of the configuration of its ASP peripheral.

The right-hand side of the configuration dialog shown below provides two distinct regions that deal with global variables and functions defined in the C source code of the embedded software project. These are linked to the processor which is wired to communicate with the ASP peripheral.


Set up your hardware acceleration requirements from within the ASP component's configuration dialog.

Here, you use the upper list (one the right) to determine which global variables should be allocated in hardware. Such variables will be allocated in ASP Block RAM by the C-to-Hardware Compiler. Access to this memory is much faster, in comparison to storage allocation in Block RAM outside of the ASP by the Embedded Compiler. Note that a global variable that’s allocated in hardware can only be accessed by a function that has also been implemented in hardware. Such a variable can't be called from a software-based function running on the host processor.

The lower list is used to specify which source functions should be implemented in hardware. To have the C-to-Hardware Compiler generate a function in hardware, as part of the ASP, simply enable the associated check box for that function, in the Implement in Hardware column. If you want to be able to call that hardware function from within the software running on the host processor, make sure that the corresponding check box in the Export to Software column is also enabled.

Here are some key points to consider when using these two function-related options:

  • A function with enabled Implement in Hardware option will become a hardware function.
  • A hardware function can call another hardware function.
  • A hardware function can not call a software function.
  • A software function running on the host processor can call a hardware function, provided that hardware function has been exported to software (Export to Software option enabled for function).
  • A hardware-only function (not exported to software) can call a hardware function that has been exported to software. Conversely, a hardware function that has been exported to software can call a hardware-only function.

Allocation of variables and implementation of functions in hardware can also be performed from within the C source code – either from the C to Hardware panel (shown below), or by right-clicking on a global variable/function directly in the code editor and using the relevant commands that appear on the context menu. Note that when using the panel, only global variables and functions defined in the active C document will be listed.


Specifying hardware acceleration requirements from within the Code Editor.

Generating and using hardware functions

When configuring the ASP component, the following two options are the most important:

  • Generate ASP – this option provides the ability to enable or disable generation of hardware-compiled functions. With this option enabled, the C-to-Hardware Compiler will be invoked when you compile and synthesize your design project. All functions that have been enabled for implementation in hardware will be created as the appropriate configuration of gates in the FPGA fabric.
  • Use ASP from Software – this option lets you to control, on a global level, whether functions compiled into hardware can be called by software-based functions running on the processor. If this option is disabled, the relevant Embedded Compiler will generate the functions in software, and these will be used instead.

The typical (and most efficient) way to use these two options is actually from a debugging perspective. In terms of code development, debugging a function is only really possible at the C source code level. It is near-impossible to debug the corresponding hardware implementation of that function.

By enabling the Generate ASP option, and disabling the Use ASP from Software option, you can effectively test and develop the software-compiled code only. The FPGA logic for any functions enabled for implementation in hardware will still be generated, but the processor will only use software-compiled versions of those functions.

Once the software is fully debugged and operates as required, then just enable the Use ASP from Software option, to switch over to using the hardware implementations of those functions. As the logic for the hardware functions already exists, full reprocessing of the entire FPGA design is not required – it is simply a case of recompiling and downloading the updated embedded software.

In this way you can quickly switch between software-only and software-hardware implementations of the design, to observe the benefits obtained by using hardware acceleration. The process then becomes and iterative and explorative way to fine tune your design for the best performance or cost-efficiency outcome.

More information

► September 09 Envision home