Improving Predictability Through Design Solutions Methodologies

“Plans are useless, but planning is indispensable.” – Dwight D. Eisenhower

Our first article called for the need to change how we think about verification. In this follow-up, we dive deeper into the tools needed for today’s verification.

Project milestones are destined to move. Development estimates are rough and almost always optimistic. Each development stage contains interdependencies and inefficiencies that contribute to schedule unpredictability. RTL delivery to testbench, testbench bring-up, RTL integration, implementation, emulation, and firmware hand-off all line up with unpredictable overlaps and unpredictable interactions, making for a gauntlet of scheduling pitfalls.

Experienced project managers in mature flows use metrics to help gauge progress to schedule and adjust on the fly. However, sometimes even well-known metrics can’t provide the detail needed to improve predictive capability.

For example, how can code quality be measured before testbench availability? Lines of code are tracked, and rate of change is graphed, but there is no guarantee of the RTL quality and, ultimately, how much time will be spent debugging RTL, versus testbench problems. This type of early unpredictability leads to large deltas in resources and project timelines. Late-stage schedule divergence leads to last minute scrambling and ultimately missed deadlines or re-spins. While it is impossible to plan with perfect predictability, it is possible to reduce unpredictability and improve tracking so that initial project plans are more likely to stay relevant longer and deviations from plan can be caught and compensated for earlier.

It is easy, early in RTL development, to meet a set of milestones and incrementally add functionality. One might start with some sort of rudimentary, designer-driven, unit testbench, or maybe even go so far as to use formal properties to drive a test-driven development flow, as suggested by Neil Johnson in his excellent blog series. As line count steadily increases and then levels off, you might throw in a code review or two, and instantly, milestones seem to be met and the project appears on target.

Yet, what assurance do you really have that your RTL is of high quality? Perhaps you rely on some assertions or stimulus written by the designer (not quite unbiased) or lines of code “leveling off”. Or maybe you fall back on code reviews that possibly (probably?) devolve into arguing about coding style and rules rather than the value add that comes from discussions around interface assumptions and implementation decisions. These stop gap measures do not ensure high quality RTL. Even when reviews remain on track, there are buried issues, such as state machine interlocks, which are so embedded that reviews are unlikely to deterministically uncover them.

Without reliable assurances or measurements of code quality, RTL integration into testbenches and implementation likely to result in additional cycles spent debugging RTL issues. Often these are cycles spent by the testbench team, which is already in the critical path, further adding uncertainty to the bring-up period and delay to the project.

The Siemens EDA Questa Design Solutions product line provides quantifiable design readiness metrics at each stage of development, giving insight into core design health, warning against regression, and exposing fundamental design bugs early. Targeted goals guide you through the expectations of each design phase — from code bring-up through simulation readiness, implementation readiness, and finally tapeout. The tools provide a set of goals for each design phase with recommended checks and settings, but these are also completely configurable to manage the unique needs of each project and each team.

Fig. 1: Keys to improving design predictability.

A component of Quest Design Solutions, Questa Lint provides a data-driven design quality score so code quality can be measured and tracked without writing a single line of testbench code. As issues are resolved, the score improves, and the tool recommends next stage readiness. Scores are even divided into categories so coding style, naming convention, and language construct violations can be resolved before code review readiness, enabling the team to focus on true value add conversations.

A common front-end for all the Design Solutions tools, as well as QuestaSim, means a design compiled for Questa Lint is also ready for Questa Formal, Questa CDC, Questa RDC, and formal verification apps like Questa AutoCheck and Questa X-Check. Thus, while testbench bring-up is ongoing, designers can again get ahead of the game finding and fixing complex design issues which are traditionally difficult for testbenches to identify. Running lint early effectively pipe-cleans the QuestaSim compilation, further easing testbench bring-up.

By allowing isolation and configurability of tool messages, Questa Lint, AutoCheck, and X-Check work with continuous integration flows to guarantee a clean design stays clean. Design verification engineers are freed to focus on debugging testbench and deep functional design issues rather than basic RTL bugs that result from messy check-ins.

As chip integration approaches and the implementation phase nears, a new set of requirements and problems spring to the forefront. Again, Questa Design Solutions enable target-adaptable check points (such as CDC plus RDC checks for problematic clock and reset network constructions) specifically aligned to the requirements of this phase, providing measurable progress towards the goal of being implementation ready. Each of the checks can again be tracked through a unified coverage database (UCDB) so metrics and design health are monitored while tracking meaningful progress toward the next project milestone.

Finally, as the project drives to closure and verification teams are scrambling to close coverage, the designer can leverage Questa Design Solutions to clean up the final design and resolve coverage-related issues without the time intensive code exploration necessitated by code coverage misses. Final stage lint checks include unused variables, unused ports, and tied reset lines, each of which points directly to unused logic. And Signoff CDC verifies that the final implementation of the design has remained clean from a clock design perspective.

Up front planning and scheduling are key first steps to a predictable project; but planning alone isn’t enough. Plans will fail, and deadlines will be missed. It is critical that methodologies are implemented that catch those inevitable slips as early as possible, giving projects the opportunity to pivot. Clearly scoped milestones driven by measurable goals reduce schedule uncertainty. Toward this end…

• Questa Lint generates quality scores, providing metrics which show progress towards a goal of quality, not just quantity. Each quality improvement early in the design cycle reduces the chance of finding a problem in a later, more expensive stage when designs and testbenches are integrated.
• Questa Lint, CDC, and RDC provide stage-readiness guidance through phased checks targeted at design delivery goals. Each bug that can be found at the module level eliminates debug at the block or chip levels.
• Bug hunting using Questa Lint and Questa Formal improve predictability by pinpointing the location of bugs before they get exposed in an integrated environment. Each assumption that can be proven and every design strategy that is deterministically verified reduces the chances of late-stage problems, particularly emulation and implementation problems.

When integrated into an end-to-end design development methodology, the Questa Design Solutions product line acts as a development platform, using a common set of concepts and strategies to guide the product cycle and focus teams on the right checks at the right time, reducing noise and increasing productivity each step of the way.