ST Microelectronics: RDC Verification on CPU Subsystem Using Meridian RDC

Executive Summary: Case Study by Julien Faucher & Jean-Christophe Brignone of STMicroelectronics at the 2019 Design Sign-Off seminar.

Meridian RDC

Case Study Presentation Overview

Julien Faucher presented a case study by Jean-Christophe Brignone and himself on STMicroelectronic’s domain crossing policies, with a goal to have full CDC/RDC coverage, with no design bugs, and no waivers unless there was proper justification.

Julien also covered RDC verification benchmark data for Real Intent Meridian RDC and a competitive tool on a dual CPU subsystem with 150,000 gates, 15 clock domains,  ~25,000 CDC paths and ~450,000 RDC paths.

Meridian RDC achieved a 25X reduction in noise, with a typical 4X reduction in runtime and RAM usage compared with the competitive tool.

Download STMicroelectronics Case Study PDF

(The PDF version of the RDC Verification case study has additional details.)

STMicroelectronics Overview

STMicroelectronics is among the world’s largest semiconductor companies, serving around 100,000 customers globally with approximately 50,000 employees and 7400 people in R&D. Our mission is to be everywhere that microelectronics makes a positive contribution to people’s lives.

STMicroelectronics’ primary end markets are automotive, industrial, personal electronics, and communication equipment, computers & peripherals. These are consumer electronics and all industrial, in almost every field.

CDC & RDC Verification Checks Flow for Multi-processor Subsystems

Julien Faucher discussed ST Microelectronics’ check flow for a multi-processor subsystem.

He said that ST’s main goal to have full CDC/RDC coverage, with no design bugs, and no waivers unless there is proper justification.

ST requires that their RTL design teams provide a full synchronizer list. They must check for all clock domain crossing (CDC) and reset domain crossing (RDC) structural rules in the ST reference template.

Their gate level design teams must check the glitch rule subset and integrity MTBF of the reference templates.

CDC & RDC Verification Primary Goals

To fulfill this mission, ST has the following goals:

1. Generate and define setup constraints that properly define clocks to maximize our CDC and RDC coverage with minimal noise.

2. Properly configure our CDC and RDC sign-off tools to be sure that they properly check all the required items, such as synchronizers and glitch prone cells.

3. Define design constraints that are functionally constrained by clock configuration signals and reset configuration signals.

ST’s CPU RDC Verification Flow

ST’s flow is constraint-based; however, it is not based on the SDC constraints that might come from the STA team.

They want to create a whole set of constraints to be sure that their verification is different from the STA verification, so that they don’t have any issues hidden by the STA constraints.

  1. They start with the RTL hardware descriptions, gates, tool parameters, and setup constraints that might be functionally generated by the RDC verification tool or by the documentation of the design.
  2. They perform a setup check to be sure that our setup is done correctly. They go back to the setup constraint anytime it is needed.
  3. They go to the RDC structural check with design constraints to say that a signal or a reset crossing is not a problem in the functional mode.
  4. At that point, ST Microelectronics considers that the entire check to be complete. (They only use formal verification in very rare cases that are critical.)

ST’s CPU Subsystem Testcase

STMicroelectronics benchmarked Real Intent Meridian RDC against a competitive commercial RDC tool, running a flat (non-hierarchical) check for both.

The test case Julien discussed was a dual CPU subsystem with 150,000 gates. It had 15 clock domains and around 25,000 CDC paths and approximately 450,000 RDC paths. He said CDC and RDC checks were mandatory for that level of complexity.

Benchmark Results: Meridian RDC had 25X Less Noise