Seeing the Early Snow on the Ridge

By Jakob Engblom,

Published:03/17/2020   Last Updated:03/17/2020

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.

Snow Ridge

“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.

Diagram showing how virtual platforms let software development and system integration overlap with hardware design and production

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.

The software developed by the silicon vendor includes firmware, BIOS, UEFI, OS drivers, libraries, SDKs, applications, compilers, and tools

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.

The chip goes onto a board, and the board goes in the shipping product

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.

Showing the SoC on a board with generic components

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.

The SoC on a custom board along with third-party hardware, custom hardware, generic components, and also connected to other boards

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

JEDr. 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.

Product and Performance Information

1

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804