It Takes A Village… To Develop And Verify SoCs

In my last blog post from 2017, “Design Chains Will Drive The Top 5 EDA Trends In 2018,” I had pointed to the importance of ecosystems for electronics development in general. From an EDA perspective, it also takes a village to shepherd the actual chip development with its complex verification and software development tasks. And the types of partnerships often depend on the application domain—what works in the server/infrastructure domain may not be applicable in the same way in 5G and networking. To add complexity, standardization is often different per application domain, too, making application specificity a key driver for EDA ecosystems.

In the early days of my career I was responsible for several chip developments. They were in HDTV video encoding, video editing, video conferencing, and MPEG 1 and MPEG 2 video/audio decoding. My teams and I would learn to speak the language of our chip development customer’s customers, even follow the standard’s development to be prepared with the right IP, following the right standards at the right time. We even had trademarked the term “DesignObjects™” to liken hardware IP re-use to object-oriented programming in software. Oh, I miss the ‘90s sometimes…

As to standardization, there is, of course, the standardization of functions and protocols itself. From a development tool perspective, application domains add several additional challenges to the already complex development, verification and validation of systems on chips (SoCs). Just consider compliance with functional safety standards and system environment complexity. Take safety, for example. Development teams need to consider ISO 26262 in automotive for autonomous driving and automated driver assist, IEC 61511 in industrial applications for the needs around factory automation and IEC 62304 in the medical domain for robotic surgery and implants into the human body. Functional safety has also become a critical issue in control systems of trains (EN 5012x) and flight systems (DO-178, DO-254). And then there is the convergence of electronics and needs to be considered during development. For example, due to the sheer system complexity in aerospace applications, verification needs to consider the different domains involved—flight control, cabin and passenger—and needs to put them into the context of multiple airplanes and ground control systems.

Let’s look at hardware-assisted development in more detail. An SoC must be connected to external interfaces, and the development team’s intent is to avoid as many late-stage surprises as possible. For instance, it certainly becomes a pivotal career moment for a project manager if a team finds bugs that cannot be corrected by software when the chip is connected to a tester for PCI, Ethernet or LTE/5G protocols.

It turns out, all those interfaces require special domain expertise for which experts exist in the market. It comes to no surprise that, in the hardware development ecosystem, we have more and more partners present with us. Here are a few examples:

• Teledyne Lecroy and its PCI expertise connects seamlessly to the Palladium platform as presented in “Ubiquitous PCI Express Verification from Simulation Thru Post-Silicon Development.” Protocol testing can be done across pre-silicon and post-silicon development tasks.
• Rohde and Schwarz testers for LTE, 4G and now 5G have been working with pre-silicon development in the Palladium platform for years, as presentations like “LTE-Advanced—Taking LTE to True 4G” show.
• Ixia (a Keysight Business) and Cadence are partnering in the area of Ethernet testing. Users need to run as many packets through networking protocol analysis as early as possible, as part of the verification process.
• A more general trend here is connect the pre-silicon verification and post-silicon lab testing, as we have been for “Design to Test” with National Instruments for quite some time now, see “Portable Stimulus for Verification and Post-Silicon Test—How to Connect These Two Worlds.”

The figure below shows the principle – start with simulation and the lab-testing software (like LabView) and then reconfigure as more detailed version of the chip under development become available.

“Design to Test Flow” combining pre-silicon and post-silicon capabilities.

Another category of ecosystem partners are development partners that can lend verification expertise to design teams. Some of these partnerships can be regionally focused, like our work with PLC2 in Europe and other leading verification service providers. Expertise is then shared at public events like CDNLive EMEA, like PLC’s presentation “Full-Speed Ethernet Implementation on the Protium S1 FPGA-Based Prototyping Platform” last year.

Beyond verification, software development is key. This is an area in which application specificity again plays an important role. In automotive, for example, different software debuggers are more predominant than in mobile and server applications. We are closely partnering with Lauterbach with their Trace 32 debugger and Arm with DS-5 in this area.

So, it literally takes a village to provide complete application-specific development environments for chip developers across verification and software development. With further specialization in application domains, this continues to be a key area to watch in 2018.