Introduction
Over two-fifths of FPGA design projects fall behind schedule. In order to reduce risk of delay of product delivery, changes need to be made not just in verification and production but also in the design process. Design simplification must be a principle that starts at the beginning of the project life cycle – before verification of complex code has become the bottleneck that delays project delivery.
For FPGA design, there are several methodologies that can be adopted to make life easier for both design and verification engineers. Two of these will be examined here: SystemVerilog for design and behavioral modeling.
No Time for Change
Most design teams claim that there’s no time to change design methodologies due to project schedules—it’s just one tape-out after another. Perhaps a high-level view of the problem can serve as motivation to take pause and reconsider where time is really being wasted.
As mentioned, studies show that two-fifths of designs fall behind schedule. One-fifth of the delays are caused by design-and-verification issues. Another two-thirds of these delays are caused by System Integration and Test-and-Verification issues. The same customer surveys show that today’s engineers spend a third of their time on verification and this is expected to grow to roughly 40% in the next two years.
Perhaps the right question to ask is to what degree do the number of bugs found and the number of bugs not found (perhaps of more interest) depend on the amount of RTL code and its complexity. In the past we were able to perform detailed design reviews (DR) of each sub-block of a design within one to two hours and a DR of the entire design within a few days. For today’s designs, this process is nearly impossible to perform in the same time-frame. More than 60% of designers today expect the total number of lines in their RTL code to increase by 20% in their next project. Even taking into account design reuse methodologies, more potential bugs per design are expected due to greater size and complexity.
Figure 1: Bugs History Histogram
In addition, larger designs cause longer simulation times, and in turn lengthen the lifetime of product development as shown in the bug histogram. As designs grow in size, they have more bugs and it takes longer to identify them, fix them, and verify the fixes. More time must to be spent on verification, increasing the chance of project delay.
So how to address this problem? In conjunction with improving the verification process, design engineers can reduce the number of bugs in their designs by adopting several methodologies—two of them explained here.
SystemVerilog for Reducing Complexity
A wise man once said “make things simple”. So how is it possible to simplify RTL code while the complexity of the design itself is increasing? The answer is to use higher level language structures. Studies have shown that using SystemVerilog for design entry may reduce the size of the design by a factor of two to five.
Much has been written about SystemVerilog and yet it still has not experienced broad adoption by design teams. Among the reasons for its slow adoption includes the effort of changing design methodology, training design engineers, and, of course, finding adequate tool support. This kind of effort requires justification.
One design team leader of a well known semiconductor company stated that his engineers have not adopted SystemVerilog for two primary reasons. First and foremost, they simply have no time. They release a new chip every few months and can not allocate time between projects to research the new language extensions. Secondly, they claim that the available tool support is inadequate.
This latter claim is no longer the case—today’s market leading design tools have comprehensive SystemVerilog support that allow for seamless usage of the language.
Figure 2 : Next Project Choice
There are many useful design constructs in SystemVerilog (SV), but only a sub-set will be examined here. The following is an example of parameterized interfaces, where I/O ports are bundled and reused among different modules, reducing the risk of error during top level integration.
In this example, a behavioral model of Single Port RAM is instantiated under the top level module. The use of parameterized interfaces prevents the common mistakes of port mismatch and wrong interface interconnections.
As seen from the above example, once the interface named address_bus is defined, it may be reused in different modules in the following way:
module memory (address_bus.address_port_in addr)
where the hierarchical port declaration address_bus.address_port_in is used for the addr port. Using such unified and parameterized declarations can help solve port width mismatch problems in designs.
Another useful construct is the implicit port connection. The memory module is instantiated using these type of connections:
memory #(.p1(p1), .p2(p2)) mem_i (.*);
The (.*) notation automatically connects instance ports to the top level signals with the same names and data types. This technique can significantly reduce integration problems, particularly when naming rules are used as part of an in-company convention.
Behavioral Modeling of FPGA cores
Note that in the above example, the memory is inferable by synthesis and may be implemented using dedicated FPGA memory resources depending on the selected FPGA vendor and device family, as shown in Figure 3 . This brings us to the next design methodology that can reduce project delay—the use of behavioral models.
Figure 3 : Design Implementation
Much has been written about behavioral design and its advantages versus instantiation of FPGA vendor’s IP cores. While there are the advantages of portability and vendor independence, other advantages include faster simulation times, code-re-use, and flexibility for hardware implementation. All of these make the design and verification flow more efficient.
Most FPGA vendor’s IP cores are instantiated as black or gray boxes. These are either linked by synthesis or place-and-route (P&R) tools to generated gate-level netlists, or they are predefined functional blocks. As a result, simulation times drastically increase even at the RTL level versus the same design that uses behavioral models. In fact, the simulation time of a design using behavioral models may be two to twenty times faster than the same design using instantiated IP cores.
Behavioral models also allow for scalability. The memory block shown above may be used many times using different parameters to implement memories throughout the design. A single parameterized module can be enough to describe several configurations, such as a single-port or dual port memory, using either write-first, read-first, or no-change write-modes. These configurations cover the majority of requirements of mainstream FPGA design. This methodology would require four files versus tens or hundreds of files when using vendor IP blocks.
Behavioral models also leverage the flexibility of the synthesis tool to implement the logic using different FPGA resources. Designers may control resource allocation of memory blocks and arithmetical functions during synthesis using either synthesis attributes or via a graphical resource management interface. Controlling resource allocation without changing code or regenerating many IP blocks may considerably shorten the design process.
Conclusion
There are other methodologies for improving the FPGA design and the verification process, but using SystemVerilog language structures along with behavioral design are two simple ways to ease the effort by changing the design process from the start. While there is a time commitment in adopting these methods, it is relatively minor and the time savings gained from them will pay-off many times over in terms of easier debug, shorter simulation times, code re-usability, and flexibility in hardware implementation. Project delivery can finally be predictable by efficiently generating reliable, bug free code for complex designs.
