Functional correctness for IP is essential yet elusive. In our first article A hierarchy of needs for SoC IP reuse, we described a hierarchical model to relate the relative priority of the deliverables from IP providers to the SoC designer who uses them. Based on Abraham Maslow's theory that all human beings have a basic set of needs that form a hierarchy, the SoC Designer's IP Needs Hierarchy has five levels of needs beginning with Functional Correctness:
1. Human beings have an inherent hierarchy of needs that must be satisfied in order.
In this article, we discuss the most basic need of every chip designer – functionally correct IP. The best and most unambiguous measure of functional correctness is the extent to which IP has been validated in production silicon. SoC designers don't like being the lab rats of IP providers and often find themselves discovering bugs that should have been sorted out long ago by the provider. SoC designers want to use IP that has been silicon proven – and the more times the better.
Why functionally correct IP is so elusive
Fundamentally, IP can be said to be functionally correct when it operates according to its specification. This tautology is easier said than done. Specifications are rarely so complete as to anticipate every possible use case (context) or unambiguous enough to avoid misinterpretation by design and verification engineers. In the case of standards-based IP (USB, PCI, etc.), the specifications change over time, and each change represents a risk of introducing a new bug where none had previously existed. IP that is configurable (e.g., through parameters, generics) represents more challenges to the design/verification team in that as configurations are added, the verification effort can grow exponentially.
Planning to succeed
Because of these complexities and uncertainties, which are faced by every design team, engineers must deploy a diversity of methods to ensure their IP is correct. A key aspect of this planning is developing a strategy around architecture, design entry, verification, validation, and silicon testing that can provide the confidence that the design is functionally correct. A well-chosen strategy can be the difference between a highly profitable, stable IP block and a bug-ridden, unstable one that people are afraid to use.
As shown in Fig 2, one strategy to address to the problem of translating a specification into an implementation is to develop a series of models, each with successive levels of detail. The Architecture model provides a basic check of the understanding of specification by verification and design teams, by providing a very fast model from which the complete functional behavior of the IP can be tested. Specification inconsistencies can be flushed out at this level. A Cycle Accurate model can then be developed to verify completeness and accuracy against the Architectural model. A Bit Accurate model can similarly be used to check the Cycle Accurate model. Finally, an RTL model is developed against a rich set of tests that were developed at various levels of abstraction for each of the preceding models.
2. One proven approach to developing complex IP cores is to deploy a step-wise refinement model
As each stage of the process involves different people with different perspectives on the specification, this approach greatly minimizes the risk of any one person misinterpreting the specification as – at each level – new tests are written. If the probability of any single person making a mistake is 50%, then the probability of everyone making the same mistake and it escaping into the RTL is (at worst) as follows:
P(m) = 0.5 × 0.5 × 0.5 × 0.5 × 0.5 = 0.3125%
Design is more than typing
Too little attention is paid to the art of design itself. Design consists of two distinct parts: architecture and implementation. The odds at achieving functionally correct IP are greatly improved if the architecture of the IP is partitioned along clean functional boundaries at the hardware and software levels. Such partitioning allows the tests to be written at a very high level and reused easily at different layers of abstraction, including fully functional hardware prototypes. For example, Fig 3 shows how, in a Bluetooth HCI Baseband Controller, the connection between the hardware layers is performed over a simple UART interface, where the software layers communicate through a standard Bluetooth Host Control Interface (HCI) protocol.
3. The IP is partitioned along system-level interfaces at both the hardware and software levels
As for the implementation aspects of design, Extreme Programming advocates are demonstrating the benefits of "pair programming," whereby two engineers are teamed to write a single piece of code. One engineer types as the other engineer reads the code, performing essentially a continuous design review. Each line of code gets two sets of eyes reviewing it and, as a result, you have two engineers trained on that piece of code, doubling the odds that future changes can be made by one of the original designers.