Skip to content
White Papers
Meridian RDC
Achieving RDC Sign-off with Parallelization of Hierarchical Flow
Over the past decade, the move to System-on-Chip (SoC) design has dramatically increased chip sizes. An SOC can have many subcomponents with complex interactions and can stress capacity of verification flows. There can be a proliferation of complex reset interactions. Ensuring that a complex SoC works according to specification requires design and verification teams to spend an increasing amount of time on verification of these resets and their interaction.
This whitepaper starts with a discussion of hierarchical methodology to verify Reset Domain Crossings. It then elaborates on some of the requirements for such a methodology.
Making Sure Resets Don’t Kill Your SoC
The primary purpose of reset in a digital design is to initialize the hardware for system operation by forcing the design into a known state. Verifying design initialization is a critical part of design verification as failures can lead to functionality hazards or design re-spins. With increasing design complexity, reset design architecture is also becoming more complex.
Modern SoCs often have multiple power-on-resets that stage initialization of the chip when power is turned on. Staging minimizes simultaneous switching that can cause other issues. In addition to power-on-resets, there are also software resets, debug resets, lowpower resets, low-voltage resets, global resets and local resets. All these resets can be independently asserted and de-asserted at any time during chip operation.
This paper will review the fundamentals that engineers follow in designing complex reset architectures. It will then elaborate some of the failures that can occur if reset design fundamentals are not followed.
Meridian CDC
This whitepaper begins by discussing why a comprehensive hierarchical methodology is needed to verify Clock Domain Crossing (CDC) aspects of these complex billion-gate SoCs.
The paper then elaborates on some of the challenges created by such a methodology. Based on these challenges, the paper summarizes a set of requirements for an efficient and effective solution.
CDC Methodology for Fast-to-slow Clocks
CDC checking of any asynchronous clock domain crossing requires that the data path and the control path be identified and that the receive clock domain data flow is controlled by a multiplexer with a select line that is fed by a correctly synchronized control line.
Meridian CDC identifies all the data and associated control paths in a design and will ensure that the control signals passing from a transmit clock domain to an asynchronous receive clock domain are correctly synchronized. This paper discusses the application of three techniques: structural checking, formal checks and simulation-based injected metastability checks.
Clock Domain Crossing Demystified
With the increasing trend towards SOCs, designs with multiple asynchronous clock domains are becoming commonplace today. The design of asynchronous clock domain crossing (CDC) interfaces is required to follow strict design principles to ensure reliable operation in the presence of metastability.
With the emergence of CDC verification tools, users have a way to verify their designs. However, first generation CDC tools provide inadequate support for a top-down, bottom-up CDC verification methodology. Also, extensive manual setup and signoff requirements create serious deployment limitations. These factors cause inconsistent usage of the tools and wasted engineering resources without covering the CDC failure risk.
Challenges in Verification of CDC
Emerging systems have multiple dimensions of complexity when it comes to making them CDC-safe. First, the number of asynchronous clock domains in designs can range from the tens to the hundreds for complex systems with many components. Next, the master clock frequencies vary per component. It is not uncommon for the ratio between the fastest and the slowest clocks to be greater than 10.
Additionally, the clock frequencies themselves can change dynamically during the course of chip operation to save power. As a result, CDC verification becomes critical to ensure that metastability is not introduced in the design.
Clock and Reset Ubiquity: A CDC Verification Perspective
Today’s SoC integrates a collection of peripherals, memory, graphics, networking and I/O components that originate from a multitude of sources. It could comprise designs from within the company, from other companies or from third-party IP vendors. These independently developed components come together to enable a rich feature set for the SoC. However, accompanying this abundance of features is a significant amount of complexity that needs to be correctly and efficiently handled to render the integration successful.
One such source of complexity is that components operate at clock frequency ranges that may be very different from those of their counterparts. The existence of these multiple clock domains and the need for them to exchange information creates a hotbed for CDC bugs to thrive. As a result, CDC verification becomes critical to ensure that metastability is not introduced in the design. In this paper, we provide several situations with varying set of examples that showcase the challenges in CDC verification.
True Multimode CDC Sign-off
The shrinking of process technologies has dramatically increased the amount of logic in a single chip, as typical System-on-Chip (SoC) designs integrate functionality that was once part of many discrete chips. This increased complexity and configurability in SoCs translates to a large number of operating modes and scenarios. There is also a proliferation of internal and external protocols and aggressive power requirements that lead to an explosion in the number of asynchronous clocks.
This paper starts by discussing typical approaches designers currently take to verify Clock Domain Crossing (CDC) aspects of these complex SoCs. It then elaborates on some of the risks associated with these approaches, and creates a set of requirements for CDC verification that can mitigate these risks and enable true multimode CDC sign-off.
Ascent Lint
Setting a New Lint Benchmark
This paper describes how Verilog, SystemVerilog, and VHDL design and verification can be accelerated and enhanced at all stages of development by Ascent Lint.
It also describes how Ascent Lint has set a new benchmark for linters by focusing on both high-value rules and performance and on the overall user experience from start to finish.
Ascent AutoFormal
3 Ways Two-Phase Linting — RTL & Automatic Formal — Cuts RTL Verification Time
This white paper covers in detail how RTL structural linting and formal linting complement one another to provide a complete two-phase RTL linting sign-off solution. Together they detect both logical and sequential functional bugs prior to simulation, reducing overall RTL verification time and effort.
Recent breakthroughs in capacity/performance and increased automation have made it feasible for designers to now also run formal linting to catch sequential control logic bugs during design — with minimal time investment and no manual writing of assertions. Furthermore, formal linting advances in root cause analysis have dramatically reduced the debug time of complex sequential issues.
Two-phase linting is part of the industry move to ‘shift left’ to find bugs earlier in the flow. Catching errors before simulation time reduces iterations because you start with a higher quality RTL.
Bulletproofing FSM Verification: Automated Approach to Detect Corner Case Issues
Comprehensive verification of Finite State Machines (FSMs) is essential because they control most aspects of the functionality of a design. While simulation is irreplaceable for verifying functionality, it is only as good as its stimulus.
This paper discusses how to automate formal verification of corner case chip killers of an FSM design – namely that the FSM will not lock up, is not subject to metastability on reset deassertion, and that synthesis directives hold true.
Sign-off Flow
The Next Step in High-Reliability FPGA Sign-off
FPGA designs are complex devices, with complex verification issues. Today, FPGA designs are found throughout many mission critical industries such as satellite systems, avionics, self-driving cars, military guidance systems, and medical electronics. Device failures in these applications are simply not an option, and could result in lost deployment windows, costly late market entries, irreplaceable hardware systems rendered useless, and even death.
With FPGA design complexity on part with their ASIC brethren, the verification challenges experienced by FPGA users may well exceed the traditional utilities available to them. This paper examines some of the specific challenges faced with FPGA designs, as well as proven methods and tools to ensure verification success and full chip sign-off.