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

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.

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.

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.

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.

Many folks stumble on very similar issues when they begin their journey towards creating and executing DO-254 compliant design projects. The good news is that each of these issues has solutions. Understanding these common pitfalls, and proactively addressing them before they cost a project time, resource and certification risk, is essential. Some of these common pitfalls, along with advice for addressing them (based on learnings from successful DO-254 programs), are described in this paper.