Skip to content
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.
(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.
- 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.
- 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.
- 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.
- 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
Their initial RDC verification analysis (with design constraints):
- The competitive commercial tool reported more than 400,000 violations.
- Meridian RDC’s initial analysis showed only 16,000 violations.
Julien stated that was an impressive improvement for Meridian CDC for the same amount of work.
After using some of Meridian RDC capabilities to optimize the RDC analysis, STMicroelectronics was able to reduce the number of Meridian RDC’s reported violations to only 8,000 – and without requiring the earlier design constraints.
Using Waveforms Reduces Violations by Additional 2X
Julien stated that Meridian RDC enabled them to use waveforms to specify scenarios on resets and clock constraints for their resets.
This is what reduced their noise by an additional factor of 2X over the initial results.
Using scenarios to reduce violation count
Julien setup TcL code to specify this reset scheme, which Meridian RDC then translated into a proper wave form and scenario.
He noted that setting up of this kind of constraint could be a bit error prone, as you must take your specification and manually add the constraints.
However, he commented that Meridian RDC provided a way to quickly check if the designer was mistaken, so it was not too big of an issue.
RDC Verification Schematic Viewer
They had some annotations for the schematic viewer.
And the indicator on the schematic helped to quickly understand violations and very quickly locate the issues.
Meridian RDC Tool Performance: 4X Faster
Julien note that the biggest improvement he saw was with the runtime.
Because ST was running approximately the same checks on Meridian RDC as on the competitive tool, Meridian’s typical 4X reduction in time and RAM usage was “absolutely astonishing”.
Conclusion — Other Useful Features
For his conclusion, Julien noted other useful Meridian RDC features.
- The constraint generation will detect and suggest configuration signals. This is quite useful because after you have your setup constraints you can spend lot of time looking for the configuration signals and trying the settings for those signals to match your specification — which is very time consuming. Having a tool which can suggest the signal is a great improvement.
- The ability to do multi-scenario runs is also a nice feature, because in addition to specifying a reset scenario with waveforms, you can also specify multiple scenarios and check them at the same time. I.e. if you check two scenarios, it won’t take you twice the time as it does for one scenario. It is always quite useful to “re-use” the run time.
- The status system with fixed status, deferred status, and waived status associated with a dashboard, is also quite useful to see the progress on your verification task – you can see if you’ve done half of the work or a tenth of the work. It’s quite useful to report back that you are on time with schedule.
- The session system allows to have several runs and parameter sets at the same time without worrying too much about constraints setup and it’s also quite useful.
- Meridian RDC has an advanced filtering feature which helped him check how many violations he had coming from a specific reset domain or from one clock domain going to this clock domain.
Julien indicated that knowing how many violations he would have coming from various blocks helped him to identify problematic blocks, resets, or situations — to hopefully to resolve them faster.