Prologue
Peter was running late for two reasons. First, he encountered unexpected heavy traffic and arrived ten minutes late for a crucial meeting with a customer to run a compliance test of his new 6G phone design prototyped on FPGAs. This prototype’s success was pivotal, as it could secure a significant purchase order. Peter had reason to be confident. A rigorous twelve-month verification process, from early RTL stages, through weekly RTL regression testing, to hardware/software integration, software validation, and final system validation, had bolstered his assurance. Second, and more concerning, he was already a week late for his overall schedule which added pressure to the day.
After apologizing for being late, Peter swiftly set up the prototype and connected it to several of his customer’s USB devices. Initially, the demonstration proceeded without a hitch, until they tried the customer’s most important device, a brand-new USB drive. No matter how often he tried to connect, the USB drive stayed invisible causing a chill to run down Peter’s spine. Repeated attempts to recreate the issue by unplugging and plugging the USB cable confirmed the problem persisted, clearly indicating a failure in the design that needed attention back at the factory.
That day, Peter learned an unforgettable lesson about the unpredictability of the real-world environment and the importance of compliance testing under real-life conditions.
Architecture of a Peripheral Interface
Modern system-on-chip (SoC) designs, whether all-in-one systems or sub-systems of a large multi-chip design, communicate with the outside world via a set of peripheral interfaces in the form of IPs. They differ in types and in numbers. Regardless of the type, all share the same architecture that consists of two main components: a controller and a PHY. See figure 1.
The controller, an eminently digital design, implements the communication protocol encompassing the set of functions governing the transmission of data/information between the transmitter and receiver. Today, most interface protocols adhere to industry standards such as PCIe, UCIe, CXL, USB, HDMI, and others.
The PHY, an analog/digital mix-signal design, manages the actual transmission of data to/from the external world which is an analog environment. The PHY deals with voltage, current, power, and other electrical parameters.
Verification of a Peripheral Interface in Stand-Alone Mode
The verification flow of an interface IP, as part of SoC, adheres to the multi-step industry paradigm:
The flow starts with RTL simulation. Since the complexity of an interface IP is limited (one of the most complex protocols such as PCI Express (PCIe) includes less than 10 million equivalent gates), an HDL simulator is adequate for RTL debugging before driver development and system integration begin. Ensuing RTL debug, software driver validation and HW/SW integration are performed with hardware-assisted verification (HAV).
There is one additional step that Peter was missing that is critical for first silicon success: compliance testing. The verification flow of an IP interface finishes with compliance testing to ensure that the design adheres to the rigorous standards set by the compliance body for each protocol. At this stage, a challenge arises because a PHY digital model, as accurate as it may be, does not simulate the analog behavior of a PHY. This limitation hinders comprehensive verification as required by compliance testing. To overcome this hurdle and address the analog aspects, the PHY must be implemented on a test chip.
Interface IP vendors must verify their IPs following the flow just outlined and provide the buyer with confidence that the IP the are buying passed the certification of compliance.
Verification of a Peripheral Interface in an SoC Context
SIDEBAR: Some design teams may interpret the vendor’s IP compliance certification as an excuse to skip their own compliance testing after integrating the IP into their SoC design. This is a risky proposition…
Certifying an interface IP in isolation does not ensure that the integration into the SoC hardware and software is bug free. Everything might appear to function perfectly until system validation in a real-world environment uncovers hidden system bugs. This situation truly tests the IP integration and system design robustness—it’s where “the rubber meets the road.”
Once part of an SoC, an interface IP must operate seamlessly with components that could be designed by the same company or by multiple different companies. It is crucial to verify these interactions to prevent costly issues after the silicon is manufactured.
Peripheral Interface Verification: Benefits of Hardware Emulation vs FPGA Prototyping
HAV platforms fall into one of two categories: hardware emulation or FPGA prototyping, each offering distinct advantages. Emulation platforms are synchronous engines driven by one master clock. The benefit of this attribute is the ability to reliably reproduce error conditions since it allows for quick and straightforward bug tracing and debugging. However, a typical SoC design incorporates various subsystems each operated by independent clocks, which may or may not be synchronized with one another, making the SoC inherently asynchronous.
When a synchronous behavior triggers an error, the emulator can efficiently capture and debug the issue. Yet the predictable nature of these events means there is still a non-zero probability of encountering scenarios in real-life that cannot be duplicated during emulation. Such bugs are more likely to emerge when testing the first silicon samples, where operations are entirely asynchronous.
Conversely, FPGA prototyping is capable of handling purely asynchronous clocks making it an ideal platform for accurately dealing with asynchronous behaviors in a pre-silicon environment. For instance, while in mobile standards such as LTE, 5G, and 6G, there is a central master clock, smartphones require the generation of many different local design clocks, creating a truly asynchronous system. This system cannot be fully verified in an emulation environment. While prototyping can reveal hidden bugs caused by the interaction of asynchronous clocks, tracing and resolving these issues can be time-consuming and frustrating. The only effective method for thorough verification is in a prototyping environment. A SoC prototyping platform should provide the capability of capturing signals at-speed with elaborated trigger mechanism to catch the issue when the system is operating at-speed. A prototyping system also needs enough trace buffer depth to correlate the HW bug that is seen by the SW several milliseconds/seconds after the bug happened.
Emulation and prototyping can be integrated into a verification flow to harness the strengths of each approach. Emulation can identify all bugs that arise in synchronous environments, except for those few that may only manifest through asynchronous behavior. Once these are uncovered, switching to emulation allows for quick and easy tracing and fixing of these issues.
Criticality of Compliance Testing
The importance of IP compliance testing varies among different market segments of the semiconductor industry.
The consumer market is more tolerant if a product failure shows up in the field. If a fault in an HDMI interface of a play-station connected to a TV causes an occasional flickering image, an issue that may be uncovered in compliance testing, the user may elect to overlook the annoyance.
In contrast, an occasional failure in a PCIe interface in the HPC market would lead to a different outcome. Even seemingly minor PCIe interface faults, where occasional transmission bits are dropped, can cripple a data center causing significant financial losses.
Best in class solution for SW development and Compliance Testing
A best-in-class solution enables mapping the controller IP onto a prototyping system and supports a test chip on an extension card that is specifically speed optimized for the prototype system to connect to the real-world interface.
Such a solution is designed to tackle three different verification scenarios:
- Out of the Box software driver development
- 3rd Party Interoperability Testing
- Protocol Compliance Testing
A real prototyping system must be engineered with two primary objectives in mind: to accelerate SoC software development and validation, and to enable at-speed connection and validation of interfaces. At-speed connectivity is essential for conducting compliance tests of interfaces.
Software also plays a critical role in the system’s overall functionality. A malfunction in the driver configuring the interface can lead to the failure of the entire interface. This highlights the critical need for rigorous validation of both software and hardware elements, including digital and analog components. Comprehensive testing like this is crucial to guarantee that the system operates correctly in real-world conditions.
Conclusion
Peter learned the hard way that skipping compliance testing can result in costly delays. Indeed, if an unidentified design bug slips into manufacturing, the financial repercussions could be severe, involving product recalls, expensive redesign, and millions of dollars in lost revenue in highly competitive markets. This kind of oversight could be catastrophic for a project.
The takeaway is clear: for every SoC project conduct at-speed compliance testing in a real-world environment. You want no chills running down your spine when you go into tape-out!