The Need for an API for FGPA development

In the software development field, utilizing an API for development is essential to productive software development.  Although the definition of an API may differ depending on the specific field (desktop app development, web development, or low level device driver software,... etc.), one can assume that an API relates to a set of functionality or services that are assumed available by using pre-existing functions and procedure calls.  Productivity for the software developer comes with the assumption that low level details about common functionality should be worked out already and the developer should be able to easily leverage this common functionary in their application.

FPGAs on the other hand are hailed as being 'blank slate devices' that can be configured to perform any digital logic functionality.  This may be both the FPGAs best attribute and also its Achilles heel in the sense that FPGAs do come with any expected functionality to begin begin with. The problem with developing on an FPGA as that many times there is a need to 'reinvent the wheel' when it comes to common functionality. For developers to be more productive with FPGAs, there needs to be a way to more easily leverage common functionality in an FPGA application without  the need to handle low level details.

.

SpeakHDL FPGA API Development

The utility of an API, need not be limited to to software development. It is fair to assume that most FPGA developers could benefit from an API to more easier access to common functionality with FPGA applications. The issue  with developing an API for FPGA use is two fold:

1. What would be the common set of functionality that an API would give to the FPGA developer?
2. How an API should be implemented on an FPGA as there is no Operating System to make API calls to?

To answer the first question, SpeakHDL exposes the following list of procedure calls to the developers. Developing an API for FPGA development is tedious in the sense that one would like to achieve functionality that may somewhat overlapping with each API call however do not want to create a very large number of API calls.

As far as how an FPGA API should be implemented... SpeakHDL approaches the implementation of an API is by using a design pattern with a flat design architecture. By making the application conceptually creates the opportunity to crating a single framework module that can 'service' all the others in the same way that an an OS would do for software applications.  The code that actually implements the design pattern will be placed into a library.

A Uniform Coding Structure for VHDL files

Given that procedural programming is indeed a high level data flow HDL modeling scheme, we now describe how procedural programming can be useful for FPGA design . When used in conjunction with a Flat Design Architecture and abstract data types at the module port interface we can now begin structuring all of our VHDL design files in a uniform way.

To motivate how that can be done, we must recall that at a very high level, the functionality of all data processing devices (whether it be either hardware or software) are essentially the same and can easily described.

All data processing devices must have the capability to accept some input data (or possibly generate some data) then internally process that data in some way.

From there, the device can only do one of two things.

The device can either:

After some key words are uttered, in this case the word " ok ", SpeakHDL generates all the supporting files necessary to compile and simulate the design in a third party VHDL simulator (Modelsim, Viviado Simulator ect.) .

• TESTBENCH.vhd
• TOP.vhd
• SM_API_PKG.vhd
• USER_DEFS_PKG.vhd

In general, the user need not be concerned about the contents of any of the supporting files as they are scripted and may update periodically. In addition, because SpeakHDL sets up the port interface of the user design files to the format necessary to utilize the design pattern, connection of the modules with the rest of the system is an automated and transparent process. The user need not interact with the top-level file in any way.

This design example, involving just two user files ( test_module.vhd , and fft.vhd ) may be a rather trivial example in terms of FPGA functionality. However, it can be used to highlight a few key features that make SpeakHDL a very productive design tool.

1. No prior knowledge of VHDL is necessary to begin development using SpeakHDL.
2. There is no need to understand the all the specifics of how the design pattern works in order to make use of it.
3. Testing of a FPGA design using SpeakHDL and the underlying design pattern is a very simple process, and i s not like writing traditional testbenches.

Handling Sequential Programming

Procedural Programming with a software program differs from procedural programming with a HDL in the sense that, with software program, it is assumed that every procedure operates sequentially until specified that there will be parallel operation.

With a hardware program, the opposite is true.  Procedures are assumed to operate in parallel until a coding struct is encountered that has the procedures operate sequentially,.  With Speak HDL, sequential programming is handled by the use of state machines.