Electronic Design
Software Ecosystem Bring-Up for a 21st Century Processor Architecture

Software Ecosystem Bring-Up for a 21st Century Processor Architecture

Hardware alone cannot exist successfully without a software ecosystem. That’s why stakeholders are investing heavily in ensuring the 64-bit ARM ecosystem is ready with software to support new server hardware.

Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.
Frank Gorishek, Director of Solutions Enablement Engineering, AMD

Bringing a server processor to market based on an emerging architecture involves a coordinated hardware and software effort. History has shown that bringing silicon to market without the appropriate software ecosystem in place can lead to failure regardless of its benefits when users are unable to deploy needed applications. That’s why companies and organizations like AMD, Linaro, Red Hat, and SUSE, among many others in the software community, are investing heavily in ensuring the 64-bit ARM ecosystem is ready with software to support new server hardware.

ARM’s 64-bit ARMv8 architecture was designed from the ground up as a new architecture with significant performance improvements over previous ARM architectures alongside the headline-grabbing support for 64-bit memory addressing. This all-new design means it doesn’t carry the baggage that comes with having to support legacy applications, drivers, or operating systems.

Starting with a blank sheet of paper provides hardware vendors with a tremendous opportunity to create a revolutionary product—one that can efficiently handle the demands of today’s Internet-based software. This provides the freedom to build a software ecosystem from scratch: from the firmware level up to the operating-system kernel, device drivers, then to developer tools such as compilers and libraries, and finally the user applications. However, building from scratch doesn’t mean throwing away the standards that have established a level of order and compatibility in large data centers.

Even with the basic platform software and development tools in place, silicon vendors play a lead role in helping inventive developers optimize for a new architecture. Hardware vendors are cognizant that without a robust software ecosystem, the market is limited for their products.

Collaboration is Crucial

An important realization at the very beginning of ecosystem bring-up is understanding that it takes a cooperative, community effort to build a successful software ecosystem. This means collaboration is key to short- and medium-term success. For long-term success, readily available hardware, documentation, and education, as well as marketing support from the hardware and software providers, must exist to sustain ecosystem growth, ensuring architectures such as ARMv8 continue to flourish for years to come.

Reaching a stage where developers are enabled to make their own applications takes a lot of hard work and collaboration. The days when a single silicon vendor could prescribe a proprietary standard and expect widespread adoption are all but over. When the x86 architecture first appeared, the open-source concept didn’t exist. Instead, operating-system and software vendors worked with closed-source models, which meant silicon vendors had to work with comparatively few organizations.

Today, the open-source paradigm has gained acceptance, even among traditional closed-source advocates. The open-source community fosters collaboration, which means that companies now have to work on projects with potentially thousands of active contributors.  

Just as open-source projects such as the Linux kernel project require organizations to work alongside each other, in recent years a concerted push is being made toward open industry bodies such as the Linux Foundation and Linaro. Working within these organizations provides an opportunity to collaborate with focused teams that are dedicated to certain features, while maintaining the advantage of working with the wider community.

Even when vendors decide to work on functionality in-house, the key is to upstream any developments to projects such as the Linux kernel. If developments aren’t upstreamed, then Linux-based distributions such as Red Hat Enterprise Linux or SUSE Enterprise Linux are unlikely to incorporate updates. That, in turn, leads to customers potentially having to patch their operating system to include support for features specific to a particular product, which is generally regarded as a negative. By upstreaming development, it helps the ecosystem adopt the developments as well as enable the wider community to understand the silicon, and, in turn, aid in the development of third-party software.

ARM's 64-bit ARMv8 processor architecture.

Ultimately, the result is a more robust set of products. However, the community development process can take more time than if performed by a single vendor within a closed, proprietary environment. That additional time is part of what we’re seeing now with 64-bit ARMv8 adoption.

What About Hardware?

Providing the community with software is one part of the story, since a single vendor, regardless of its size, can only do so much. The software-development community has imaginative and talented individuals that will always push the ecosystem ever further, and the only way to enable them is to get hardware in their hands.

The ability for developers to play with hardware based on the actual silicon is better than any emulator and an absolute must in the 64-bit ARM ecosystem, which requires development of firmware and drivers. Key functionality, such as Advanced Configuration and Power Interface (ACPI) and PCI Express driver development, simply would not be a viable proposition if the hardware wasn’t made available to developers, and the silicon vendors didn’t provide documentation and support. This may be the unglamorous side of bringing up new silicon. But without Unified Extensible Firmware Interface (UEFI), the system wouldn’t even boot, so it’s difficult to overstate its importance.

Providing a hardware-development platform is a multi-faceted undertaking. A development platform is much more than simply a piece of silicon stuck to a circuit board. For instance, AMD Opteron A1100 Series developer kits were designed to expose all of the processor’s features and allow developers low-level access to the hardware. This not only enables the development of functionality such as SATA or PCI Express drivers, but developers can also profile how the software interacts with the hardware.

Considering ACPI’s development as one case in point, working on this important piece of software is critical to an efficient system. With power efficiency being of vital importance in the data center, not having this functionality mature could be the death knell for the ARMv8 architecture. Because ACPI is so fundamental to the ARMv8 ecosystem, the development process is long and requires collaboration between organizations such as Linaro and hardware vendors like AMD.

The role played by Linaro’s Enterprise Group in the development of both ACPI and UEFI cannot be understated, and when vendors such as AMD work with these organizations, it helps ensure the wider community reaps the rewards. Linaro’s working groups offer transparency and a framework for vendors to work within while also leveraging the open-source development paradigm.

Perhaps the most important part has little to do with the hardware itself. Providing support to developers in the form of clear, concise documentation backed by engineers who can either be physically present or on the other end of a telephone to provide help is absolutely vital. This stage, more than any other, exemplifies the collaboration between hardware engineers and software developers.

Developers need clear documentation to help in the development of drivers. However, they also need vendor support to understand how to optimize and produce a piece of software that gives users with the best possible experience.

Tool Support

Empowering software developers to take hardware and use it as a platform to realize their designs should be the ultimate goal of any silicon vendor. In addition to low-level firmware and drivers, developers also need access to tools such as compilers and libraries in order to create applications. Porting high-level languages (e.g., C and Java) to an architecture like ARMv8 is absolutely vital in persuading time-starved developers to embrace these new platforms. It’s particularly important because asking them to learn new languages and adjust to new workflows has proven to be a significant barrier to overcome.

The support of programming languages such as C and Java by development tools, whether debuggers and/or toolchains, is critical, as is education and documentation on how to embrace these tools. Well-documented libraries are the life-blood of any self-sufficient development ecosystem, because they allow developers to progress rather than spend time recreating commonly used algorithms.

Creating a software ecosystem is exciting, but one from a blank canvas is doubly so. It gives the opportunity to develop software that addresses today’s needs—without having the baggage of legacy compatibility and workflows—while tackling the challenges in a way that will benefit the wider community and not just a few vested parties. The days of using proprietary standards to silo innovation are thankfully fading, and collaboration is simply the most efficient way of driving long-term sustained ecosystem growth.

The challenge of bringing up a software ecosystem is not just hard, but requires long-term commitment from many stakeholders. It often requires doing work that’s for the greater good of the ecosystem rather than a single team or company. These challenges are compounded when one has to deal with brand new hardware that brings revolutionary changes. Ultimately one has to understand that the hardware alone cannot exist in isolation. Without a software ecosystem, it may as well not exist. In many ways, the software developers play as much of a role in the development of successful silicon as the electronic engineers.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish