feature article
Subscribe Now

Avoid FPGA Project Delays by Adopting Advanced Design Methodologies

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.

20080527_mentor_fig1.gif

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.

20080527_mentor_fig2.gif

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.

20080527_mentor_fig.gif

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.

20080527_mentor_fig3.gif

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.

Leave a Reply

featured blogs
Sep 17, 2021
Dear BoardSurfers, I want to unapologetically hijack the normal news and exciting feature information that you are accustomed to reading about in the world of PCB Design blogs to eagerly let you know... [[ Click on the title to access the full blog on the Cadence Community s...
Sep 16, 2021
I was quite happy with the static platform I'd created for my pseudo robot heads, and then some mad impetuous fool suggested servos. Oh no! Here we go again......
Sep 15, 2021
Learn how chiplets form the basis of multi-die HPC processor architectures, fueling modern HPC applications and scaling performance & power beyond Moore's Law. The post What's Driving the Demand for Chiplets? appeared first on From Silicon To Software....
Aug 5, 2021
Megh Computing's Video Analytics Solution (VAS) portfolio implements a flexible and scalable video analytics pipeline consisting of the following elements: Video Ingestion Video Transformation Object Detection and Inference Video Analytics Visualization   Because Megh's ...

featured video

Product Update: Complete DesignWare 400G/800G Ethernet IP

Sponsored by Synopsys

In this video product experts describe how designers can maximize the performance of their high-performance computing, AI and networking SoCs with Synopsys' complete DesignWare Ethernet 400G/800G IP solution, including MAC, PCS and PHY.

Click here for more information

featured paper

Designing device power-supply ICs in an application-specific automated test equipment system

Sponsored by Maxim Integrated (now part of Analog Devices)

This application note provides guidelines for selecting the device power-supply (DPS) IC in an automated test equipment (ATE) system. These considerations will help you select the right DPS IC for your specific ATE system. It also explains the best system level architecture to tackle the output current and thermal requirements of the ATE system.

Click to read more

featured chalk talk

BLDC Applications and Product Solutions

Sponsored by Mouser Electronics and ON Semiconductor

In many ways, Industry 4.0 is encouraging innovation in the arena of brushless motor design. In this episode of Chalk Talk, Amelia Dalton chats with CJ Waters of ON Semiconductor about the components involved in brushless motor design and how new applications like collaborative robots can take advantage of the benefits of BLDCs.

Click here for more information about ON Semiconductor Brushless DC Motor Control Solutions