When Intel released the Intel® Atom® P5900 series of system-on-chip (SoC) devices for 5G wireless base stations, one of the final milestones was the public release of that official name. I have been working with the chip for quite a while in virtual form, and to me it was always known by its code-name, Snow Ridge. Snow Ridge as a Simics® virtual platform (VP) is a classic example of system-level pre-silicon software enablement, or shifting-left.
“Shifting left” refers to using simulation solutions to get software developed, tested, and ready for launch without waiting for the silicon. As shown in Figure 1, it is possible to do integration testing and software development in parallel with hardware development by using the VP. This is one of the defining value propositions for Simics VPs from the very first days of the product, as discussed in one of my blog posts from the Simics 20th anniversary.
Figure 1. Shifting left with virtual platforms
Enabling the Silicon with Software
Shifting left includes many types of software. Some examples are shown in Figure 2. With a modern, feature-rich system-on-chip (SoC) like the Intel Atom P5900, there are many different types of software that need to be developed, tested, and integrated to have a complete software stack supporting the new chip when it launches.
Figure 2. Software support from a silicon vendor for a new SoC
The software that a silicon vendor develops, starts with the firmware hidden deep inside intellectual property (IP) blocks in the SoC (that is, subfunctions inside the chip). It is necessary to develop boot code—the Basic Input-Output System (BIOS) more commonly known today as the Universal Extensible Firmware Interface (UEFI). Once the SoC boots virtually, the next step is to update the Operating System (OS) kernels and libraries, and the device drivers. To expose the functionality of the SoC to users, programming libraries and software development kits (SDKs) like the Data-Plane Development Kit (DPDK) and Intel® oneAPI Toolkit need to be ported. Next, application software and example code needs to be ported and optimized to take advantage of the improvements offered by the new SoC, and compiler, debugging, and performance analysis tools need to add support for the new architecture. Often, they are extended with specific features supporting processor core features and accelerators.
Many of these software tasks take place in parallel, because it is possible to take shortcuts and “cheat” in a virtual platform. For example, system boot can be simplified to let OS work happen before a final UEFI is available, and driver work can be performed block by block, before the complete SoC model is built (or even before all blocks have had their designed finalized).
It is worth noting that developers and validation engineers often combine VPs with other tools like register-transfer-level (RTL) simulators, emulators and field-programmable gate array (FPGA) prototypes to validate the hardware implementation against software—and the software against the hardware implementation. This finds errors early, and it reduces the risk of having to re-spin the chips due to errors found when the first chips arrive.
Enabling the End Product
The enabling software from a silicon vendor is not the end of shifting left, however. As illustrated in Figure 3, the SoC in itself is not an end-user product, but a component in a bigger system. It will be designed into circuit boards and then integrated into final products. A final product includes physical power supplies, cooling, inputs and outputs, cable connectors, and much more.
Figure 3. SoC to board to product
At each level, both low-level and high-level software are added. Custom boot code, power-on self-test (POST), drivers for custom hardware on the board but outside the main chip, application stacks, middleware, and others. The amount of software that is needed in a modern system is enormous, and it needs to be developed as early as possible.
Thus, Intel provides customers with Simics models of future SoC and platforms, allowing pre-silicon system-level software development, hardware-software integration, and system validation testing—shifting-left the shipping product and not just the SoC software support.
From Reference to Custom
The first step of the enablement process is to provide the chip customer with a virtual reference board, just as chip vendors traditionally have provided physical reference boards. These are generic systems with “standard” parts added to the SoC to make it boot and run software in general, as illustrated in Figure 4. They provide a way to run the standard enabling software stack from the silicon vendor, and it offers a head start in testing functionality and supporting software.
Figure 4. Virtual reference board for basic software bring-up
A VP can provide even more value by modeling the customer’s board(s) and system. Figure 5 shows how this combines the SoC model with models of custom hardware and models of third-party hardware.
Figure 5. Model of a custom system allows much more software to be tested
Figure 5 includes some additional boards to indicate that for some types of systems (such as telecom infrastructure), it is common to model not just a single new board, but also other boards in the system. The other boards modeled can be old or new, but the key is for the VP to scale up to the entire network, allowing the testing of key features like redundancy, distributed software architectures, middleware, and systems management software. In fact, several customers for the Intel Atom P5900 did just that: modeling entire systems as part of the pre-silicon effort, bringing-up systems and integrating software ahead of hardware availability.
It is cool to see this happen, that shifting-left and pre-silicon software enabling happens both inside of Intel and with our customers. In the end, our customers’ customers benefit by getting more capable products earlier.
Related Content
The Early Days of Simics – An Interview with Bengt Werner: A look back at what happened before Simics went commercial. The product was officially launched in late June 1998.
Shifting Left—Building Systems & Software Before Hardware Lands: Chip-making at Intel used to involve a lot of work in sequence, but silicon products now take more time to design, develop, test and manufacture, and they need more software to deliver full value.
Shifting Left Together at the Embedded World 2019 Conference: Silicon vendors can (should) use virtual platforms to bring shift-left practices to their customers in addition to their own internal teams.
Intel® Software Development Emulator: Intel® SDE can help ensure software is ready to take advantage of the opportunities created by new instructions in our processors.
Author
Dr. Jakob Engblom is a product management engineer for the Simics virtual platform tool, and an Intel® Software Evangelist. He got his first computer in 1983 and has been programming ever since. Professionally, his main focus has been simulation and programming tools for the past two decades. He looks at how simulation in all forms can be used to improve software and system development, from the smallest IoT nodes to the biggest servers, across the hardware-software stack from firmware up to application programs, and across the product life cycle from architecture and pre-silicon to the maintenance of shipping legacy systems. His professional interests include simulation technology, debugging, multicore and parallel systems, cybersecurity, domain-specific modeling, programming tools, computer architecture, and software testing. Jakob has more than 100 published articles and papers and is a regular speaker at industry and academic conferences. He holds a PhD in Computer Systems from Uppsala University, Sweden.