Technical Publications - FPGA
Providing a Comprehensive Design Flow for Successful FPGA-to-Structured ASIC Migration
More Techpubs
Making the Case For an Integrated FPGA Design Flow
With the rate of ASIC-to-FPGA conversions continuing to escalate, choosing the right FPGA design tools can determine the course and competitiveness of a system house’s entire business. Design teams can select proprietary solutions, commercial tools, and other alternatives. Some choices offer short-term cost advantages, others offer longer-term flexibility. This paper discusses the pros and cons of the diverse approaches available today.
Designing Multi-FPGA Prototypes That Act Like ASICs
FPGA prototyping has become indispensable for functional verification and early software integration of prospective ASIC designs. If the ASIC in question is large, it is often necessary to spread the functionality across multiple FPGAs on a special prototype board. This white paper discusses the importance of choosing the right tools and methods to most efficiently partition ASIC functions into multiple FPGAs for development and evaluation purposes.
Block-Based FPGA Design Flows Support Team Design and IP Re-use
Block-based design—a method of partitioning a complex FPGA design into natural sub-blocks—has become a necessity for many project teams. It not only streamlines the design and integration process but also cuts down on implementation time when used with the right tool flows. The Mentor Graphics FPGA synthesis solution, Precision® RTL Plus, offers both a manual bottom-up methodology and a partition-based incremental flow for block-based design and implementation. It allows FPGA designers to cut down on run time while preserving quality-of-results (QoR) of unchanged design blocks
Code Coverage Explained: For DO-254 Projects
Level A/B designs governed by RTCA/DO-254 must have additional verification for added design assurance. DO-254 Appendix B specifies several methods by which this can be accomplished. Today, the most common method is "Elemental Analysis," which typically involves using code coverage to ensure that the verification activities exercise all the design code. The issue is that code coverage is not one thing, but rather an umbrella term that includes numerous code-oriented metrics. This paper explains each of those metrics, what is covered and what isn't, and how the Mentor Graphics functional verification tools can be used to easily generate these metrics during simulation.
Formal Verification for DO-254 (and Other Safety-Critical) Designs
Formal Verification (a.k.a., Formal Methods) is one of the few technologies mentioned by the RTCA/DO-254 document. It is listed as an example of an acceptable method for Appendix B "Advanced Verification" requirements for level A/B designs. However, many people (hardware applicants and certification authorities alike) do not have a good understanding of what Formal Verification is, how it works, and how it can or should be used within DO-254 programs. Using simple language, analogies and examples, this paper introduces Formal Verification in the context of its use for DO-254 and/or safety-critical programs, taking the ambiguity out of this powerful verification method.
Planning SystemVerilog Adoption
Design demands have grown exponentially over time as fabrication capabilities and geometry sizes have improved drastically. The verification methodologies have not kept up and not changed a whole lot over at least four decades. Different attempts have been made at advancements but the solutions were proprietary or left to user’s imagination, at best. SystemVerilog amalgamates these previously attempted, disjoint technologies by extending a well known design language - Verilog. However, adopting new verification methods often seems unmanageable. This paper provides a new way for digital design and verification groups to easily adopt SystemVerilog. The paper opens with a historical review of how transaction-level modeling (TLM) has been used for design, followed by an explanation of how SystemVerilog can be useful for taking verification to the transaction level. We will look at how the Open Verification Methodology (OVM) addresses the vastness of the SystemVerilog language. The paper will finally propose a “next-generation” approach to design and verification management using SystemVerilog to improve verification methodologies by a couple of decades.
Synthesis for DO-254 Design Assurance and other Safety-Critical Design Processes
RTCA/DO-254 (referred to as “DO-254”) is design assurance guidance for airborne electronic hardware. The Federal Aviation Administration (FAA), European Aviation Safety Agency (EASA), and other aviation authorities worldwide began accepting DO-254 as a means of compliance through Advisory Circular 20-152 in 2005. The guidance may be applied to PLD, FPGA, and ASIC design. Methodologies, tools, and flows can impact the success of any project. However, DO-254 projects have special considerations that make these decisions even more important. DO254 is causing many companies to re-evaluate their design methodologies and tools as these important factors can directly impact quality, productivity, schedule, budget, and certification.
Improving FPGA Prototyping with SystemVerilog
As ASIC designs have grown larger at a much faster pace than FPGA devices, often multiple FPGA devices must be used to prototype a single ASIC. The obstacle of using multiple devices is the task of connecting all of the logical blocks of the ASIC design across multiple FPGA devices. However, methods for logically connecting the design blocks have proven to be manually intensive and error prone. With the introduction of SystemVerilog, an evolutionary RTL language, and advanced mixed language synthesis tools such as Mentor Graphics' Precision Synthesis, the procedure for connection has been simplified.
FPGA Synthesis: Looking Beyond the Obvious
In many cases, design requirements refer to performance and area—the design needs to operate at a minimum frequency and naturally needs to fit into the selected device. Hence, designers or CAD managers looking to standardize on a synthesis flow tend to look for good out-of-the-box quality-of-results (QoR).
Often, to meet aggressive QoR goals, constraints need to be refined, optimizations must be enabled, or small portions of RTL may need to be re-coded—but without help from the tool it is difficult to identify when and where to make these changes. In other cases QoR goals may have been met but design changes are constantly being introduced, and new changes either degrade previous QoR results or runtime for each change delays project schedule. FPGA project managers must take into account these scenarios and consider how their synthesis flow addresses them.