Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
In parts 1 and 2 of this series we talked about the challenges of clock domain crossing (CDC) and reset domain crossing (RDC) for developers of multi-billion-gate ASICs. We are now going to discuss some of the challenges arising from static linting of code and how to address them.
Increasing ASIC size and complexity are demanding more from designers and the tools they use. At the same time, development lifecycle timescales are getting tighter, which in combination is pushing designers and tool vendors to innovate in this well-established area of methodology and tooling.
Shift-Left with Efficient Code Linting
Linting—automated source code checking for errors—has been an established part of the hardware development lifecycle for decades. As with CDC and RDC, however, new challenges of scale and complexity are presented by modern multi-billion gate ASICs. This is driving the need for more capable lint tooling that will help shift-left the entire development lifecycle by finding and eliminating design problems efficiently and early.
To explore these challenges, we need to understand how developers are approaching things at an abstracted level. In short, they want to be able to assess design maturity and the impact of avoidable downstream errors as early as possible during the RTL design phase.
Typically, large ASIC designs are built from the integration of third-party IP, re-use of in-house IP, new IP components, plus system-level integration IP to stitch it all together into a system-on-chip (SoC). Linting must be applied in all cases. Incoming IP blocks may already be lint-clean; however, any new RTL code needs to be developed as lint-clean at the earliest opportunity. As with many hardware development workflows, it is highly desirable to begin the process of lint checking at the earliest point possible and converge quickly towards a stable lint-clean codebase so that the code is signoff-ready well before you reach the signoff point in the development lifecycle. This spiral-design flow approach—more commonly known as shift-left—leads to earlier delivery and avoids late signoff surprises. Find the problems and eliminate them early.
To achieve a left-shift, chip designers want to be able to perform many complex tasks early in the design process. This could involve more complex checking within the RTL and ensuring that their RTL is more aligned with the downstream synthesis engines, for example. Designers also want the RTL to be “friendly” and interoperable with various simulators and for the RTL to be compatible with equivalence checkers. Quite a tall order. Modern linting goes well beyond RTL semantic rule checking and extends to synthesizability checking, structural analysis, and netlist/electrical rules checking.
So, the challenge is to find and fix bugs at the source in the quest to create correct-by-design RTL. And all of this must scale to modern multi-billion-gate ASIC designs.
Managing Rule Sets
Lint tools operate using sets of rules (rule sets). Development teams, however, are typically challenged in terms of the time needed to create, manage, and curate these rule sets. On top of that, this is a specialized skill set which requires expertise smaller companies may not have, or want to invest in. As a result, they may be looking for an off-the-shelf package to provide them with the generic rules to get started. Larger companies often have their own in-house lint rule sets developed over many years. These internal rule sets often represent a significant engineering investment to develop and curate them as internal standards.
Third-party or industry-standard rule sets can accelerate lint workflow bring-up for both larger and smaller design teams with a much lower barrier to entry cost. Synopsys GuideWare methodology documentation and rule sets serve exactly this purpose and enable developers to jump-start with this technology; then, further rules can be developed as needed. The goal is to get to RTL hand-off in at least 80% of cases. This minimizes the need for real experts to create, manage, and curate rules. Smaller design teams can experience a real productivity boost, not to mention a quality step-up. Regular updates from Synopsys keep them ahead of the complexity curve. Designers have the option to integrate Synopsys IP (which is certified lint-clean) and design reuse compliance checks (STARC and OpenMORE) which are captured in GuideWare, making it compatible to industry standards.
What to Do About Dead Code?
Most designs will contain some dead code or unreachable code at some point in development, and in many cases this code will survive into production. Why is that? When complex designs evolve during development, RTL code changes as bugs are fixed, features are added, reusable blocks are integrated, or code is optimized to achieve power and performance objectives. Sometimes there is a build-up of technical debt for which there is insufficient time to clean up code due to product delivery timescale pressure.
For example, late in the cycle, some designers might decide they are too late in the process to make changes and decide to leave dead code; overall the code is functional, but it may end up containing a lot of dead code. Not exactly a clean design.
Alternatively, what happens when the designer is unsure whether to trust the tool to identify dead code? If the conclusion is that they don’t trust it to do so, they may leave the code in “just in case.” In practice, this is not very likely as most users follow a zero violations policy which says, “Fix a lint message, or waive it.” This practice helps get around the issue; however, it is important to be able to identify dead code and decide how to deal with it.
Static linting tools that leverage formal engines, such as the Synopsys VC SpyGlass™ Lint, are highly efficient at identifying these areas of concern. Designers then have a number of options:
- Update the RTL code to remove dead code. While this is the cleanest solution, it may require some effort to re-factor the code followed by functional verification. This approach provides a clean lint result and removes coverage holes from coverage analysis.
- Comment out dead code with informative comments for future reference. This approach may still require functional verification, but provides a clean lint result and removes coverage holes.
- Waive the dead code in the lint waiver file. The dead code is acknowledged but deemed to be safe and the RTL codebase remains unchanged. Coverage holes would persist.
Understanding Design Complexity
Complex designs contain complex bugs, which in turn might lead to critical bug escapes and quality issues. Developers don’t typically set out to build complex code; they strive for clean and elegant design that is intrinsically well-constructed, intuitive, and easy to understand and maintain. However, we all recognize that code quality can deteriorate over time for multiple reasons. Technical debt can accumulate as bugs are fixed sometimes in less-than-ideal ways, or the intended behavior becomes obfuscated though optimization, code-churn, and maybe feature-creep. Suddenly you have complex RTL and the development team admits they no longer fully understand how the code works. Extreme verification may indicate that “yes, it’s complex, but it apparently works.” Experienced developers understand that this is a risky strategy and it is far better to address areas of complexity wherever possible and as early as possible.
Measurement and visualization of code complexity can really help developers to ‘see’ where the complexity lies in their code and use that knowledge to assess and reason about complexity build-up. Maybe re-factor some areas of code, or trade-off performance and function in areas where the complexity risk is too high.
While robust peer code reviewing is a best practice that all design teams should be adopting, Synopsys VC SpyGlass Lint gives developers measurable insights into code complexity that are hard to achieve with other methods. The tool exploits formal engines to deliver functional analysis capabilities that will analyze complexity and present the results to the user via dashboards.
Yet Again, the White Noise Problem
We previously talked about the white noise problem in earlier blogs about CDC and RDC. Guess what? The same challenge is here with linting workflows. The big problem with running many lint check rules is that they produce too much noise, creating a risk that the user will overlook an important violation. There can be huge numbers of violation messages when linting multi-billion-gate designs, so how do you reduce that noise and help the user see meaningful messages? How do you qualify messages to ensure that only legitimate violations are flagged and reported to the user and assist them to accelerate the triage of the violation output file?
VC SpyGlass Lint exploits formal engines to assist with this problem. The user does not need to be aware of this, nor do they need to be a formal verification expert user. It’s formal under the hood. There are more than 5,000 checks built into the tool and Synopsys keeps adding more.
Driving for Earlier Signoff – Why Functional Linting?
Functional linting leveraging push-button formal allows users to test for functional and coverage issues early, before testbenches are available, saving time and shifting the process left. Functional linting is good at detecting control issues such as:
- FSM deadlocks
- Unreachable state checks
- Coverage issues such as constant nets
- Dead code checks
- Array bound violation
In conclusion, tools such as Synopsys VC SpyGlass Lint with functional analysis enabled by formal engines allow users to make earlier judgements about the maturity of their design. For example, they can determine whether the complexity delivers the required results and avoids costly investments in tools, time, and effort further downstream in the design process. This all adds up to faster chip design signoff.