Introduction

In the past, preparing a first implementation of an FPGA design on the board was relatively straightforward, requiring only a single design project, a handful of source projects, and a single design engineer. Subsequent improvements to the FPGA design on the board could be reflected in a matter of hours.

Today’s designs are not so simple. FPGAs are used in production to implement complex designs such as those for consumer, computer, and communications applications, where staying ahead of the competition requires fast delivery of the next-generation system that includes new functionality or perhaps takes advantage of a new FPGA device.

And, more and more, FPGA-based prototyping systems are being used to verify huge pending ASIC designs. These types of designs typically consist of 1000s of source files and implement the equivalent of multi-million gate ASIC designs. To add to the problem, the engineer implementing and verifying the design in an FPGA may not have been the one who authored the RTL code and may therefore be unfamiliar with it.

Some FPGA systems are partitioned across multiple FPGAs, adding another level of complexity to the process.  With designs this huge and design source often foreign to the user, the time required to bring up the first working implementation of the design on the board can now be weeks, the result of a staggering number of setup requirements, ASIC design conversion issues and user errors in the overall design specification.

Users hope for quick feedback on their design specification – that is, efficient ways to identify, isolate and fix issues that prevent design completion from occurring.  The fewer design iterations needed to do this, the better. Whereas top-down implementation methodologies still work well in some cases, a hierarchical design methodology is usually more appropriate for runtime and design stability reasons.

But, that’s only one piece of the puzzle. Another important piece is the ability for the design project to proceed in the presence of errors using  synthesis “continue-on-error” technology, and then merge multiple fixes at once, incrementally, using hierarchical design approaches.  By using these methods users can find multiple errors in one design iteration and apply fixes in parallel,  potentially cutting days, if not weeks, off the time taken for initial board bring-up. Let’s explore this in more detail.

Challenges for FPGA design bring-up

Designers face several technical challenges during initial board bring-up of their FPGA-based system as follows:

• Large projects being imported from non-FPGA environments are initially hard to set up for successful FPGA synthesis and verification.   There may be ASIC design conversion issues, for example with clocks and memories.  The design may simply fail to compile during synthesis due to ASIC gated clock conversion failure or because some of the ASIC source is missing.
• Determining the block(s) responsible or the root cause of a design failure on the board is difficult
• Comprehending the design hierarchy and file interdependencies, especially if one did not author the source files, can be a challenge, making it hard to isolate a module to analyze and improve it
• FPGA designs consisting of more than one FPGA add additional levels of complexity because the user must now ensure that inter-chip signal and clock synchronization occurs between  the FPGAs on the board
  The need for hierarchical “divide-and-conquer” flows
  Hierarchical flows can help with all of these design challenges. With the ability to divide large projects into hierarchical blocks that can be treated as individual subprojects, the designer can focus on improving or debugging a smaller problem and isolate suspected errors to individual blocks or modules of the design.

This can be useful in assessing both design compilation errors and in determining the reason why the design does not work properly on the board. FPGA board bring-up problems may be the result of erroneous clocking setup. This kind of issue can also be identified by dividing the design up into blocks and running simple testbenches at the block interface level.  

In the face of errors, tool efficiency is a must

While hierarchical design can help the design and debug process, it’s the tools and tool features that implement the theory of hierarchical design on the board. To take advantage of the benefits that hierarchical design can offer, users must choose tools that incorporate key productivity features to identify, isolate, and correct design errors quickly.

For example, design tools must allow the user to continue the synthesis process without stumbling over the first error that is uncovered. Synthesis cycles that abort or fail after running for several hours require users to repeat the cycle to fix each individual error one at a time until a clean synthesis compile is finally achieved.

Clearly, one full synthesis iteration per error is inefficient when you consider that the thousands of design source files may cumulatively contain hundreds of errors. Continue-on-error synthesis technology enables multiple errors to be resolved at once.

Applying multiple fixes at once – Continue-on-error hierarchical flows

The idea behind continue-on-error synthesis is that it enables a first complete successful synthesis run to occur sooner, with fewer iterations. It does this by allowing multiple errors to be flagged in a single synthesis cycle while completing synthesis on the error-free modules, in contrast to the traditional approach that required the design to be resynthesized in its entirety to incorporate a fix in even the tiniest portion.

Now, the flexibility to simply paste the fix into the design at the netlist level saves synthesis runtime and preserves parts of the design known to already work. This merge approach, also known as hierarchical bottom-up synthesis, provides a much quicker way to assess whether the fix actually worked.

Erroneous modules that are flagged can, in fact, be fixed in aggregate and in parallel, with the fixes applied incrementally using either a hierarchical bottom-up “netlist merge” flow.  Alternatively, the designer can still resynthesize the entire design using a top-down flow to maximize QoR after the fixes have been confirmed to be successful using the bottom-up approach.  This process, shown in Figure 1, shortens the time it takes to get the design through its first successful synthesis in the face of hundreds of errors.

Figure 1: The Continue-on-error feature means fewer synthesis iterations are required to resolve errors when introducing or synthesizing RTL.

Continue-on-error synthesis flags modules with errors such as missing source files or a non-syntax error such as out-of-range access, missing function or task definitions and improper port/generic mappings. Isolation of problematic modules that contain these errors can be achieved with the help of synthesis reports, hierarchy visualization tools and the ability to physically perform a hierarchical export of the module in question, including its RTL testbench, so that it can be tested and reworked.

For example, the Synopsys Synplify Premier and Certify continue-on-error flow creates a consolidated report of the errors and generates an RTL view of the design with error modules highlighted to enable the user to quickly pinpoint design issues and erroneous modules, as shown in Figure 2.

Figure 2.  Erroneous modules and those with missing files are highlighted in red and an aggregate error report is generated.  Fixes can be merged incrementally at the netlist level (hierarchical bottom-up flow) or the RTL level (top-down flow)

Comprehending the hierarchy

Comprehending the natural design hierarchy is a good first step to isolating design flaws, yet can itself be a challenge in the face of thousands of source files.  Visualization of the hierarchy early in the design process, as shown in Figure 3, can help.

Figure 3:  Understanding the design hierarchy and which
source files belong to which block is critical

This visualization is an integral ingredient that relates an “erroneous module” back to the module’s actual source files, allowing source file errors to be quickly narrowed down.  This process can also help in identifying which block or module has missing source files and is the first step to assessing the module in isolation.  Users can then export the files, testbenches and settings associated with that hierarchical block for further improvement and analysis.

Multi-FPGA systems

In the case of designs that consist of multiple FPGAs, designers can improve turnaround time during the debug and modify phase of a multi-FPGA ASIC prototyping project, using the same hierarchical design with continue-on-error approach. After the design partitioning phase during which design blocks are distributed across multiple FPGA devices, each FPGA partition can be further divided into multiple synthesis hierarchical blocks that can be executed and fixed in parallel.

The designer will want to ensure that inter-chip signal and clock synchronization occurs between FPGAs on board for multi-FPGA designs.  With the divide and conquer approach described above, it is possible to deliver a working FPGA on the board sooner to evaluate whether system clocks and signals have been adequately specified and synchronized and to make appropriate adjustments.

In many cases, chip I/O pins will be MUXed, adding to the overall complexity of the chip synchronization problem.  The ability to export RTL testbenches for a particular hierarchical block of the design to enable basic board connectivity testing and signoff of a submodule can also help narrow down single and multi-chip signal synchronization issues alike.

Dealing with ASIC conversion issues

When an ASIC design is being prototyped and validated in an FPGA or converted to an FPGA, it is usually necessary to convert memories and clocks to a more FPGA-friendly and resource-efficient form. Embedded memories may need to be carved out and either implemented using memory that is external to the FPGA or implemented on the FPGA efficiently using FPGA memory generators. Gated clock structures put in place to save power in the ASIC are no longer necessary in the FPGA and cause inefficient use of FPGA resources.

The Gated/Generated Clock Conversion feature of the Synplify Premier and Certify FPGA synthesis tools performs conversion of these structures to skew issues and reduce the number of clock sources required in the design. This in turn allows the design to fit more easily into the FPGA resources available. However, clock conversion may fail due to poor synthesis constraints setup or an erroneous or unimplemented part of the design existing between a clock and its original source. These kinds of problems surface during synthesis and fixing them is critical to initial board bring-up.   It is critical that, during the early compile stage of synthesis, the existence of one or more clock conversion failure is flagged so that these issues can be corrected up front.  

Conclusion

Today’s FPGAs may contain the equivalent of millions of logic gates and thousands of source files. Multi-FPGA systems are common, particularly in designs used to prototype ASICs. With these levels of complexity, it can often take weeks to create a first working implementation of an FPGA-based system on the board.  The newest generation of FPGA design tools is responding by supporting hierarchical design approaches, coupled with continue-on-error synthesis, which allows multiple errors to be fixed in aggregate, requiring fewer design iterations.  These flows provide ways to divide-and-conquer, including the ability to test failing designs at the module interface boundaries to fix clocking issues.  They also allow designers to quickly find and apply fixes resulting from design setup issues by isolating the problem hierarchically and then merging fixes back at the design netlist level using hierarchical bottom-up flows.  

Finding the source of the error and comprehending the design can sometimes be tricky given the large number of source files, and the fact that they designer may not be familiar with every single source file.   Tools now exist to help designers visualize the design implementation hierarchy, relating each hierarchical block back to its source file components.  ASIC conversion issues such as clock conversion failures can be identified up front by the tools.  These items help designers pinpoint where amid those thousands of design files the problems are occurring, and what actions to take to rectify the problems.

The ability to use hierarchical design and fast error resolution to achieve a working design with fewer design iterations is now seen as being mission-critical by any company involved in the creation of one of today’s high-end FPGA designs and is a feature that designers frequently request of FPGA tool providers.

About the author:

Angela Sutton brings over 20 years of experience in the field of semiconductor and semiconductor design tools to her role as staff product marketing manager for Synopsys, Inc.  In this role, she is responsible for the FPGA Implementation product line.

Prior to joining Synopsys, Ms. Sutton worked as senior product marketing manager in charge of FPGA Implementation tools at Synplicity, Inc., which was acquired by Synopsys in May 2008.  Ms. Sutton has also held various business development, marketing, and engineering positions at Cadence, Mentor Graphics, Responsys, and LSI Logic.  At LSI Logic she was responsible for marketing LSI Logic’s line of digital video semiconductor products and platforms.

Ms. Sutton holds a BSc. in Applied Physics from Durham University UK, and a PhD. in Engineering from Aberdeen University UK.

Article Courtesy: Programmable Logic DesignLine