Fifteen years ago verification of FPGA designs was easy: you only needed a decent gate-level simulator to verify a circuit containing several thousands of logic elements. As the size of FPGAs started to grow, so did the complexity of the designs implemented in them.

Over time, hardware description languages sneaked into schematic designs and eventually replaced schematic entry.

Today, it is quite common that FPGA users have to deal with more than one language in their designs (e.g. original sources in VHDL with some IP core in Verilog). At earlier stages of the design development it may be necessary to interface HDL simulation with environments using Domain Specific Languages, such as Matlab. To speed up testbench simulations, patches written in C/C++ are used frequently. Sometimes, when simulation is still too slow, hardware acceleration may be necessary. In the last two years embedded systems found their way into the FPGA domain, adding one more headache – how to test both system software and system hardware in the simulation environment not prepared for this task.

In this article we analyze sample solutions to the problems mentioned above that make the life of a modern FPGA system designer much easier.

The history of FPGA design verification

When Xilinx released the first FPGA in 1985, the XC2064 chip and its 1,000 gate size seemed very impressive. No one probably predicted that by the year 2004 the size of an FPGA would be 10,000 times larger…

As long as design size remained within the range of several thousand gates, schematic design entry and a good gate-level simulator were enough to create and verify the entire design. Hardware descriptions languages started to sneak into schematic designs in the shape of HDL macros, and as designs migrated into tens of thousands of gates they gained importance. By the time FPGAs crossed the100,000 gate threshold it became obvious that HDLs would have to eliminate schematic entry and gate-level simulators. The two most important factors were:

-The impossibility to manage all-schematic designs at this level of complication,
– The necessity to synthesize HDL macros before gate-level simulation.

Although HDL simulators were available since the late 80’s, lack of efficient HDL synthesis tools prevented wider application of an HDL-only FPGA design flow. When the speed of HDL simulations started to approach the speed of gate-level simulations, synthesizers became more efficient and schematic tools turned into block diagram editors able to generate HDL netlists, it was time to switch the entire FPGA design flow to HDLs.

Of course it was just the first step: VHDL and Verilog were quickly joined with traditional programming languages (C/C++) and domain-specific languages (Matlab). In the following sections we demonstrate how an FPGA designer can deal with challenges created by this diversity.

Mixed language designs

VHDL was the first hardware description language that gained popularity in the FPGA design world. When the size of FPGAs started to grow, Verilog solution providers working mainly in the ASIC domain realized the opportunity to enter the FPGA market. Right now both VHDL and Verilog are used in large FPGA designs. If the design is created from scratch, it may be possible to handle it entirely in one description language. If legacy code must be re-used, or if IP cores have to be incorporated, we may end up with a mixed-language design. While peaceful co-existence of VHDL and Verilog in the design description was never a problem, efficient simulation of mixed-language designs is a challenge.

The first HDL simulators were usually dealing with one language only. When two languages had to be handled in one design, co-simulation using both VHDL and Verilog simulators was the obvious solution. Please note that the Unix platform seemed better suited for this solution than Windows.

Frequent data exchange between separate simulation engines may have a negative effect on the performance of the entire design simulation. That’s the main reason why single kernel simulators are now the most popular verification tools.

Although there are differences in scheduling mechanisms used in Verilog and VHDL simulations, similarities prevail. It is possible to create one simulation engine (kernel) that meets the requirements of both hardware description languages. When paired with matching compilers and elaborators, a single kernel simulator creates the optimal environment for verification of mixed language designs. Benefits are obvious for both designers and simulation tool vendors:

-The use of one simulation engine means that designers don’t have to fight with configuring multiple tools to co-simulate properly.
-The growing size of designs creates the pressure to increase speed and reduce resource usage during simulation; a single kernel makes any kind of simulation optimization easier than separate kernels.
-A single kernel simulator can be easily turned into a VHDL-only or Verilog-only simulator via licensing options, eliminating the need of maintaining multiple tools by the software vendor.

Single kernel simulators supporting Verilog and VHDL are very popular and should be the first choice for anybody working in a mixed-language environment. Some tools can handle even more description formats in one kernel, e.g. EDIF netlist.

Programming Language Interface in HDL simulation

Large FPGA designs usually require advanced verification algorithms. Some of those algorithms, even if they can be implemented in VHDL or Verilog, are not simulating efficiently in the HDL environment. That’s why modern simulators enable the interface with routines written in traditional programming languages – mainly C and C++. Typical applications of such interface include:

-Encoding functions without native support in HDLs (e.g. trigonometric functions in Verilog).
-Accessing functions of the operating system.
-Accessing hardware devices (logic analyzers, data collection units, etc.)

Since its very beginning, VHDL provided open access to programming language routines via foreign architectures and subprograms. This approach enables a very efficient connection between the simulator and user-written routines, but requires excellent knowledge of the simulator’s application program interface (API). Even if developers have no problems with the use of a given simulator’s API, the chances are that whatever works now will not be portable to other simulation platforms.

Verilog used a slightly different approach: its standard contains a description of the C language procedural interface, better known as programming language interface (PLI). We can treat PLI as a standardized simulator API for routines written in C or C++. Most recent extensions to PLI are known as Verilog procedural interface (VPI); the solution enabling a similar interface between VHDL and C/C++ is in the final stage of development and is called VHPI (VHDL Procedural Interface).

PLI and VHPI give design and verification engineers developing C/C++ routines a mechanism that shields them from the low-level details of their simulator operations that are irrelevant to the verified design functionality. Since PLI (or VHPI) is standardized, both C code and matching PLI calls should be much easier to port between different simulation platforms. But one non-standard area still remains: the connection of the PLI (VHPI) engine with the simulation kernel. Procedures involved here vary dramatically between different simulators and may look like black magic to designers that are not professional C/C++ programmers.

Fortunately a little bit of good will shown by a simulator vendor can eliminate this last hurdle. A small applet or wizard (like the one shown in Figure 1) should be able to create low-level interface files.

Figure 1. Sample VHPI/PLI Wizard for HDL simulator environment.

A user preparing his or her C code for connection with the simulator has to fill in several simple fields related only to the C code being connected and PLI/VHPI routines that have to be used. After completion of the wizard, two .cpp files are created. One contains all low-level routines required to connect the simulator with the PLI/VHPI engine and does not have to be modified by the user. The other contains placeholders for both pure C functions and related PLI/VHPI routines.

After entering his or her code, the user compiles and links both files, receiving a dynamically linked library that can be used during simulation.

Co-simulation with Domain Specific Languages

Quite frequently HDLs are not the best choice to start the description of a digital system. If the design has to implement advanced mathematical operations, Matlab is a very convenient environment for quick verification of ideas. For many DSP designs using algorithms published in C, a toolset similar to Celoxica’s DK2 with Handel-C support will be the best choice.

In both cases we are dealing with domain specific languages used for the description of the design. Once the initial description is verified in its native form, the designer faces the task of implementing that description in hardware. Some solutions translating domain specific language descriptions directly into the vendor-specific netlist may exist, but the traditional approach involves a gradual translation of original files to HDLs, and then continuing the implementation in the classic FPGA design flow.

The key issue here is maintaining the design integrity during DSL to HDL translation. One simulator alone will not be helpful; but working together during HDL/DSL co-simulation they can be very useful.

Of course various co-simulation solutions exist, but the user effort required to make them work in any particular design may be discouraging to the designers.

Let’s consider the case of converting one block of Matlab description of the design to a VHDL design unit.

Once the designer has the VHDL model with functionality (supposedly) identical to the original Matlab description, they need to create an interface between the data systems of both environments. For every port of a VHDL entity they have to specify at least typecast (pair of matching data types in VHDL and Matlab). If the port happens to be a vector, there are several additional tasks: specification of the number of bits in the integer and fractional part, quantization method and overflow handling mechanism. Then there is the important task of convincing Matlab’s Simulink that the VHDL descriptions are ready for co-simulation.

Fortunately Matlab provides a convenient black-box mechanism; the designer just has to know how to create the black-box, or the set of black-boxes for the entire design.

Once the black-box is created, and before starting co-simulation in Simulink, the designer may have to adjust some additional parameters, such as a sampling period. When co-simulation is running, Scope from the Matlab environment can be used to visualize native Matlab signals and ports of the black-boxes; to observe internal black-boxes signals, it is necessary to use an HDL simulator.

Please note that Matlab provides an open method of adding blocksets for co-simulation; the actual blockset creation is the task of the user connecting his or her simulator. Good HDL simulators should provide an automated method of generating Simulink blocksets. In the Windows environment they will usually take the shape of Wizards. Figure 2 presents a sample solution: a wizard started for each HDL module that should have its black-box for co-simulation. Upon completion of all wizard sessions specifying common output directory, a Simulink blockset is created automatically in the specified location.

Figure 2. Sample Matlab (Simulink) Co-simulation Wizard

Speeding-up simulations

As the size of FPGA design grows, the decrease of pure HDL simulation performance becomes noticeable. When verification procedures take hours to execute, it is time to think about hardware acceleration.

ASIC designers were implementing hardware acceleration of HDL simulation for some time before FPGA designers were forced to follow their steps. Please note one very important difference between accelerating ASIC and FPGA simulations: while there is no target silicon available yet when an ASIC design is verified, the FPGA designer has access to the target silicon all the time – it just requires programming. Consequently, ASIC designers have to use costly emulators, but FPGA designers will get similar results using a good prototyping board.

FPGA designers can use two popular methodologies of speeding-up their simulations:

-EMULATION assumes that the entire design is synthesized and implemented, then pushed into the FPGA on the hardware board connected to the computer where the HDL simulator is installed. During verification, the HDL simulator provides stimulus for the design pushed into hardware, reads design response and processes received data. While this methodology assures maximal verification speeds permitted by the hardware board and its interface with the computer, visibility of the design may be insufficient for more advanced debugging. Of course an embedded logic analyzer or similar solution can be added to the design before it is implemented and pushed to the hardware board, but the necessity to modify the design only to increase visibility during verification may be hard to accept.

-ACCELERATION assumes that only a part of the design is pushed into the hardware; the rest is kept in the HDL simulator environment and co-simulates with the hardware part. Very efficient communication protocols between the board and the simulation kernel are required to maintain a significant increase of verification speed in this methodology, but even if they are available, the wrong selection of design modules pushed into hardware may nullify gains introduced by acceleration. That’s why profiling of the design being verified is essential: modules occupying a significant portion of simulation time should be pushed into hardware first.

Although acceleration is slower than emulation, it is easier to implement when a high level of design visibility is required during verification. FPGA designs with a high percentage of original HDL code will probably benefit more from acceleration. Designs with heavy use of IP cores and previously created and verified modules may only need emulation. Design houses working on a diverse range of projects will see an equal demand for emulation and acceleration.

Challenges introduced by FPGA-based embedded systems

For a long period of time changes in the methods of creating and verifying FPGA designs were more evolutionary than revolutionary. But once the size of FPGAs became large enough to place the entire microprocessor inside (with enough room left for some peripherals), revolution had to come.

The nature of System On Chip (SOC) is dramatically different from traditional, hardware-only FPGA design: system software running on the embedded microprocessor is the integral part of the system, not just the way of designing it. Traditional flows used in FPGA development or software development always leave some part of the SOC not verified. Of course it is possible to develop system hardware and system software independently, verifying the entire system after the prototyping stage has been reached.

This approach has several important flaws:

-Design verification cycle is longer (each detected error on the hardware side requires re-creation of the prototype)
-Visibility of the design during verification may be insufficient (see our comments about emulation in the previous section
-Hardware designers are forced to use slow MPU models during simulations
-System software developers are using inaccurate C models of hardware.

There are two promising solutions that address at least some of the problems mentioned above: SystemC and SystemVerilog. Both have many interesting features, but both are still in the development stage (they have not reached the IEEE standardization phase yet).

There are some success stories describing projects developed using both solutions, but they are coming from big design houses dealing with ASICS or even discrete systems. It seems that SystemC and SystemVerilog solutions are still beyond the budget of a typical FPGA-based SOC project. How will it look in the future? It is really hard to predict; we may see that one of the solutions prevails, but we may also end up with two new, high-level languages…

The question is: what does an FPGA designer have to do if he works on an SOC project right now? There are several systems that integrate existing solutions (such as co-simulation and acceleration discussed earlier in this article) to provide an environment better suited to the needs of the FPGA designer of embedded systems.

Conclusion

The modern FPGA designer faces many different challenges while working on his or her project. Fortunately there are many solutions to choose from, both currently available or being developed. We should expect more powerful, user-friendly tools that will help designers meet new challenges, that will inevitably appear as the size of FPGAs grow.

 

• 
• 
• 
• 
•