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.
Despite the fact that much functional verification is performed at the RT Level, gate-level simulation is required as final sign-off to verify design characteristics that manifest only at the post synthesis netlist level. This requirement is critical even though gate-level simulation is slow and hard to debug. The expectation is that the output of RTL simulations will mostly match the output of Netlist simulations on the same design, but unfortunately that is not the case in reality.
The main culprit is X propagation. Gate-level simulation is handicapped by wide-spread X-pessimism, causing X’s to propagate pervasively. RTL simulation, on the other hand, can be inaccurate due to X-optimism. This paper focuses on the issues of X-pessimism at the netlist level. We define Xpessimism, discuss current solutions, and present a specific approach.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.