25 - 26 September, 2019

Radisson Blu Bengaluru

Bangalore, India

Event Details

MP Associates, Inc.
THURSDAY September 26, 4:00pm - 5:30pm | Robusta
Manu Chopra - Cadence Design Systems, India Pvt. Ltd.
Modern low power designs are logically split into multiple clock domains, power domains and reset domains. In this session we discuss some of the experiences and challenges faced with clock and reset domains - with methodology recommendations for effective verification.

9.1Exhaustive Reset Verification Enablement: A PCIE Reset Verification Case Study
Traditionally reset design and verification are done by design engineers’ and they are expected to follow some standard reset architecture guidelines to avoid any potential meta-stability issues. However, with the increased complexity of Client SoC design, the hierarchical reset architecture has also become very complex and increase in reset signaling complexity with the emergence of multiple reset domains in a device is creating new verification challenges that aren’t addressable by RTL simulations.. Therefore, there is a tangible need to provide automated, exhaustive structural and functional reset signaling checks. Using exhaustive reset verification in the Client PCIE End Point Subsystem provided a detailed coverage of all the metastability and reconvergence issues, reset domain crossing issues that could lead to silicon bugs while improving the quality of handoff to the backend team.
 Speaker: Rohit K. Sinha - Intel Technology India Pvt. Ltd
 Authors: Rohit K. Sinha - Intel Technology India Pvt. Ltd
Praveen Dornala - Intel Technology India Pvt. Ltd
9.2Our Experience of Glitches at Clock Trees, Reset Trees and CDC Paths
Introduction Implementation of a design from RTL to netlist introduces glitches on clock trees or reset trees. Clock domain crossings (CDC), if not verified appropriately, cause chip re-spins if detected late in the design cycle. To prevent this, implementing a rigorous approach to detect these potential problems early in the design cycle at the RTL level, and post synthesis at the gate level is mandatory. For low power designs, clock gating and reset gating are used extensively. When IPs from multiple sources are integrated, glitch-causing combinational logic can be introduced unintentionally. At the same time, CDC paths with multiplexers or combinational logic are prone to glitch defects introduced by synthesis. These glitches, pulses of very short duration, may be captured by a register when crossing clock domains, causing a functional failure. In this paper, we review the cause of these challenges and introduce a methodology to overcome these difficulties. Contributions CDC verification ensures that signals that cross asynchronous clock boundaries arrive complete and coherent in the receiv-ing domain. A flip-flop whose data or asynchronous reset input changes too close to the clock edge will enter a transitional indeterminate state whose duration is probabilistic. This transient indeterminate state is known as a metastable state. Many clock-boundary synchronization schemes exist to ensure that simple one-bit signals, all the way to multi-bit data busses, and even signaling protocols, can be transferred accurately despite this metastable behavior. The proper design of these syn-chronization mechanisms to ensure that the indeterminate state is not sampled more frequently than system failure rates al-low are well documented and out of the scope of this paper. Flip-flop storage devices also have requirements for minimum active pulse-widths for clock and reset signals that, if violat-ed, will result in metastable behavior. Synchronization designs do not typically ensure correct behavior when this condition occurs as these types of issues are not limited to clock domain crossings. Traditional CDC verification evaluates the design at a Register Transfer Level (RTL), representing registers (flip-flops) and the functional logic between them. At this level, clocks and resets can be easily specified, constrained and even inferred. Formal-based CDC algorithms exhaustively evaluate the RTL and identify CDCs, infer synchronization schemes and ensure that the design has integrity. However, traditional CDC verification also tends to focus specifically on the clock domain crossing and the synchronization schemes themselves, and does not focus on the integrity of the clock or reset signal specif-ically. Our designs tend to be extremely complex. Aggressive power management techniques are employed that impact clocks and resets via gating functions as well as via power domain isolation techniques. IPs designed for generic re-use were designed with different methodologies in mind. Performance and latency requirements cause us to minimize the number of clock cycles required to move data. With many clocks in the design, clock domain crossings designed for minimal latency, and a highly-complex functional environment, the challenges of CDC at the RTL level are significant enough. But generally speaking, RTL-based CDC analysis will not find all issues that can arise from this complexity. Why? RTL is an abstraction and isn’t built in silicon. There are several steps to production from RTL. Designs are synthesized into gates, modified to add power reduction or isolation schemes, and to add test circuitry. Levels of abstraction are removed, exposing potential abstraction modeling inaccuracies. The implementation process is constrained to minimize power and area, and maximize performance. In the end, the design targeted to be built doesn’t entirely match the one verified in RTL. Yet RTL analysis is the fastest, most efficient and easiest to debug. The objective therefore is to identify constructs at the RTL level that are susceptible to implementation-based issues later so that these issues can be found and fixed in RTL. We run checks to identify issues in clock integrity, reset integrity, and to find glitches in data transitioning through clock domain crossings. 1. Clock Integrity - We specifically analyze clocks looking for functional clock manipulations which may later be implemented by gates due to synthesis that can create glitches. Examples of these types of issues are: a. Combination feedback loops in clock logic created by the interconnection of unrelated IP, clock control and gating circuitry, and the like. b. Clock enable signals generated by combinational logic and not connected to a latch and therefore not held during the active phase of a clock c. Forked and re-converged clock signals through combination logic ultimately driving a storage element. d. Clock and reset pins of a storage element being driven by the same signal e. Clocks driven by inappropriate combinational gates known to generate glitches such as XOR or XNOR gates. 2. CDC Data Glitches – When implementing combinational logic functions with logic gates, the optimization algo-rithms of synthesis tools can create circuits that are capable of generating glitches on outputs as inputs change. This is due to the nature of different delays through logic gates and their inter-gate routes. This effect is normally not relevant in synchronous designs. However, in the case of asynchronous domain crossings, the data or reset pin on the receiving clock domain’s flip-flop may change due to the glitch too close to the active edge of the receiving clock. This creates a new CDC violation in a paths that was error-free in RTL. These types of implementation is-sues demand that CDC analysis be done on the netlist prior to tapeout to ensure that the design will work as ex-pected when built. One such example is below in Figure 1 below, showing the functional RTL representation. During synthesis, the synthesis tool optimizes for power, performance and area constraints as shown below in Figure 2 by replacing the multiplexer function with an AND-OR structure and incorporating the functional AND from the RTL source into the optimized AND-OR network as well for minimal latency. This implementation is functionally identical but has induced a CDC violation due to timing-based race conditions through this new structure, in a way that, should the flip-flops tx1 and rx_en2. Our methodology uses CDC verification to identify these issues post-implementation, to ensure working silicon. 3. Reset Integrity - We specifically analyze resets looking for functional reset manipulations which may later be im-plemented by gates due to synthesis that can create glitches. Examples of these types of issues are: a. Resets driven by inappropriate combinational gates known to generate glitches such as XOR or XNOR gates. b. Unexpected latches or three-state logic within a reset tree. c. Combinational logic in the reset path that may generate glitches as in Figure 3 below d. Forked and re-converged reset signals through combinational logic paths that may create glitches. Figure 3 Glitch soruce in reset path Current Results & Conclusion: With these enhanced checks for Clock Integrity, CDC Data glitches, Reset Integrity we can make sure the design is free of the glitches in clock, CDC paths and in resets. Unearthing glitch earlier in the design cycle will help to speed up RTL quality and avoid costly iterations later in the design cycle. The ROI of carrying out these additional checks is justified by the confi-dence the design teams gains after running the checks. References: [1] Jackie Hsiung, et al., “Preventing Chip-Killing Glitches on CDC Paths with Automated Formal Analysis,” DVCon 2018 [2] Anwesha Choudhury, Ashish Hari, “Accelerating CDC Verification Closure on Gate-Level Designs”, DVCon 2017 [3] Ping Yeung, “Five Steps to Quality CDC Verification,” Mentor Graphics, advanced verification white paper.
 Speaker: Jebin Mohandas - Intel
 Author: Jebin Mohandas - Intel
9.3Scalable Multi-Domain Multi-Variant Reset Management in Complex Verification IPs
Reset Modeling in verification IPs is a crucial part of functional verification and its complexity increases with the architecture complexity. Reset testing might vary from resetting the complete environment (global reset) to resetting only a set of components (domain-specific reset) in the environment. With the growing complexity of protocols and design features, multiple variations of resets and other power-related features need to be tested and modeled in verification IPs too. A standardized, scalable and protocol-independent approach is needed to handle all the possible complex scenarios to achieve a well synchronized reset across the testbench. This paper will present our technique of standardizing the reset management by deploying a centralized reset_handler component which handles and manages all the possible reset conditions at both levels, global as well domain-specific. This paper will also present the extensibility of the proposed technique to handling different kinds of reset using the proposed reset_handler.
 Speaker: Kaustubh Kumar - SiliConch Systems
 Authors: Kaustubh Kumar - SiliConch Systems
Munnangi Sirisha - SiliConch Systems
Lokesh Kumar - SiliConch Systems