Skip to content
Multipolicy SoC Linting Methodology
Case Study by Martin Maue, Sr. Staff Engineer & Team Leader, Dream Chip
Case Study Overview
Martin Maue discusses how Dream Chip implemented a multipolicy methodology using Real Intent Ascent Lint to reduce engineering verification time.
I. SoC sign-off across IP developed under differing guidelines
I will share Dream Chip’s SoC RTL linting sign-off methodology using Real Intent Ascent Lint’s multi-policy linting functionality.
Our SoCs are highly complex, consisting of a large variety of internal and third-party IP that were developed using different coding rules – and require different rules for sign off. While new IP must be exhaustively checked, pre-existing IP needs only basic design integrity and connectivity checks.
This created a challenge for us when we want to run RTL linting sign-off on our full SOC, as applying the same master ruleset across all of our IP would create a lot of noise in our violation reports. Reviewing all the extra violations and applying waivers to them would take a lot of work.
If instead we black boxed some of the IP, we might miss critical issues, such as the IP’s connectivity. And enabling basic design integrity checks gives us confidence in the use of the IP that we may not be as familiar with.
Dream Chip modified its RTL linting sign-off approach to efficiently address these linting sign-off challenge.
II. Dream Chip’s Multipolicy Linting Methodology
We have three main categories of linting policies to address with multipolicy SoC linting.
- Master SoC policy rules, which covers all of our current SoC guidelines. This ruleset is in line with our coding rules for synthesizable code. Our newer IP is developed using these guidelines.
- Policies for older internal IPs, where we disable some of the rules in our master ruleset, because the IPs were developed under older guidelines, including naming styles.
- Policies for third party IP, for which we disable naming conventions as well as certain design guidelines where we don’t have all the insights. We must still check for critical rules. For example, multiple driven wires would be a showstopper as it would mean that either the IP is configured incorrectly, or the IP has an issue.
One multipolicy linting run covers entire design
Dream Chip now deploys a multipolicy SoC linting methodology using Real Intent Ascent Lint. Our steps are as follows:
1. Define our master SoC level master policy in line with our rule set; this is a superset of all the rules/policies.
2. Enable the master ruleset for the SoC level and for our more recent internal IP.
3. Disable specific policy subsets for our older internal IP and/or third-party IP.
4. Run Ascent Lint for sign-off
III. Multipolicy SoC Linting Example Design Hierarchy
This graphic shows a representative design hierarchy. “SoC” refers to the top-level SoC, where the full rule set is enabled. Below SoC, we have IP modules B, C & D instantiated, where we customize which linting rules we want to exclude/disable.
Note that every time we set a policy at the top of a subsystem, that policy is inherited by the entire subsystem.
– Module B. We disabled rules #1, #2, and #3, which means those same rules are also disabled for modules E, F, & G.
– Module D. We disabled rules #1, #2, and #4, therefore, those same rules are also disabled for modules G & H. (Note that G also has rule #3 disabled, from hierarchy B)
– Module H. We included rule #2 and excluded rule #5. This means that H has rules #1, #4, and #5 disabled.
IP rule policy examples:
– exclude style rules
– keep connectivity rules
– keep clock & reset rules
IV. Case Study: Error from wrongly configured IP
This approach enabled us to identify a bit width mismatch error for IP that was configured using incorrect parameter settings.
We achieved a 5X improvement in simulation run time and turnaround time for verifying all the data paths — by deleting and grouping data paths modeling files by function.
Design Error: Bit width mismatches (rule PORT_BITLEN) are missed, when the IP is checked separately, but not in exact configuration as instantiated
V. Conclusion: One SoC linting run supports all rule policies
Dream Chip has seen several positive outcomes using this low noise multipolicy SoC linting methodology with Ascent Lint.
1. Dream Chip now only needs one full SOC level lint run to find all issues through the entire design hierarchy.
2. When we update any IP in the design, we simply kick off one lint run. This saves us effort as we no longer need a separate lint run on the IP with different rules.
3. Noise reduction without missing important issues — when we would check third party IP using our master ruleset, we would get 100s of false violations due to the different rules used during development. Our engineers no longer have to review and waive these. Yet we still get the desired connectivity and basic design integrity checks throughout.
4. Because we have Jenkins setup checks running in the background, triggered by either a design change or running at regular time intervals, it is easy to flag additional errors.
Ascent Lint’s multipolicy linting performance is very fast. The runtime was only 16 minutes for our entire SoC, which includes several processors.