Most functional verification is done before the RTL is handed off for digital synthesis. Gate-level simulations take longer and are hard to debug, but still needed to verify some circuit behavior. Ideally, the output of the RTL simulation will match the output of gate-level netlist simulation after synthesis. But that is not typically the case. Besides the obvious things verified in your gate-level simulations, there are always unknown values (Xs). Some will not be seen in the RTL due to X-optimism, but there will be additional Xs in the gate-level simulations due to X-pessimism.
X-optimism in RTL and other generic issues around unknown states are discussed in more detail in the paper ‘X-Propagation Woes – A Condensed Primer‘. Some basic familiarity with the concept is assumed here.
This paper focuses on X-pessimism at the netlist level. It discusses some current techniques and their limitations, and then describes a more efficient X-pessimism strategy based on Real Intent’s Ascent XV. (more…)
Recently I came upon an article by Ankush Sethi of Freescale on the importance of avoiding bad design practices that lead to glitches in clocks which result in asynchronous behavior. He points out:
It is very important to make digital designs free of any clock or data glitches to ensure correct functioning. There are many cases where such issues have caused functional failure, or increased design time through incurring extra debug effort. Hence, it is very important for a designer to take care of such issues at the earliest stages of design once flagged by a tool or gate-level synthesis.
With the increasing complexity of SoCs, multiple and independent clocks are essential in the design. The design specifications require system level muxing of some of these clocks before they are sent to actual IP. Also, to save power, clock gating cells are inserted in clock paths. While implementing these muxing and gating cells, a designer tends to make mistakes that can lead to glitches. A glitch on a clock signal exposes a chip (or a section of a chip) to asynchronous behavior. A glitch-prone clock signal driving a flip-flop, memory, or latch may result in incorrect, unstable data. This paper discusses structural faults that can lead to glitches in clocks. Also, some bad design practices that lead to glitches in data are discussed. (more…)
At DVCon’16, Mark Litterick presented a paper and presentation on “Full Flow Clock Domain Crossing – From Source to Si.” Here is the abstract for the paper:
Functional verification of clock domain crossing (CDC) signals is normally concluded on a register-transfer level (RTL) representation of the design. However, physical design implementation during the back-end pre-silicon stages of the flow, which turns the RTL into an optimized gate-level representation, can interfere with synchronizer operation or compromise the effectiveness of the synchronizers by eroding the mean time between failures (MTBF). This paper aims to enhance cross-discipline awareness by providing a comprehensive explanation of the problems that can arise in the physical implementation stages including a detailed analysis of timing intent for common synchronizer circuits.
Mark works for Verilab as senior verification consultant and holds the position of fellow. He is based in Munich, Germany. To see more of Mark’s technical papers, check out his profile page on the Verilab web-site.
Even though, you may have signed-off for CDC at RTL, logic synthesis, design-for-test and low-power optimization tools can break CDC at the gate-level, the physical implementation stage of design. Real Intent’s Meridian products provide clock-domain crossing verification and sign-off. Our most recent offering is Meridian Physical CDC and provides sign-off at the netlist level of the design. It uses a mix of structural and formal methods to identify glitching and other errors that break the correct registration of signals crossing clock domains. (more…)
Recently, I interviewed Vikas Sachdeva, Sr. Technical Marketing Manager at Real Intent where we discusse why gate-level CDC verification is necessary, what are some of the failure modes that can occur, and why Meridian Physical CDC is the right tool to do gate-level sign-off. You can see the video below. You can also find more information about Meridian Physical CDC here.
Part one of this article focused on the issues of X-pessimism at the netlist level and why the current solutions are inadequate. In In part two, we look at how the Ascent XV tool correctly addresses X-safe verification.
If a node is determined to be 1(or 0) pessimistic, that means its real circuit value is 1(or 0), but simulation produces an X. A pessimistic simulation value can be corrected by forcing a 1(or 0) on the node until the conditions for pessimism no longer hold, at which time, it is released. This does not mean that all X’s can be arbitrarily forced to a known value. Only X’s that result from pessimism should be forced, and they must be forced to represent the deterministic value that real hardware would see and released immediately when the pessimism stops.
Ascent XV-netlist makes your simulation hardware accurate by appropriately correcting pessimism. Ascent XV statically identifies the potentially pessimistic nodes and then uses that information to create SimPortal files that augment gate-level simulation to correct X-pessimism on the fly. By doing the analysis statically before the simulation starts, the number of nodes that must be analyzed during simulation is significantly reduced. Also, the X-analysis during simulation can be reduced to a table look-up when the potentially pessimistic node has an X-value. The SimPortal files monitor the potentially pessimistic nodes in the design on the fly, independent of the testbench. (more…)
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis because gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Ideally, the output of the RTL simulations will match the output of gate-level netlist simulations on the same design after synthesis. And why wouldn’t they? Besides the obvious things that are being verified in your gate-level simulations, there are also unknown values (X’s) that were not seen in RTL due to X-optimism, and additional X’s in the gate-level simulations due to X-pessimism. Part one of this article focuses on the issues of X-pessimism at the netlist level and why the current solutions are inadequate. (more…)
Multiple asynchronous clocks are a fact of life on today’s SoC. Individual blocks have to run at different speeds so they can handle different functional and power payloads efficiently, and the ability to split clock domains across the SoC has become a key part of timing-closure processes, isolating clock domains to subsections of the device within which traditional skew-control can still be used.
As a result, clock domain crossing (CDC) verification is required to ensure logic signals can pass between regions controlled by different clocks without being missed or causing metastability. Traditionally, CDC verification has been carried out on RTL descriptions on the basis that appropriate directives inserted in the RTL will ensure reliable data synchronizers are inserted into the netlist by synthesis. But a number of factors are coming together that demand a re-evaluation of this assumption.
A combination of process technology trends and increased intervention by synthesis tools in logic generation, both intended to improve power efficiency, is leading to a situation in which a design that is considered CDC-clean at RTL can fail in operation. Implementation tools can fail to take CDC into account and unwittingly increase the chances of metastability. (more…)