June 1, 2011 -- In the times of a not so rosy economy and constantly growing design sizes, FPGA designers are constantly facing surprises: old companies go away, taking tools and languages with them, new languages and methodologies appear. The only constant element is the demand to deliver a high-performance, well-tested design on time. This article tries to give a quick overview of currently important or forthcoming languages and technologies needed in the design and verification of FPGAs.

While checking the languages used in the FPGA design process, let's consider two perspectives: that of the hardware designer and that of the system/ verification engineer.

Hardware description languages

Since the 2009 merging of Verilog HDL into SystemVerilog standard (IEEE Std 1800-2009) there are only two contenders here: SystemVerilog and VHDL (IEEE Std 1076-2008). Note that SystemC does not belong here — although it has facilities to create RTL descriptions, no one is using this language at this level of abstraction.

Although there are still some designers who stay at the Verilog-2001 level, they should seriously reconsider their position. Designing, verifying and maintaining certain classes of designs in old-style Verilog is a serious impediment in the current competitive environment. Everyone who tried to design a state machine using SystemVerilog enumeration types, improved case statement and other language facilities usually does not want to go back. In addition, all commercial simulators and synthesis tools that support Verilog licenses usually grant access to the SystemVerilog design subset without an extra fee.

VHDL has a very well-established following in the FPGA designer community and the most recent changes in the 2008 revision of the language made it easier to use and more powerful. The language is not dead by any means — a new group working on the next revision of the language was just established. Some companies with poor management practices might have decided to switch their design teams from VHDL to SystemVerilog, but it does not change the fact that there are no technical reasons for such a change; the only happy people in this situation will be sales persons working for tool vendors. Managers considering a similar decision should remember that SystemVerilog verification works very well with VHDL design code and retraining experienced VHDL designers to use a different language is a waste of human resources.

System-level and verification languages

Large FPGA designs have definitely reached system-level complexity, bringing new language choices.

Seasoned system designers are big fans of plain C or C++ used for design descriptions. It should not be a surprise, since the first rendition of the system (at the algorithmic level) is usually an executable. When refinement of the description is needed to consider hardware implementation issues, the language of choice is SystemC (IEEE Std 1666-2005). It is fully compatible with C++ descriptions and provides all of the hardware-related constructs that are needed to deal with hardware at a comfortably high level.

Figure 1. System-level design flow.

SystemVerilog seems to be less popular than SystemC among system designers, mainly because it imposes stronger restrictions in Object Oriented Programming (OOP). The situation changes when we talk about hardware designers migrating into the system-level design domain. Hardware designers can adapt to SystemVerilog faster and easier than to SystemC — especially if they had no prior experience with software development.

From the verification point of view, both languages have advantages and disadvantages. SystemC works better on higher levels of abstraction and slows down as the description reaches RTL. SystemVerilog natively supports constrained random stimulus generation and functional coverage, which require additional coding in SystemC. Strong support for properties and assertions is another area where SystemVerilog wins in competition with SystemC.

FPGA designers deal with various methodologies while working on their projects. Let's review verification methodologies first and then proceed to synthesis methodologies.

Simulation

Simulation is still a very important part of the verification cycle — other methodologies seem to complement, not replace it. Existing simulators usually work in event-driven mode when the highest precision and detailed debugging are required, switching to cycle-based mode for higher speed. Note that VHDL/ Verilog/ SystemVerilog standards do require event-driven simulation support; cycle-based mode and other acceleration techniques do require some sacrifices — mainly reduced visibility of non-critical parts of the simulated design.

One potential of speeding up simulation is created by multi-processor (multi-core) workstations. But some existing tools claiming support of multi-core simulation are not really implementing full-blown parallel computing algorithms.

What they can really do is:

Separate tasks performed by the simulator (simulating, saving waveform data, collecting debugging information, handling GUI into threads running on separate processing cores. Partition the top-level of the design into several relatively independent sections that can be simulated on separate cores.

While the first solution is universal, it cannot significantly speed simulation of really large systems. Design partitioning in order to parallelize simulation is not as easy as it seems. If we divide the design into two parts that have to communicate frequently with each other, the overhead required to synchronize both simulation threads can almost nullify the benefits of parallel processing. Tools face increasingly difficult challenges as the number of available cores grows: dividing the design into four independent parts is more difficult than finding two independent parts.

Simulating a complete system that includes microprocessor units is even more challenging. Traditional simulators are unable to simulate the entire system with an embedded operating system running on it; at best, they can simulate bus cycles during execution of individual MPU instructions. The use of instruction set simulators (ISS) — dedicated programs written in C emulating behavior of the target MPU — can help, but not solve all the problems.

Simulating the entire system with an embedded OS and application software is only possible when hardware co-simulation is implemented. Usually, a prototyping board with the MPU already implemented in the target FPGA is added to the simulating workstation. After establishing a link between the simulator and the prototyping board, the simulator can take care of simulating the already developed system hardware while the MPU on the prototyping board takes care of running system software.

Linting

Designers used to catching small errors during simulation of small designs quickly realize that this is a horrible waste of time while working on large system. That's why addressing those issues before simulation begins is so important.

Linting tools implement design rule checking by analyzing the sources of the design statically. This means that linting tools must be equipped with two critical items:

Sets of reliable rules covering wide range of designs. Efficient engine for checking those rules.

Sets of design rules are available from independent sources (e.g., the STARC consortium) or silicon vendors. Several linting engines are available with different levels of complexity: from the simple ones to those performing pseudo-synthesis of the checked design or even clock domain crossing (CDC) checks.

Property-based design and verification

All designers have to deal with design specifications and their main concern is to correctly implement the specification requirements in the hardware. Unfortunately, during numerous transformations of the design the original specification details can be unintentionally distorted. Having an additional layer in your design that represents the original specification and can be automatically compared with the current iteration of design code could solve this problem.

Design specification properties can be formalized using SystemVerilog properties, VHDL 2008 or PSL (Property Specification Language). Once in the code, verification tools can test properties for violations using assert directives or for proper coverage using cover directives. As you see from this brief description, the popular buzzword "assertions" reflects only a small portion of the much wider area of property-based design and verification.

FPGA designers can immediately start using properties in simulation — as long as their tools support them. Formal verification tools can also use properties, but may be less accessible.

Formal verification

Formal verification tests correctness of the design using mathematical transformations of the design description instead of simulation. Formal tools can be roughly divided into two categories:

Equivalence checkers compare the current iteration of the design against golden reference. If the functionality of both is identical, verification passes; in other cases, the designer gets information about functionality changes and their possible sources. Model checkers rely on design properties formalized in SystemVerilog or PSL to mathematically prove that the design functionality matches those properties.

Both equivalence checkers and model checkers are popular in ASIC design and are slowly migrate into the FPGA design domain.

Behavioral synthesis

Behavioral synthesis seems to be Holy Grail of electronic design. Its main fault was the too general promise of taking any behavioral description of the system and producing function hardware. No one managed to create a tool that performs such a challenging task without constraints.

We can get well performing behavioral synthesizers if we make some initial assumptions:

Original description is in C/C++/SystemC. Behavioral description uses structural model of communicating processes. Communication model is TLM (transaction-level modeling). Result is RTL code in Verilog or VHDL ready to be synthesized into hardware.

Behavioral synthesis tools may be very expensive, but necessary in the development of large FPGA systems.

RTL synthesis

Even if the starting description of the FPGA system is at a high abstraction level, eventually it will be refined down to RTL level and traditional synthesis will be needed. Although the number of vendors delivering RTL synthesis tools decreased recently, there are still many viable choices available. FPGA designers should always seek the tool that supports most the recent versions of Verilog/ VHDL and provides the most efficient optimizations.

In summary

To conclude our review, let's create a list of tools that any serious FPGA designer should have access to:

A simulator is a necessity. It should support multiple languages (Verilog, VHDL, SystemC and SystemVerilog) to allow efficient mixing of both design and verification IP. A good RTL synthesizer is also a must, since all designs need it. Mixed language support is highly recommended. A linting tool can be very useful in medium to large designs, where it complements the simulator. This should be a high priority if the budget allows some flexibility. A behavioral synthesis tool may be required while designing large systems. A formal tool should be considered when really big systems are designed. Its high cost will be returned if the company frequently works on totally new designs. A hardware co-simulation solution saves a lot of time when embedded systems are designed and can also be used for simulation acceleration.

Missing some of the advanced tools from the list does not mean that the design cannot be completed, but it usually means that the design will take longer to complete. In very competitive environments it may be a problem, so designers and team managers should choose their tools and methodologies wisely.

By Jaroslaw "Jerry" Kaczynski.

Jaroslaw 'Jerry' Kaczynski is a research Engineer at Aldec, Inc. and has 19 years of working experience in the fields of HDL language and tool training, technical writing, application and research engineering. Jerry is IEEE member, participated in development of industry standards and has both working and teaching experience of PSL, .