Introduction
Chip-making at Intel used to involve a lot of work in sequence, but silicon products require more steps now. They take more time to design, develop, test and manufacture, and they need more software to deliver full value.
And if unplanned revisions occur, they can cost months of delay and many millions of dollars to the bottom line. This challenge spurred a new approach to getting Intel® silicon and critical software stacks done right the first time: compressing tasks and doing more in parallel. The industry calls that “shifting left” because it means getting more done earlier in the product lifecycle, in large part, by using innovative simulation and modeling technologies such as Simics* virtual platforms.
Our shift-left began with efforts to coordinate the co-development of platform hardware and software—one effect was moving software from the end of product development to front and center.
It’s simple on a chart. Just draw an arrow—do it earlier. I honestly entered with that mindset.
Today, my team ensures that all the critical code needed to ship a product to our customers and make it viable for their customers is ready at the final “go.” This effort is called “Pre-Silicon Software Readiness.
It’s a paradigm shift. Much more has to happen in partnership with our customers much earlier in the process.
The Implications—From Design to Test
Robert Jones, a senior principal engineer leading shift-left efforts in the Intel Platform Engineering Group, told me “it’s huge” on the hardware side. He said that before, when testing and software development happened post-silicon on a new chip “you had a relatively fixed definition of what the hardware does—what we taped out.”
But for teams to start building tests and critical software earlier, they need to know ahead of time what the new chip is going to do and how it’s going to do it.
“The requirements on design and architecture are very high,” Jones confirmed. “Teams are working to build more products for more customers, and now we need this piece of work earlier.”
Inside and outside of Intel, software teams working on firmware, BIOS, drivers, compilers and software development kits (SDKs) are no longer considered downstream users—they’re partners. In the past, the hardware teams had license to change designs at will.
Changes made after software is already being developed can cause a lot of pain. The challenge of continual integration is always how much does it change per integration. Something as simple as changing the name of a register can be a huge problem.
Virtual Platforms Simulate Chips for Rigorous Tests
Greater use of virtual platform software is enabling developers to build and run code on simulations of new chips. This helps to deserialize and compress tasks into the crucial pre-silicon window. Intel’s primary simulation environment runs on the Wind River* Simics* virtual platform and is also supported by my team.
After building and testing software on a virtual platform, a top OEM booted up a new chip in just over one day—previously, that took two weeks.
Intel teams are building advanced tests on these virtual platforms—even running a virtual reality (VR) demo on a years-away client chip design. We are also putting virtual platforms in the hands of customers and ecosystem partners to give them a head start on their own designs and software stacks.
Through these initiatives, Intel has extended the scope of virtual platforms to cover not just BIOS and operating systems (OSs), but also tools, SDKs, middleware, workloads and applications.
A Closer Look at Virtual Platforms
Ryan Averill, Director of Virtual Platforms Systems in my organization, shared more details about the role of simulation in our Pre-Silicon Software Readiness program. He explained, “It’s all about reducing the time from when we conceive of a product to when we can actually ship it.”
“We test real software on the Wind River Simics virtual platform, so we can actually debug the code just like it's on a real physical platform. When different test cases fail, we can debug them and figure out what software ingredient has an issue, fix it, test it again and move on.”
Wind* River Simics* Software Shortens the Traditional Product Life Cycle
From Wind River, Simulate Anything, Chip to System
While the virtual platform, on its own, is primarily for functional testing by executing software instructions, Intel® CoFluent™ technology and Intel® Docea™ solutions provide additional simulation capabilities that handle power, performance, and thermals.
Averill added, “As these technologies are integrated, we get an incredibly robust solution for end-to-end simulation, pre-silicon. This holistic simulation suite is fundamental to our ability to accelerate pre-silicon readiness for the entire software stack internally, as well as with our customers.”
Much of the firmware, BIOS codes and development tools for testing come from Intel, with some coming from third-parties like operating systems (OSs), Java*, database management systems and even applications. Intel works with software partners to get them bug reports and software fixes ahead of hardware.
Using virtual platforms for software validation is not new to Intel. Averill points out, “This is something we started in 2010 when we acquired Virtutech, the company that built Simics. We started ahead of the Skylake generation, and so we've had several generations to continue to improve—with each generation, we're able to do more.”
Software Readiness Qualification
The next step is software readiness qualification (SRQ) of mission-critical software (MCSW).
Vinoo Srinivasan, Director of Software Readiness Enabling in STO, describes SRQ this way: “We ensure MCSW is qualified in virtual platforms, pre-silicon. The SRQ mission is to shift-left the qualification of the full software experience.”
He adds, “We make sure the software stack works before silicon launches. Today, software qualification is a team effort across Intel.”
MCSW readiness at power-on is the primary goal. MCSW is established in four key areas:
- Driver and firmware ingredients for legacy and new silicon features
- OS and virtual machine manager (VMM) changes for new silicon features
- Application and middleware features
- Software tools and SDKs
We use platform ingredients, both in-development and new OS features, critical workload functionality, new features of the silicon products, and product-related tools and SDKs. Srinivasan explains. “SRQ uses virtual platforms for maximum software coverage to qualify real user experiences.”
The SRQ team engages early in the process to establish a pre-silicon execution plan. The software landing zone for the product must be well understood to identify MCSW for the program, so the SRQ team works with the software planning team. Together, they build the MCSW and partner with stakeholders to drive the MCSW coverage for all pre-silicon development and validation.
Linux* is a great example
The Intel Open Source Technology Center (OTC) supports new Intel silicon features through upstream contributions across a broad range of projects. As the number-one upstream contributor to the Linux kernel, OTC invests substantial resources to offer new feature-enabling and value to the Linux community.
Alexandra Oliveros-Villalba, Core Linux Kernel program manager in Intel OTC points out, “The Linux kernel is not an operating system. Think of the kernel as a set of services that enable scheduling, thread management, I/O device compatibility, CPU optimization, memory management, and other system capabilities on a platform.”
Oliveros-Villalba’s team contributes code patches upstream via kernel.org to the Linux community. The code patches, in turn, enable downstream OS distributions, such as Red Hat* Enterprise Linux*, Ubuntu*, Android*, Chrome* OS, Clear* Linux, and others. Just by enabling the kernel, you can enable all the Linux OSs.
Oliveros-Villalba adds, “Some Intel customers care about a specific Linux distribution and use cases, so validation is needed for each of the downstream kernels and OSs. As part of the SRQ, you need to look at each particular OS to meet those particular requirements. We’re shifting left to enable pre-silicon customers and downstream OS distributions—coordinating an environment that first starts with the Linux kernel and then goes into a model for those Linux distributions.”
“The key for us is to enable code for each hardware platform by the time the platform is launched, so that platform capabilities are supported and aligned with the OS vendors,” she explains. “The earlier we start, the better we can deal with changes and have upstream code available for customers before launch.”
Pre-silicon Customer Acceleration
The rubber hits the road with major customers and ecosystem partners. Chris Lawless, Director of Pre-Silicon Customer Acceleration (PCA) in my division, describes his team’s primary mission “to enable Intel’s customers to shift-left their software development and deliver their Intel-based products to market sooner.”
“We work closely with Intel business units to help drive parallelization of each customer’s software development process with Intel’s product development, allowing both to achieve deliver products faster.”
To achieve product release, new and complex features in Intel silicon need a “software development runway,” Lawless said. “We also seek close customer collaboration and feedback on Intel’s own software.”
PCA aims for an end-state where each software stack boots and runs on Day One at customer platform power-on, significantly reducing customer time-to-launch. 
PCA supports dozens of original equipment manufacturers (OEMs) and original device manufacturers (ODMs) along with independent firmware vendors (IFVs), OS vendors (OSVs), and independent software vendors (ISVs). PCA also partners with electronic design automation (EDA) houses to support more sophisticated solutions at the customer site
The software ecosystem is complex and interconnected. By supporting IFVs, OSVs and others that deliver to our customers, we help complete early readiness of the entire software stack. Lawless added, “We focus primarily on ensuring each customer’s system software is ready.”
Learn More
For more information about how virtual platforms help speed-up platform integration and software/firmware readiness, read The More the Merrier – Building Virtual Platforms for Integration
Visit the Wind River Simics page to learn how you can use virtual platforms.
Author
Michael Greene is Intel Vice President and General Manager of System Technologies & Optimization in the Intel Architecture, Graphics and Software organization. Greene leads a worldwide division responsible for a broad range of development, validation, enabling, and architecture analysis efforts for Intel platforms, including pre-silicon software, virtual platforms modeling and simulation solutions, and power performance analysis, to increase development velocity and time to market. Greene joined Intel in 1990, after graduating from the Massachusetts Institute of Technology and has managed several new product developments, research efforts, and engineering groups. He has served as Intel’s initiative owner for power efficiency, pre-silicon software readiness, and has driven new technology benchmarking throughout his career. Greene is also Chairman of the Board for the National GEM Consortium. GEM is a national non-profit providing programming and full fellowships to support the number of under-represented individuals who pursue a master’s or doctorate degree in science or engineering. Follow Michael on Twitter.