THURSDAY March 05, 1:00pm - 2:30pm | Siskiyou
Kurt Takara - Mentor, A Siemens Business
Verification takes many forms. What some consider to be a modern verification methodology may be of a scope that others are not able to support. Some implement a Portable Stimulus-enabled, constrained-random, coverage-driven methodology that utilizes emulation and prototyping to enable hardware-software co-development and accelerate system deployment. Others build an implementation of their FPGA and test.
Both extremes are borne of differing constraints. Both have been used successfully, and unsuccessfully, to deploy products to market. The goal of any verification process is to ensure that the design performs as intended, and not to “find bugs” or to “close coverage”. Of course, these are hurdles that must be addressed. Finding bugs is necessary because designs and test benches are never perfect. Closing coverage is necessary because it’s a metric by which we know how complete our stimulus is. Yet, while a verification effort that closed coverage and found no new bugs in days or weeks is more likely to see clean deployment, it is still not guaranteed any more than is a lab-tested implementation.
Why? Because most designs today are built across teams, across companies, across geographies, across languages and across time. At every boundary lies a gap. These gaps are fertile ground for bugs to thrive and go undetected. Current challenges: Very few designs today are flat. A hierarchical design consists of layers of functions. Gaps exist by definition between functions not designed together – across all combinations of the aforementioned boundaries. For instance:
- Documentation is written in spoken languages, incomplete, and subject to translation and interpretation.
- Assumptions are made by the designer about interfaces that may not be true.
- Models are created for more accuracy, but models are abstractions; errors and omissions can exist.
- Constraints valid at the time of design can be different than those for other functions created later, as target markets, technologies, and industry standards change.
- Designs can be completely verified and validated in one EDA suite only to have issues in another.
Furthermore, in parallel with hierarchical design, organizations introduce gaps as they scale up and become locally specialized. It is easy for task responsibilities to remain in one organization that over time begins to lack the skill set demanded of modern use cases. Finally, designs are developed by many teams across many companies over time. Changes made downstream by one team or company may unwittingly corrupt the functional intent of the original design.
This workshop will examine several gaps in development processes that can result in verification escapes, and suggest solutions that can prevent bugs from finding their way into customer deployments. Specifically:
- Design Verification vs. Functional Verification – Using static linting, sequential linting, clock domain crossing and reset domain crossing applications as examples, this section proposes creating an intentional gap between Functional Verification – that of ensuring that the design functions as it is intended, and Design Verification – ensuring that the design is of high quality and meets the designer’s intent. This is intended to address these undesirable gaps:
- In large organizations, designers create code and hand it off to verification teams, specifically built with the skill set to use and understand the verification tools. However, the designer knows better what is and is not a failure. For instance, will a verification engineer understand what metastability is in a flip-flop? Or, if a state was intentionally added to a state machine that can not be reached functionally?
- In smaller organizations, the designer typically stops doing design and starts doing verification. But, the engineer is typically not well-versed in the tools available to the modern verification engineer and so does not deploy many of these powerful capabilities. Either way, the gap between organizations, or between skill sets, is fertile ground for bugs to thrive and go undetected. In promoting this division of verification effort, and by use of the aforementioned examples, this section will demonstrate that bugs that can slip through the verification process can quickly be found and fixed by employing modern verification technologies, wrapped in a designer-friendly manner. In addition, this section will also identify where this is not true, in that some tasks must span the gap.
- Design vs. Implementation – Using formal verification technology and clock domain crossing tools as examples, this section examines the gap between the design team and the implementation team and their skill-sets. In similar fashion to the previous section:
- In large organizations, an implementation team is left to interpret and fix design issues in ASIC or FPGA that arise from the implementation of the netlist.
- In smaller organizations, engineers who perform all functions aren’t aware of the verification tools available to ensure that their implementation work didn’t cause new issues. These undesirable gaps are known to let bugs pass undetected. This section will demonstrate that bugs typical of this gap can be found and fixed using static analysis and formal verification techniques.
- Large, hierarchical, geographically-dispersed teams using 3rd-party IP: Using clock domain crossing and linting tools as examples, this section examines the gaps present in developments within large hierarchical organizations, across geographies and between companies. The nature of these gaps challenge resources and schedule. The industry has appropriately covered the gaps functionally, but current solutions are slow, compute-intensive, or require significant documentation and review. This section will propose tool-based solutions that will accelerate the analysis and reduce the barrier of adoption, or increase team productivity to ensure that issues present in these gaps are found and addressed.
Thank you to our Sponsor: