PowerCommons - The Open Silicon Commons

Welcome to PowerCommons

PowerCommons is an ambitious initiative to create the world’s first fully open, verifiable, and sovereign computing infrastructure based on the OpenPower architecture. We’re reviving and modernizing proven processor designs to deliver transparent, auditable, and secure computing platforms that serve the public interest rather than corporate surveillance.

In an era where digital infrastructure determines economic and political power, PowerCommons represents a crucial step toward technological independence and democratic control over computing resources.

What We’re Building

PowerCommons is reviving IBM’s A2O processor core—a proven 64-bit PowerPC design that powered Blue Gene/Q supercomputers—for modern FPGA platforms. We’re pairing it with Microwatt as a secure boot processor to create a fully open and verifiable SoC architecture, where every component from power-on to application execution can be inspected and audited.

Current work: A2O core revival targeting Xilinx VCU-118, with build system modernization for contemporary Vivado toolchains.

Foundation already laid: Linux booting on Microwatt/VCU-118, LiteDRAM integration, upstream contributions to the Microwatt repository.

Technical guidance: Direct collaboration with Prof. Peter Hofstee, original architect of IBM’s Cell Broadband Engine.

Where This Leads

A complete sovereign computing stack built on proven, auditable silicon—from embedded controllers through workstations to datacenter infrastructure. Not a slide deck vision: a concrete path from working FPGA implementations through formal verification to production hardware. Computing infrastructure that serves the public interest because every transistor’s behavior can be verified.

Our Vision

We’re building computing infrastructure that can be fully verified—where organizations and individuals can audit every component from silicon to software.

For government and critical infrastructure: Deploy systems where security doesn’t depend on trusting opaque vendor firmware.

For research institutions: Study and teach processor architecture with complete visibility into implementation.

For industry: Build products on foundations you can inspect, modify, and maintain independently.

The Broader Context

PowerCommons emerges from a recognition that computational infrastructure shapes society as fundamentally as roads, utilities, and communications networks. When this infrastructure is opaque and privately controlled, democratic oversight becomes impossible. We’re creating an alternative: computing as commons—collectively maintained, transparently operated, publicly auditable.

Long-Term Vision (2027+)

These phases depend on successful completion of the SoC platform and securing production partnerships:

• Hardware production: ASIC fabrication or volume FPGA deployment, contingent on formal verification completion and manufacturing partnerships
• Infrastructure deployment: Sovereign compute services built on verified PowerCommons hardware, contingent on hardware availability and operational partnerships

Our Mission

To democratize access to high-performance, secure, and transparent computing by creating fully open-source processor implementations and system architectures that can be verified, modified, and deployed by anyone, anywhere, without proprietary dependencies or hidden backdoors.

Project Summary

Why This Matters

Digital Sovereignty

Every major processor today contains hidden management engines, proprietary firmware, and un-auditable code paths. PowerCommons changes this paradigm by ensuring every transistor’s behavior can be inspected and verified.

Post-Surveillance Computing

In alignment with post-capitalist visions of technology, PowerCommons creates computing infrastructure that serves communities rather than extracting value from them.

Technological Commons

Like public utilities and infrastructure, fundamental computing technology should be a commons - collectively owned, transparently operated, and democratically governed.

Get Involved

For Developers

• Code Repository: codeberg.org/PowerCommons
• Get Started: Getting Started Guide
• Matrix Chat: #powercommons:matrix.org

For Organizations

• Government & Critical Infrastructure: Deploy verifiable, sovereign computing
• Academic Institutions: Research and teach with fully transparent systems
• Industry Partners: Build secure products on open foundations

For Citizens

• Learn: Understand why open hardware matters for democracy
• Advocate: Support policies promoting open infrastructure
• Support: Contribute to sustainable development

Partners

Updates

September 30, 2025: NLnet Funding Proposals Submitted

Submitted NLNET funding proposal for A2O Core revival.

September 20, 2025: First Microwatt boot with LiteDRAM, clock and timing issues..

August 2025: MicroWatt VCU118 Success

Successfully booted Linux on VCU118 platform without DRAM.

July 2025: Project Inception

PowerCommons initiative launched with support from OpenPower Foundation.

PowerCommons is a public interest technology initiative aligned with European digital sovereignty goals and the principles of the commons.

Mission & Vision

Our Mission

To democratize high-performance computing by creating fully open, transparent, and verifiable processor architectures that serve as digital commons - collectively owned, democratically governed, and accessible to all.

PowerCommons develops and maintains open-source processor implementations, system architectures, and supporting infrastructure that eliminate proprietary dependencies, hidden functionalities, and corporate control over fundamental computing resources.

Our Vision

A Future of Sovereign Computing

We envision a world where:

• Every circuit is inspectable - No hidden management engines, no proprietary firmware, no unauditable code paths
• Communities control their infrastructure - Local sovereignty over digital resources, not dependency on foreign corporations
• Innovation serves humanity - Technology development guided by public interest, not surveillance capitalism
• Knowledge is truly free - Complete transparency from transistor to application, enabling genuine understanding and innovation

Join the Revolution

PowerCommons isn’t just building processors - we’re building the foundation for a democratic digital future. Every contribution, whether code, documentation, advocacy, or funding, advances our collective liberation from corporate control over computing.

The power of computing belongs to the people.

“The master’s tools will never dismantle the master’s house. We must build our own tools - transparent, democratic, and free.”
— Adapted from Audre Lorde for the digital age

Digital Sovereignty

Reclaiming Control Over Our Digital Infrastructure

Digital sovereignty is not merely about data localization or regulatory compliance - it’s about fundamental democratic control over the technologies that increasingly govern our lives. PowerCommons embodies this principle by creating computing infrastructure that communities can truly own, understand, and control.

The Crisis of Technological Dependence

Hidden Control Mechanisms

Every modern processor contains multiple layers of proprietary control:

• Management Engines: Intel ME, AMD PSP run below the operating system with full system access
• Proprietary Firmware: Unauditable code controlling critical functions
• Hardware Backdoors: Undocumented features accessible to manufacturers
• Supply Chain Vulnerabilities: Components from untrusted sources with unknown modifications

These mechanisms create fundamental vulnerabilities that no amount of software security can address.

Economic Extraction

The current computing paradigm extracts value through:

• Planned Obsolescence: Artificial limitations forcing constant upgrades
• Vendor Lock-in: Proprietary standards preventing migration
• Surveillance Capitalism: Data extraction as primary business model
• Rent-Seeking: Software-as-a-Service replacing ownership

PowerCommons breaks these extraction patterns by ensuring permanent ownership and control.

Technical Foundations of Sovereignty

Verifiable Security

True sovereignty requires the ability to verify every aspect of the system:

• Open Hardware: Every logic gate documented and inspectable
• Reproducible Builds: Identical outputs from source code
• Formal Verification: Mathematical proofs of security properties
• Transparent Supply Chain: Known origin of every component

Technological Independence

PowerCommons achieves independence through:

• No Proprietary Dependencies: Fully open stack from silicon to application
• Local Manufacturing Capability: Designs suitable for diverse fab processes
• Knowledge Transfer: Complete documentation and education
• Tool Chain Freedom: Open development tools throughout

Call to Action

For Policymakers

• Mandate Open Hardware: Require transparency in public procurement
• Fund Development: Support open processor initiatives
• Create Standards: Establish sovereignty requirements
• Build Capacity: Invest in local manufacturing

For Technologists

• Contribute Code: Develop open implementations
• Share Knowledge: Document and teach
• Build Tools: Create development infrastructure
• Form Networks: Connect with aligned projects

For Citizens

• Demand Transparency: Require open systems in public services
• Support Development: Contribute to funding campaigns
• Learn and Share: Understand and explain the importance
• Organize Locally: Build community technology initiatives

Resources

Essential Reading

• “The Age of Surveillance Capitalism” - Shoshana Zuboff
• “Radical Technologies” - Adam Greenfield
• “The Stack” - Benjamin Bratton
• “Platform Capitalism” - Nick Srnicek

Pioneering Organizations

• European Digital Rights (EDRi)
• Free Software Foundation Europe
• Chaos Computer Club
• La Quadrature du Net

Policy Documents

• EU Digital Sovereignty Strategy
• German Sovereign Tech Fund Charter
• Barcelona Digital Sovereignty Plan
• Amsterdam Digital Agenda

“Technology is the answer, but what was the question?”
— Cedric Price

The question is: How do we build technology that serves humanity rather than exploiting it? PowerCommons provides one answer: through radical transparency, democratic control, and the commons model.

Digital sovereignty is not a destination but a continuous process of reclaiming control over our technological future. Join us in building infrastructure for human flourishing rather than corporate extraction.

Why OpenPower

The Foundation for True Computing Freedom

A Proven Architecture with Deep Roots

OpenPower isn’t just another instruction set architecture - it’s a battle-tested technology with over 30 years of deployment in mission-critical systems. From the servers running banking infrastructure to the supercomputers modeling climate change, Power architecture has proven its reliability at scale.

Unlike emerging architectures that promise future potential, OpenPower delivers today with:

• Mature ecosystem: Decades of software support, tools, and expertise
• Production proven: Powers enterprise workloads globally
• Performance leadership: Consistently ranks in supercomputing top500
• Open governance: True community control through OpenPower Foundation

Comparison Matrix

Technical Superiority

Architecture Advantages

64-bit from the Ground Up
Power was designed as a 64-bit architecture from inception, not retrofitted like x86. This clean design yields:

• Consistent instruction encoding
• Efficient memory addressing
• Superior virtualization capabilities
• Hardware-enforced security boundaries

RISC Philosophy Done Right

• Fixed-length instructions for predictable decode
• Large register file (32 general purpose registers)
• Simple, orthogonal instruction set
• Powerful load/store architecture

Advanced Features

• Hardware transactional memory
• Decimal floating-point in hardware
• Advanced SIMD capabilities (VSX)
• Sophisticated branch prediction

Performance Characteristics

OpenPower processors excel in:

• Throughput Computing: Multiple execution units and deep pipelines
• Memory Bandwidth: Advanced cache hierarchies and memory controllers
• Parallel Processing: SMT4/SMT8 simultaneous multithreading
• Enterprise Reliability: ECC throughout, hardware error recovery

True Openness

While other architectures claim openness, OpenPower delivers:

Verification and Trust

With OpenPower’s open implementations:

• Every gate can be inspected
• No hidden backdoors possible
• Formal verification feasible
• Reproducible builds from source

Advisory Board

Leadership & Governance

PowerCommons operates under a collaborative governance model that balances technical expertise with democratic participation, ensuring our technology serves the public interest.

Advisory Board / Mentors

Prof. Peter Hofstee

Chief Technical Advisor
Distinguished Research Staff Member, IBM | Professor, Delft University of Technology

Prof. Peter Hofstee is a distinguished research staff member at IBM Austin and part-time professor in Big Data Systems at Delft University of Technology. He is best known as chief architect of the Synergistic Processor Elements in the Cell Broadband Engine processor, used in Sony’s PlayStation 3 and IBM’s Roadrunner supercomputer — the first system to achieve sustained petaflop operation in 2008. The A2 processor family — including the A2O core that PowerCommons aims to revive—was developed following IBM’s game console processor designs: the Xbox 360 processor and Hofstee’s Cell processor for the PlayStation 3. Prof. Hofstee’s pioneering work on the Cell architecture directly influenced the A2 family’s design philosophy. His decades of experience in high-performance heterogeneous computing and deep knowledge of the architectural lineage connecting Cell to A2O make him uniquely qualified to guide PowerCommons’ technical strategy for reviving and modernizing the A2O core for contemporary applications including AI workloads and open-source supercomputing.

Ganesan Narayanasamy

Mentor and Community Advisor
President, OpenPower Foundation | CEO - ObjectAutomation Inc.. Ganesan Narayanasamy is a technology leader with nearly three decades of experience at IBM, where he held leadership positions focused on high-performance computing, chip design, and artificial intelligence. He was instrumental in driving the OpenPOWER and AI ecosystem initiatives, with emphasis on partner enablement and market development, creating training programs for partners and supporting emerging market opportunities worldwide. As President of the OpenPOWER Foundation and CEO of Object Automation System Solutions Inc., Ganesan leads global initiatives to expand the OpenPOWER ecosystem through academic partnerships and industry collaboration. He actively collaborates with leading institutions including IIT Madras, IIT Roorkee, and IIT Ropar on Microwatt and chip design education initiatives ObjectAutomation, making him ideally positioned to guide PowerCommons’ technical direction and ecosystem development. His extensive experience in ecosystem building, partner enablement, and academic outreach provides PowerCommons with critical strategic guidance for community engagement, institutional partnerships, and long-term sustainability planning.

Partner Organizations

Institutional Partners

• OpenPower Foundation - Technical standards and ecosystem

Advisors We Seek to Engage

PowerCommons is actively reaching out to thought leaders and policy makers who can help advance digital sovereignty:

Policy & Government Leaders

Margrethe Vestager
Executive Vice-President, European Commission
A Europe Fit for the Digital Age

Roberto Viola
Director-General, DG CONNECT
European Commission digital policy

Cédric O
Former French Secretary of State for Digital
European tech sovereignty advocate

Marina Kaljurand
MEP, Former Estonian Foreign Minister
Digital rights and cybersecurity

Technology & Innovation

Mitchell Baker
CEO, Mozilla Corporation
Open internet and technology democracy

Eben Moglen
Columbia Law School, Software Freedom Law Center
Free software legal frameworks

Bruce Schneier
Harvard Kennedy School
Security technologist and policy fellow

Zeynep Tufekci
Columbia University
Technology and society researcher

Economic & Social Innovation

Mariana Mazzucato
UCL Institute for Innovation
Mission-oriented innovation and public value

Kate Raworth
Oxford University
Doughnut economics and regenerative design

Evgeny Morozov
Technology critic and researcher
Digital sovereignty and platform regulation

Trebor Scholz
The New School
Platform cooperativism

If you have connections to these leaders or similar advocates for digital sovereignty, please help us make contact

Community Partners

Building the Liberation Technology Ecosystem

PowerCommons thrives through collaboration with aligned organizations, communities, and initiatives working toward technological sovereignty, digital rights, and the commons.

Institutional Partners

OpenPower Foundation

Role: Technical Standards & Governance
Contribution: Architecture specifications, compliance testing, ecosystem coordination
Contact: openpowerfoundation.org

The OpenPower Foundation provides the technical and legal framework that makes PowerCommons possible. Their open governance model and patent pool ensure our work remains free and unencumbered.

Community Organizations

The Commune

Role: Post-Capitalist Technology Advocacy
Platform: Medium Publication
Focus: Critical analysis of technology under capitalism, alternative futures

The Commune provides essential political and philosophical context for why liberation technology matters.

The Sovereign Workshop

Role: Knowledge Dissemination
Format: Tutorials, workshops, documentation
Focus: Practical guides for building sovereign technology stacks

Transforming complex technical knowledge into accessible learning resources.

How to Become a Partner

For Organizations

1. Align with PowerCommons values and mission
2. Identify collaboration opportunities
3. Connect via [email protected]
4. Contribute through code, resources, or advocacy
5. Amplify the message of liberation technology

For Individuals

Join as a community partner by:

• Contributing code or documentation
• Organizing local events
• Translating materials
• Advocating for open hardware
• Teaching and mentoring

Partnership Principles

• Mutual Aid: Support flows in all directions
• Transparency: Open collaboration and communication
• Autonomy: Partners maintain independence
• Solidarity: United in liberation technology
• Sustainability: Long-term thinking and commitment

Current Needs

We’re actively seeking partners in:

• 🎓 Academic Research: Formal verification, security analysis
• 🏭 Manufacturing: PCB fabrication, ASIC production
• 💰 Funding: Grants, donations, sustainable revenue
• 🌍 Global Reach: Regional coordinators and translators
• 🛠️ Technical: FPGA experts, compiler developers
• 📢 Advocacy: Policy influence, public awareness

Partnership Benefits

• Early access to technology developments
• Influence on project direction
• Recognition in project materials
• Collaboration opportunities
• Shared resources and knowledge
• Building the commons together

Contact

coming soon!

“Alone we can do so little; together we can do so much.” - Helen Keller

PowerCommons succeeds through the collective effort of partners committed to liberation technology. Join us in building the technological commons.

Quick Start

Get Microwatt running on FPGA in under 30 minutes using prebuilt resources.

💬 Need Help? Stuck or have questions? Join #powercommons:matrix.org for real-time support from the community!

Prerequisites

• FPGA board - we’ve only tested Xilinx VCU-118 or Arty A7 100T
• Linux environment (native or WSL)
• USB cable for programming

Steps

1. Download Prebuilt Bitstream

For Xilinx VCU 118, download the following bitstream:

wget https://powercommons.org/downloads/microwatt-vcu118-no-dram-latest.bit

For Arty A7 100T, download the following bitstream:

wget https://powercommons.org/downloads/microwatt-artya7100t-no-dram-latest.bit

See Downloads for other images.

2. Program FPGA

Via Vivado:

vivado -mode batch -source program.tcl

Via OpenOCD:

openocd -f board/vcu118.cfg -c "init; pld load 0 microwatt-vcu118-latest.bit; exit"

3. Connect Serial Console

Determine the console your FPGA board’s output is connected to. Use the following commands to list all the USB devices:

ls /dev/ttyUSB*

Next, use a terminal software like screen or litex_term to connect to the terminal for output:

screen /dev/ttyUSB4 115200

Expected output:

Microwatt v0.1
Linux booting...

Next Steps

• Build from source
• Access UO remote systems
• Join community

No FPGA Hardware?

Use University of Oregon remote systems - free access for developers

Pre-built bit streams

This page lists pre-built bitstreams that can be used for testing or verifying your FPGA boards in case you have issues:

Development Environment

This page lists the minimum requirements for setting up the development toolchain as well as various tooling that’s required to build PowerCommons projects.

Minimum requirements and supported configurations

Currently, PowerCommons is only supported on X86/64 bit systems as 32 bit systems are limited to 4 GB in memory. There are workarounds available, but they are not officially supported or tested by the PowerCommons project.

Vivado is supported on the following operating systems on x86-64 processor architectures:

• Microsoft Windows Professional/Enterprise 10.0 22H2 Update
• Microsoft Windows 11.0 23H2 and 24H2 Update
• Red Hat Enterprise Workstation/Server 8.10, 9.4, 9.5, 9.6, and 10.0 (64-bit), English
• SUSE Linux Enterprise 15 SP4,15 SP6, and 15 SP7 (64-bit), English
• Amazon Linux 2 AL2023 LTS (64-bit)
• AlmaLinux 8.10, 9.4, 9.5, 9.6, and 10.0 (64-bit)
• Ubuntu Linux 22.04.3, 22.04.4, 22.04.5, 24.04, 24.04.1, and 24.04.2 (64-bit), English
• Rocky Linux 8.10, 9.6, and 10.0

Minimum Recommended Memory

We recommend a minimum of 32 GB of RAM for all PowerCommons related work. Technically, its possible to get the builds working for smaller FPGAs i.e. Arty A7 with 16 GB memory, but the builds will be painfully slow. Instead of wasting your time on slower systems, you can request access to our University of Oregon systems with powerful workstations and fully configured environment.

If you are building for any of the larger FPGA’s such as Xilinx VCU 118, we recommend at least 128 GB of RAM. Memory requirements for building for various boards are listed here

Common tooling - Required for all projects

You need to setup the following tools for all PowerCommon projects including Microwatt enhancements, A2O Revival and for A2O ISA Upgrade project. Installation and setup instructions for each of these components are also linked below. If you find an issue with the documentatinon, please open a ticket in our repository.

Microwatt

If you are planning to work with the Microwatt codebase, you additionally need the following tools:

A2O - Revival and Upgrade

No special tooling needed just yet.

Support

Issues? See Troubleshooting

WSL2 Ubuntu Setup

While not strictly a requirement, your development workflow might benefit from creating multiple WSL environments instead of using one environment for everything. By having multiple instances, you can cleanly isolate libraries, dependencies etc. and restart from clean state if need.

Installing WSL2 on Windows

This step is only required for Windows users. Linux users can skip this step. Before you continue with the steps below, make sure you have a working WSL 2 installation. For instructions on installing WSL 2 on Windows, follow the instructions on Microsoft’s website.

Next, verify that your WSL 2 installation. Open a Windows terminal or powershell and key in the wsl --version. You should see output similar to the following. Make sure your WSL version is also over 2.

> wsl --version
WSL version: 2.5.7.0
Kernel version: 6.6.87.1-1
WSLg version: 1.0.66
MSRDC version: 1.2.6074
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.7171

PowerCommons Ubuntu WSL Image - Automated Installation

You can use the following script to provision a complete WSL development environment for the PowerCommons project that includes all development dependencies, Litex, FuseSoc, OpenOCD etc.

Note

If you want to find your home directory, run the following in PowerShell: echo $env:USERPROFILE

To use this script, create a folder called .cloud-init in your Windows $HOME folder. Create a file called Ubuntu-24.04.user-data inside this folder and copy paste the following contents in this file:

#cloud-config
locale: en_US
users:
- name: powercommons
  gecos: Power Commons
  groups: [adm,dialout,cdrom,floppy,sudo,audio,dip,video,plugdev,netdev]
  sudo: ALL=(ALL) NOPASSWD:ALL
  shell: /bin/bash

write_files:
- path: /etc/wsl.conf
  append: true
  content: |
    [user]
    default=powercommons

packages: [git, libc6-dev-i386, net-tools, graphviz, make, unzip, zip, g++,
          xvfb,  libnss3-dev, libgdk-pixbuf2.0-dev, libgtk-3-dev,
          libxss-dev, libasound2-dev, openssl, fdisk, libsecret-1-dev, curl, wget,
          build-essential, libssl-dev, zlib1g-dev, libbz2-dev, libreadline-dev, libsqlite3-dev,
          libncurses-dev, xz-utils, tk-dev, libxml2-dev, libxmlsec1-dev, libffi-dev, liblzma-dev, libzstd-dev, tio,
          cmake, ninja-build, ccache, autoconf, automake, libtool, pkg-config,  gcc-powerpc64le-linux-gnu, g++-powerpc64le-linux-gnu, 
          binutils-powerpc64le-linux-gnu, flex, bison, bc, libssl-dev, libelf-dev, device-tree-compiler, qemu-system-ppc64, openocd]

runcmd:
   - sudo apt update && sudo apt -y upgrade
   - sudo git clone https://github.com/Microsoft/vcpkg.git /opt/vcpkg
   - /opt/vcpkg/bootstrap-vcpkg.sh
   - su - powercommons -c 'curl -fsSL https://pyenv.run | bash'
   - su - powercommons -c 'curl -s https://ohmyposh.dev/install.sh | bash -s'
   - su - powercommons -c 'ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519'
   # Write all bashrc entries
   - |
     su - powercommons -c 'cat >> ~/.bashrc << "EOF"
     export PYENV_ROOT="$HOME/.pyenv"
     [[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$HOME/.local/bin:$PATH"
     eval "$(pyenv init - bash)"
     eval "$(pyenv virtualenv-init -)"
     eval "$(oh-my-posh init bash --config ~/.cache/oh-my-posh/themes/atomic.omp.json)"
     EOF'
   # Chain pyenv commands in one shell with explicit env setup
   - |
     su - powercommons -c 'export PYENV_ROOT="$HOME/.pyenv" && \
       export PATH="$PYENV_ROOT/bin:$HOME/.local/bin:$PATH" && \
       eval "$(pyenv init -)" && \
       pyenv install 3.12 && \
       pyenv virtualenv 3.12 microwatt'
   - su - powercommons -c 'mkdir -p projects && cd projects && git clone https://codeberg.org/PowerCommons/microwatt.git'
   # LiteX in activated venv
   - |
     su - powercommons -c 'export PYENV_ROOT="$HOME/.pyenv" && \
       export PATH="$PYENV_ROOT/bin:$HOME/.local/bin:$PATH" && \
       eval "$(pyenv init -)" && \
       eval "$(pyenv virtualenv-init -)" && \
       pyenv activate microwatt && \
       pip3 install --upgrade fusesoc && \
       mkdir -p ~/projects/litex && cd ~/projects/litex && \
       wget https://raw.githubusercontent.com/enjoy-digital/litex/master/litex_setup.py && \
       chmod +x litex_setup.py && \
       ./litex_setup.py --init --install --config=standard'
   - sudo ln -s /usr/lib/x86_64-linux-gnu/libcurses.so /lib64/libncurses.so.6
   - sudo ln -s /usr/lib/x86_64-linux-gnu/libtinfo.so /lib64/libtinfo.so.5

Next, open a Windows Terminal or Powershell and run the following command. Note that the name of the distribution must match the name of the file you created above.

wsl --install -d Ubuntu-24.04 --name PowerCommons

Once the process completes, you will be logged into your new WSL instance.

Note

The cloud-config will:

1. Create a user named powercommons with the password powercommons and set it as default via /etc/wsl.conf
2. Create a python virtual environment called microwatt
3. Install all required packages and dependencies as listed in the packages section of the yml config above.
4. The script will create a folder called projects in the home folder of the user powercommons, clone microwatt repository, and install Litex with standard distribution.

Feel free to explore the yml configuration script above to understand what is installed and configured.

Creating an Ubuntu WSL 2 Instance - Manual installation

If you want to install and configure your WSL instance manually, you can run wsl --install -d Ubuntu-24.04 --name PowerCommonsA2OISAUpgrade. :

> wsl --install -d Ubuntu-24.04 --name PowerCommonsA2OISAUpgrade
Downloading: Ubuntu 24.04 LTS
Installing: Ubuntu 24.04 LTS
Distribution successfully installed. It can be launched via 'wsl.exe -d PowerCommonsA2OISAUpgrade'
Launching PowerCommonsA2OISAUpgrade...
Provisioning the new WSL instance PowerCommonsA2OISAUpgrade
This might take a while...
Create a default Unix user account: power2people
New password:
Retype new password:
passwd: password updated successfully
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
power2people@DESKTOP-P4O:/mnt/c/Users/anonymous$

Choose a username and a password when prompted and save it in a password manager - you will need it later. In the example above, we used power2people as the username. Once the process finishes, you will be logged in to the new instance and land at the shello.

This process will also install a shortcut by the name of PowerCommonsA2OISAUpgrade in your start menu in Windows. You can use this shortcut to launch the PowerCommonsA2OISAUpgrade Ubuntu instance later or after a restart.

Note that multiple shells can be opened simultaneously without interfering with each other. Refer to Ubuntu’s WSL documentation for details.

Creating multiple WSL instances

If you are going to be working on multiple projects, it is highly recommended to create multiple WSL 2 instances - one for each project to avoid mixing up libraries and for isolation. To creat a second instance using Ubuntu, just change the --name parameter for you new installation. For instance, you can have three WSL instaces - each dedicated to a specific project:

• wsl --install -d Ubuntu-24.04 --name A2ORevival : Creates an instance for A2O Revival project.
• wsl --install -d Ubuntu-24.04 --name A2OISAUpgrade : Creates an instance for A2O Upgrade project.
• wsl --install -d Ubuntu-24.04 --name Microwatt : Creates an instance for Microwatt project.

Next Steps

• Install Vivado

Vivado Installation

Vivado is required for synthesizing bitstream for FPGAs - both for Microwatt and for A2O.

The following steps are derived from the Vivado Design Suite User Guide: Release Notes, Installation, and Licensing (UG973)

Downloading Vivado

Download Vivado 2025.2 from AMD/Xilinx. This will require you to register and provide your details before downloading. All PowerCommons projects are built and tested with Vivado 2025.2. It is recommended to download the Single File Download if you will be creating multiple WSL instances - it will save you significant amount of time as you dowload the installer only once. However, this requires more disk space. If you don’t have a fast internet connection or have limited disk space, you can download the Unified Web installer for Linux.

Note

You need to dowload the Linux version even if you are using Windows as you main operating system. We will copy the installer to WSL Linux once we’re ready to install.

Assuming you are on Windows and downloaded the installer to `C:\Downloads\FPGAs_AdaptiveSoCs_Unified_SDI_2025.2_1114_2157.tar“, copy the installer to WSL instance. You can do it by running the following command from inside WSL Debian instance:

>cp /mnt/C/Downloads/FPGAs_AdaptiveSoCs_Unified_SDI_2025.2_1114_2157.tar ~

or if you downloaded the web installer:

>cp /mnt/C/Downloads/FPGAs_AdaptiveSoCs_Unified_SDI_2025.2_1114_2157_Lin64.bin ~

This will copy the installer to your home directory in WSL 2 Debian instance. Note this might take a few minutes depending upon your disk speed.

Installing Vivado Prerequisites

Before you actually install Vivado in your WSL 2 instance, install the prerequisites. In many cases, the installer can fail if the required libraries are missing. Vivado 2025 includes a script to check for and install any missing libraries. For both the Unified Single File Download (SFD) and the Webinstaller, the installLibs.sh script is located at the image root. To access the image root area with the Webinstaller, use the following command in batch mode on a Linux machine to extract the image.

><Download_Dir>/FPGAs_AdaptiveSoCs_Unified_202X.Y_MMDD_HHMM_Lin64.bin –keep --noexec --target <WI_Client_Dir>

Replace <WI_Client_Dir> with the target directory where you want to extract the files. Alternatively, if you are using the tar file, you can extract the files as shown below:

> tar -xvf FPGAs_AdaptiveSoCs_Unified_SDI_2025.2_1114_2157.tar

Once the files are extracted, you will find a script called installLibs.sh. This script will install all the libraries required for Vivado installation.

> cd FPGAs_AdaptiveSoCs_Unified_SDI_2025.2_1114_2157
>  sudo ./installLibs.sh
[sudo] password for power2people:
ubuntu-24 install
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Get:4 http://archive.ubuntu.com/ubuntu noble-backports InRelease [126 kB]
Get:5 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages [15.0 MB]
Get:6 http://archive.ubuntu.com/ubuntu noble/universe Translation-en [5982 kB]
....
....
Preparing to unpack .../5-libsecret-1-dev_0.21.4-1build3_amd64.deb ...
Unpacking libsecret-1-dev:amd64 (0.21.4-1build3) ...
Setting up libgpg-error-dev (1.47-3build2.1) ...
Setting up libsecret-common (0.21.4-1build3) ...
Setting up libsecret-1-0:amd64 (0.21.4-1build3) ...
Setting up gir1.2-secret-1:amd64 (0.21.4-1build3) ...
Setting up libgcrypt20-dev (1.10.3-2build1) ...
Setting up libsecret-1-dev:amd64 (0.21.4-1build3) ...
Processing triggers for libc-bin (2.39-0ubuntu8.6) ...
Processing triggers for man-db (2.12.0-4build2) ...
Processing triggers for install-info (7.1-3build2) ...
INFO: For more information please check /home/power2people/FPGAs_AdaptiveSoCs_Unified_SDI_2025.2_1114_2157/installLibs.sh_2025-12-13_15-36-28 log.

Now you are ready to install Vivado.

Vivado Installation

To launch the vivado installer, lanunch the installer binary as shown below:

> sudo chmod +x FPGAs_AdaptiveSoCs_Unified_20XX.Y_MMDD_HHMM_Lin64.bin
> ./FPGAs_AdaptiveSoCs_Unified_20XX.Y_MMDD_HHMM_Lin64.bin

Alternatively, if you downloaded the SDI tar file, launch the installer from the folder (FPGAs_AdaptiveSoCs_Unified_SDI_2025.2_1114_2157) extracted above:

>./xsetup

From the list of products to install, select Vivado. Note that you only need Vivado to work with PowerCommons projects - you don’t need Vitis or any other products. On the next screen, choose Vivado ML Enterprise if you have a license or alternatively choose Vivado ML standard. Remove any unnecessary Vitis or other components - you only need the minimum components as shown below along with components specific to your FPGA device (Ultrascale+ in this case).

Click next to continue.

Accept the license and usage terms, click next to continue.

Specify an installation directory and click next to continue.

Review the installation summary and click Install to start the installation. Wait for the installer to download the files in case you are using web installer - it can take 30-60 minutes or even longer on slower internet connections.

Setting up Vivado Paths for terminal utilities

Once the installation is complete, add Vivado to your path. The following assumes you are using bash on WSL 2 but the process is similar for other shells too:

# Open your .bashrc file in vim editor
> echo 'source <PathToXilinxInstallationDIR>/Vivado/2025.2/settings64.sh' >> ~/.bashrc

Replace PathToXilinxInstallationDIR with the path to Xilinx installation folder from the previous step.

Installing USB drivers and pass through on Windows

The final step in Vivado installation on WSL is to allow USB passthrough from Windows to WSL 2.

Install USBIPD on Windows 11

Note

Vivado is not supported on ARM platforms. Please make sure you download the installer for your AMD/Intel based machines.

Go to the USBIPD Release Page and download the latest x64 installer for Windows. You may get a warning asking you to confirm that you trust this download. Run the downloaded usbipd-win_x.msi installer file. Running the installer will install:

• A service called usbipd (display name: USBIP Device Host). You can check the status of this service using the Services app from Windows.
• A command line tool usbipd. The location of this tool will be added to the PATH environment variable.
• A firewall rule called usbipd to allow all local subnets to connect to the service. You can modify this firewall rule to fine tune access control.

List all of the USB devices connected to Windows by opening PowerShell in administrator mode and entering the following command. Once the devices are listed, select and copy the bus ID of the device you’d like to attach to WSL.

usbipd list

Before attaching the USB device, the command usbipd bind must be used to share the device, allowing it to be attached to WSL. This requires administrator privileges. Select the bus ID of the device you would like to use in WSL and run the following command. After running the command, verify that the device is shared using the command usbipd list again.

usbipd bind --busid 4-4

To attach the USB device, run the following command. (You no longer need to use an elevated administrator prompt.) Ensure that a WSL command prompt is open in order to keep the WSL 2 lightweight VM active. Note that as long as the USB device is attached to WSL, it cannot be used by Windows. Once attached to WSL, the USB device can be used by any distribution running as WSL 2. Verify that the device is attached using usbipd list. From the WSL prompt, run lsusb to verify that the USB device is listed and can be interacted with using Linux tools.

usbipd attach --wsl --busid <busid>

Open Ubuntu (or your preferred WSL command line) and list the attached USB devices using the command:

>lsusb

You should see the device you just attached and be able to interact with it using normal Linux tools. This should be sufficient to access the device from Vivado and other utilities. However, in some cases, you may need to configure udev rules to allow non-root users to access the device.

Once you are done using the device in WSL, you can either physically disconnect the USB device or run this command from PowerShell:

usbipd detach --busid <busid>

To learn more about how this works, see the Windows Command Line Blog and the usbipd-win repo on GitHub.

Warning

You will have re-bind the USB device if you re-start or disconnect your FPGA board.

Install Digilent Board files

This step is only required if you are using any of Digilent Boards such as Arty A7 100T. If you are using Xilinx boards such as VCU-118, skip this step.

To install BSP files, launch vivado from WSL:

>vivado

Once Vivado starts, select Vivado Store from the Tools menu:

Check the “Don’t show this dialog again” checkbox and click ok.

In the Vivado Store Window, click on “Boards Tab”. In the left tree pane, look for Digilent Inc. Expand the tree node and then expand the child “Single Part” tree node and look for your device. For example, if you are installing for Arty A7 100T, select the device from the tree and click on Download button on the top. Once the donwload button finishes, you will see a green tick against the device name indicating the BSP files have been installed. Click close and exist the Vivado Store.

Next Steps

• Build your first bitstream

Version Compatibility

PowerCommons projects target Vivado 2025.x. Using older versions (2023.x, 2024.x) may require constraint updates.

LiteX Setup

LiteX SoC builder framework for generating DDR controllers, peripherals, and SoC infrastructure.

Installation

1. Install LiteX

# Using pip (recommended)
pip3 install --user litex litex-boards

# Verify
python3 -c "import litex; print(litex.__version__)"

2. Clone LiteX Ecosystem (for development)

mkdir ~/litex && cd ~/litex
wget https://raw.githubusercontent.com/enjoy-digital/litex/master/litex_setup.py
chmod +x litex_setup.py

./litex_setup.py --init --install --user

This installs:

• litex - Core framework
• litex-boards - Board definitions
• litedram - DDR controller generator
• liteeth - Ethernet MAC/PHY
• litepcie - PCIe controller
• litesata - SATA controller

Test LiteX

Generate a simple SoC

# For VCU-118
litex_soc --board vcu118 --cpu-type microwatt --build

# For Arty A7
litex_soc --board arty --cpu-type vexriscv --build

Build time: ~5-10 minutes.

LiteDRAM for DDR4

PowerCommons uses LiteDRAM for VCU-118 DDR4 memory.

Test DDR4 initialization

cd ~/litex/litedram
./litedram_gen.py --sdram-module MT40A512M16 --sdram-data-width 64

PowerPC Support in LiteX

PowerCommons has contributed Microwatt (PowerPC) CPU support to LiteX.

Check CPU options

litex_soc --cpu-list | grep -i power

Expected output:

microwatt

Configuration for VCU-118

Example build command:

litex_soc \
    --board vcu118 \
    --cpu-type microwatt \
    --cpu-variant standard \
    --sys-clk-freq 100e6 \
    --integrated-rom-size 0x10000 \
    --integrated-sram-size 0x2000 \
    --with-ethernet \
    --build

Output: build/vcu118/gateware/vcu118.bit

Directory Structure

~/litex/
├── litex/               # Core framework
├── litex-boards/        # Board support
├── litedram/            # DDR controllers
├── liteeth/             # Ethernet
├── litepcie/            # PCIe
└── litesata/            # SATA

Environment Variables

Add to ~/.bashrc:

export PATH=$HOME/.local/bin:$PATH
export LITEX_BOARDS=$HOME/litex/litex-boards

Common Issues

“Command not found: litex_soc”

export PATH=$HOME/.local/bin:$PATH

“Board not found”

pip3 install --user --upgrade litex-boards

Synthesis errors with Vivado Ensure Vivado is in PATH:

source /opt/Xilinx/Vivado/2025.1/settings64.sh

Advanced: Custom SoC Configuration

Create soc_config.py:

from litex_boards.targets import vcu118
from litex.soc.cores.cpu import Microwatt

class CustomSoC(vcu118.BaseSoC):
    def __init__(self):
        super().__init__(
            cpu_type="microwatt",
            sys_clk_freq=125e6,
            with_ethernet=True
        )

if __name__ == "__main__":
    soc = CustomSoC()
    soc.build()

Run:

python3 soc_config.py

Documentation

• LiteX Wiki: github.com/enjoy-digital/litex/wiki
• PowerCommons LiteX integration: Projects → Microwatt → LiteX Integration

Next Steps

• Install PowerPC Toolchain
• Build first bitstream

PowerPC Toolchain

Build Linux kernels and software for PowerPC targets.

Quick Install (Debian/Ubuntu)

sudo apt install -y \
    gcc-powerpc64-linux-gnu \
    g++-powerpc64-linux-gnu \
    binutils-powerpc64-linux-gnu

Verify:

powerpc64-linux-gnu-gcc --version

Test Cross-Compilation

Hello World

// hello.c
#include <stdio.h>
int main() {
    printf("Hello from PowerPC!\n");
    return 0;
}

Compile:

powerpc64-linux-gnu-gcc -o hello hello.c
file hello

Expected:

hello: ELF 64-bit MSB executable, 64-bit PowerPC

Linux Kernel Build

1. Get Kernel Source

git clone --depth 1 -b v6.1 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux

2. Configure for Microwatt

make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- microwatt_defconfig

Or for custom config:

make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- menuconfig

3. Build

make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- -j$(nproc)

Build time: 10-30 minutes depending on CPU.

Output: arch/powerpc/boot/zImage

Device Tree Compilation

Install DTC

sudo apt install -y device-tree-compiler

Compile DTB

dtc -I dts -O dtb -o microwatt.dtb microwatt.dts

Decompile for inspection

dtc -I dtb -O dts microwatt.dtb

Endianness

PowerPC is big-endian. Common issues:

// Wrong (host endian)
uint32_t val = *(uint32_t*)ptr;

// Correct (explicit)
uint32_t val = be32_to_cpu(*(uint32_t*)ptr);

Or in userspace:

#include <endian.h>
uint32_t val = be32toh(raw_val);

Environment Variables

For kernel builds, add to ~/.bashrc:

export ARCH=powerpc
export CROSS_COMPILE=powerpc64-linux-gnu-

Then simply:

make microwatt_defconfig
make -j$(nproc)

Common Issues

“Compiler not found”

sudo apt install -y gcc-powerpc64-linux-gnu

“Cannot execute binary” Cross-compiled binaries only run on PowerPC hardware or QEMU:

sudo apt install -y qemu-user-static
qemu-ppc64-static ./hello

Toolchain for A2O

A2O uses same PowerPC64 toolchain. Additional flags may be needed for specific ISA features:

powerpc64-linux-gnu-gcc -mcpu=power7 -maltivec -o program program.c

Next Steps

• Build your first bitstream
• Microwatt Linux Boot

First Bitstream Build

Step-by-step guide to synthesize and program Microwatt on FPGA.

Choose Your Path

Option A: Microwatt Native Build (FuseSoC)

Best for: Understanding Microwatt internals, VHDL development

Option B: LiteX SoC Build

Best for: Quick SoC prototyping, adding peripherals

Option A: Microwatt Native Build

1. Install FuseSoC

pip3 install --user fusesoc

2. Clone Microwatt

git clone https://github.com/antonblanchard/microwatt
cd microwatt

Or PowerCommons VCU-118 fork:

git clone https://codeberg.org/PowerCommons/microwatt-vcu118
cd microwatt-vcu118

3. Build Hello World

make -C hello_world

Output: hello_world/hello_world.hex

4. Synthesize for FPGA

For Arty A7:

fusesoc run --target=arty_a7-100 microwatt --memory_size=16384 --ram_init_file=hello_world/hello_world.hex

For VCU-118 (PowerCommons fork):

fusesoc run --target=vcu118 microwatt

Build time: 30-60 minutes

Output: build/microwatt_*/arty_a7-100-vivado/microwatt_*.bit

5. Program FPGA

openocd -f board/arty_a7.cfg -c "init; pld load 0 microwatt.bit; exit"

Or with Vivado:

vivado -mode batch -source program.tcl

6. Connect Serial Console

screen /dev/ttyUSB1 115200

Press reset. You should see:

Hello World

Option B: LiteX SoC Build

1. Build SoC

For VCU-118:

cd ~/litex/litex-boards/litex_boards/targets
python3 vcu118.py \
    --cpu-type=microwatt \
    --sys-clk-freq=100e6 \
    --with-ethernet \
    --build \
    --load

For Arty A7:

python3 arty.py \
    --cpu-type=vexriscv \
    --with-ethernet \
    --build \
    --load

Build time: 15-40 minutes

2. Console Access

LiteX provides litex_term:

litex_term /dev/ttyUSB1

Expected:

        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

LiteX SoC on VCU118

Build Optimization

Faster Synthesis

Use Vivado’s performance settings:

set_param general.maxThreads 8

Or in LiteX:

python3 vcu118.py --cpu-type=microwatt --vivado-synth-directive PerformanceOptimized

Verify Build Success

Check Resource Utilization

Open in Vivado:

vivado build/*/microwatt.xpr

Navigate to: Reports → Utilization

Expected for Microwatt on Arty A7:

• LUTs: ~5,000 (5%)
• FFs: ~3,000 (3%)
• BRAM: 20 (30%)

Expected for Microwatt on VCU-118:

• LUTs: ~8,000 (<1%)
• FFs: ~5,000 (<1%)
• BRAM: 40 (3%)
• Plenty of room for expansion!

Check Timing

cat build/*/microwatt.runs/impl_1/*_timing_summary.txt | grep "WNS"

WNS (Worst Negative Slack) should be positive:

WNS: 2.341 ns

If negative, design won’t meet timing. Reduce clock frequency.

Troubleshooting Build Errors

“Vivado not found”

source /opt/Xilinx/Vivado/2025.1/settings64.sh

Synthesis fails with timing errors

• Reduce --sys-clk-freq
• Add timing constraints
• Check Troubleshooting

“Memory file not found” Ensure hello_world.hex exists:

make -C hello_world
ls -l hello_world/hello_world.hex

Out of memory during build Increase swap or reduce threads:

export MAKEFLAGS="-j2"

Next Steps

Boot Linux

See Microwatt LiteX Integration for Linux boot.

Add Custom Logic

Modify VHDL in microwatt/:

• core.vhdl - CPU core
• soc.vhdl - SoC wrapper
• fpga/*.vhdl - Board-specific

Modify SoC Configuration

LiteX allows Python-based SoC building:

from litex_boards.targets.vcu118 import BaseSoC

class MySoC(BaseSoC):
    def __init__(self):
        super().__init__(cpu_type="microwatt")
        # Add custom peripherals
        self.add_custom_peripheral()

Build Time Reference

Congratulations! You’ve built your first OpenPower bitstream.

Troubleshooting

Common issues and solutions.

Environment Setup

Vivado Not Found

Symptom: vivado: command not found

Solution:

source /opt/Xilinx/Vivado/2025.1/settings64.sh

# Make permanent
echo 'source /opt/Xilinx/Vivado/2025.1/settings64.sh' >> ~/.bashrc

Python Import Errors

Symptom: ModuleNotFoundError: No module named 'litex'

Solution:

pip3 install --user litex litex-boards
export PATH=$HOME/.local/bin:$PATH

USB Permission Denied

Symptom: Error: libusb_open() failed with LIBUSB_ERROR_ACCESS

Solution:

# Temporary
sudo chmod 666 /dev/ttyUSB*

# Permanent
sudo usermod -a -G dialout $USER
# Logout and login

Build Errors

Synthesis Fails - Timing

Symptom:

CRITICAL WARNING: Timing constraints are not met
WNS: -1.234ns

Solution:

Reduce clock frequency:

# LiteX
python3 vcu118.py --sys-clk-freq=80e6  # Was 100e6

Out of Memory

Symptom: Build crashes, system freezes

Solution:

# Limit parallel jobs
export MAKEFLAGS="-j2"

# Increase swap
sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

License Error

Symptom: License checkout failed

Solution:

# Check license
echo $XILINXD_LICENSE_FILE

# Or run license manager
vlm &

For VCU-118, you need Standard edition license (eval or purchased). WebPACK doesn’t support Ultrascale+.

Missing FPGA Part

Symptom: Part xcvu9p not found

Solution:

Re-run installer to add Ultrascale+ device support:

sudo /opt/Xilinx/Vivado/2025.1/xsetup

FPGA Programming

Cable Not Detected

Symptom: No devices detected

Solution:

1. Check USB connection:

lsusb | grep Xilinx

2. Install cable drivers:

cd /opt/Xilinx/Vivado/2025.1/data/xicom/cable_drivers/lin64/install_script/install_drivers
sudo ./install_drivers

3. WSL users - USB passthrough:

usbipd list
usbipd attach --wsl --busid X-X

Programming Fails

Symptom: Programming failed at 30%

Solution:

• Check power supply to board
• Verify correct .bit file for board
• Try lower JTAG frequency:

openocd -c "adapter speed 1000" -f board/vcu118.cfg

Serial Console

No Output

Symptom: Screen is blank after programming

Solution:

1. Check baud rate:

screen /dev/ttyUSB1 115200  # Not 9600

2. Check correct USB port:

ls -l /dev/ttyUSB*
# Usually ttyUSB0 = JTAG, ttyUSB1 = UART

3. Check FPGA programmed:

• Look for LEDs on board
• Run lsusb, should show Xilinx device

4. Try reset:

• Press reset button on board
• Power cycle

Garbled Output

Symptom: Random characters

Solution:

Clock frequency mismatch. Check UART clock divider matches system clock.

Boot Issues

Linux Kernel Panics

Symptom:

Kernel panic - not syncing: VFS: Unable to mount root fs

Solution:

1. Check device tree:

dtc -I dtb -O dts microwatt.dtb | grep memory

2. Verify initrd:

file rootfs.cpio.gz
# Should be gzip compressed

3. Check bootargs:

console=ttyS0,115200 root=/dev/ram0

Hangs at Boot

Symptom: Boot stops at “Starting kernel…”

Solution:

• Enable early printk in kernel config
• Check memory controller initialization
• Verify DDR4 timing constraints

LiteX Specific

Build Fails - Yosys

Symptom: Yosys not found

Solution:

cd ~/litex
./litex_setup.py --install --user

SoC Build Fails - Missing Board

Symptom: Board vcu118 not found

Solution:

pip3 install --user --upgrade litex-boards

Performance Issues

WSL Builds Slow

Symptom: Build takes 3x longer than expected

Solution:

Move project to WSL filesystem:

# Bad (slow)
cd /mnt/c/Users/name/projects

# Good (fast)
cd ~/projects

File I/O across WSL/Windows boundary is slow.

Vivado GUI Sluggish

Symptom: Vivado GUI freezes, slow

Solution:

1. Use batch mode when possible:

vivado -mode batch -source build.tcl

2. Resource limits: Ensure WSL has enough RAM (see .wslconfig)

Getting Help

Still stuck?

1. Check logs:

cat build/*/vivado.log

2. Community:

• Matrix: #powercommons:matrix.org
• Codeberg: codeberg.org/PowerCommons

3. Upstream:

• Microwatt: github.com/antonblanchard/microwatt
• LiteX: github.com/enjoy-digital/litex/wiki
• Vivado: xilinx.com/support

4. Provide details:

• OS and version
• Vivado version
• Complete error log
• Steps to reproduce

Projects Overview

Building the Open Computing Stack

PowerCommons develops interconnected projects that together create a complete, transparent, and sovereign computing platform. Each project advances specific technical goals while contributing to the larger vision of liberation technology.

Core Processor Projects

✅ Microwatt Xilinx VCU-118 Integration

Status: In Progress | Estimate: October 2025

Successfully integrated Microwatt processor with enterprise-grade Xilinx VCU-118 board, enabling Linux boot.

Achievements: ✅ Added VCU-118 support to Microwatt SoC (FuseSoC + VHDL). This additionally sets up LEDs to debug issues with clock, reset signal, UART etc. ✅ Extended Microwatt SoC LiteDRAM support to VCU-118 board 🟡 Fixed LitexBios and LitexSoC to support Linux on Microwatt as Litex BIOS was only designed to boot RISC V.

Why It Matters: Established VCU-118 as the primary development platform for high-end OpenPower FPGA work.

Learn More → | Repository

🔥 PowerCommons A2O: OpenPower A2O Core Revival

Status: Active Development | Target: Q4 2025

Reviving IBM’s battle-tested A2O processor - the out-of-order superscalar core that powered Blue Gene/Q supercomputers. This enterprise-grade processor brings serious computational power to the open hardware ecosystem.

Key Objectives:

• Restore compatibility with modern FPGA toolchains
• Fix timing closure and synthesis issues
• Create comprehensive documentation
• Establish software toolchain

Why It Matters: A2O provides the high-performance computing capability needed for real-world workloads, from scientific computing to database servers.

Learn More → | Repository

🏗️ PowerCommons SoC Platform

Status: Architecture Phase | Target: 2026

Creating the world’s first fully open System-on-Chip with verifiable security from boot to application. Combines Microwatt (control) and A2O (compute) processors in a heterogeneous architecture.

Key Objectives:

• Integrate dual-core heterogeneous design
• Implement open BMC replacement
• Create secure boot architecture
• Develop complete firmware stack

Why It Matters: Eliminates the last proprietary components in modern computing systems, including the hidden management engines.

Learn More →

Project Integration Strategy

┌─────────────────────────────────────────────┐
│            PowerCommons Platform            │
├─────────────────────────────────────────────┤
│                                             │
│  ┌─────────────┐      ┌─────────────┐      │
│  │  Microwatt  │◄────►│     A2O     │      │
│  │   (Boot)    │      │  (Compute)  │      │
│  └─────────────┘      └─────────────┘      │
│         ▲                    ▲              │
│         └────────┬───────────┘              │
│                  ▼                          │
│         ┌─────────────┐                    │
│         │    LiteX    │                    │
│         │  Framework  │                    │
│         └─────────────┘                    │
│                  ▼                          │
│  ┌──────────────────────────────────┐      │
│  │     Peripherals & Memory         │      │
│  └──────────────────────────────────┘      │
│                                             │
└─────────────────────────────────────────────┘

“The future is not some place we are going, but one we are creating. The paths are not to be found, but made.” - John Schaar

Microwatt Integration

Open PowerPC Core on Modern FPGAs

Overview

Microwatt is an open-source PowerPC soft core developed by Anton Blanchard and IBM. PowerCommons has extended Microwatt to run on high end FPGA platforms with full Linux support.

Core: Microwatt v0.1
Architecture: PowerPC 64-bit
Platform: Xilinx VCU-118
Status: Linux operational

Development Work

Native Microwatt SoC

Implementation using Microwatt’s native build system (FuseSoC/VHDL):

• VCU-118 board support with debug capabilities
• DDR4 memory integration via LiteDRAM
• Linux boot from native Microwatt

Details →

LiteX Framework Integration

Integration of Microwatt into LiteX SoC framework:

• PowerPC support in LiteX BIOS
• Endianness and boot protocol fixes
• Linux boot through LiteX infrastructure

Details →

Key Achievements

Upstream Contributions

• Microwatt: VCU-118 platform support
• LiteX: PowerPC architecture fixes
• LiteDRAM: DDR4 timing configurations

Resources

• Microwatt Repository
• PowerCommons Fork
• Build Documentation

Microwatt SoC on VCU-118

Overview

Implementation of Microwatt SoC on Xilinx VCU-118 using the native Microwatt build system (FuseSoC/VHDL). This work establishes basic board support, DDR4 and debugging capabilities.

Platform: Xilinx VCU-118 (XCVU9P FPGA)
Build System: FuseSoC
Language: VHDL

Task 1: Basic build support for VCU-118

Objective

Update the build system and add build options for Xilinx VCU 118.

Implementation

Added build definition in microwatt core along with pin constraints (xdc) and a bare minimum top level file for the board.

Task 2: Constraint Updates, Top Level Entity and Architecture

Task 3: Re-compile the firmware and Re-build

Task 3: Add GPIO Debug LEDs for Hardware Troubleshooting

Objective

Add VCU-118 as a supported platform in Microwatt with GPIO-based debugging capabilities to diagnose bring-up issues.

Implementation

Created FuseSoC core files and VHDL top-level for VCU-118:

# Build commands
fusesoc run --target=vcu118 microwatt --ram_init_file=hello_world.hex

Debug LED mapping for hardware troubleshooting:

• LED 0: PLL lock status
• LED 1: Reset state
• LED 2-3: UART TX/RX activity
• LED 4-7: User-defined debug signals

-- Debug LED connections in top-level VHDL
leds(0) <= pll_locked;
leds(1) <= not soc_rst;
leds(2) <= uart_tx;
leds(3) <= uart_rx;

[Screenshot placeholder: VCU-118 board with LEDs showing successful clock lock]

Running Microwatt (No DRAM)

# Build the bitstream without DRAM
[Build command placeholder]

# Generate hello world binary
[Compile command placeholder]

# Program the FPGA
[Programming command placeholder]

# Connect to UART console
[Serial terminal command placeholder]

Challenges Solved

• Clock domain crossing from 300MHz input to 100MHz system clock
• Pin assignment for mixed voltage I/O standards
• Reset sequencing for stable initialization

Code: codeberg.org/PowerCommons/microwatt-vcu118

Task 4: Generating LiteDRAM core

Objective

Integrate LiteDRAM DDR4 controller to access the VCU-118’s 4GB memory, enabling Linux boot.

Implementation

Extended the basic VCU-118 support with DDR4 memory:

# LiteDRAM configuration
class VCU118DDR4(Module):
    def __init__(self, sys_clk_freq=125e6):
        self.submodules.ddrphy = USDDRPHY(
            pads = platform.request("ddram"),
            memtype = "DDR4",
            sys_clk_freq = sys_clk_freq,
            cmd_latency = 1
        )

Memory initialization sequence:

1. Assert DDR4 reset for 500us minimum
2. Configure PHY with training patterns
3. Execute read/write leveling
4. Verify with memory test
5. Report status via UART

[Screenshot placeholder: Terminal showing DDR4 training completion and memory test pass]

Task 5: Updating signal/pin mapping

Task 6: Upgrading LiteDRAM Wrapper

Task 7: Building and Running

Running Microwatt with DRAM

# Build Microwatt with LiteDRAM
[Build command with DRAM placeholder]

# Generate memory test binary
[Memory test compile placeholder]

# Program FPGA with DRAM support
[FPGA programming command placeholder]

# Run memory test
[Memory test execution placeholder]

# Load and boot Linux kernel
[Linux boot command placeholder]

Results

• Bandwidth: 1.6 GB/s sustained
• Size: 256MB mapped (4GB physical available)
• Stability: 48-hour memtest passed

Code: codeberg.org/PowerCommons/litedram-vcu118

LiteX SoC with Microwatt on VCU-118

PowerPC Support in LiteX Framework

Overview

Integration of Microwatt PowerPC core into the LiteX SoC framework, enabling Linux boot through LiteX’s infrastructure. This required fixing numerous RISC-V assumptions in LiteX.

Platform: Xilinx VCU-118
Framework: LiteX
CPU: Microwatt PowerPC

Task: PowerPC Boot Support in LiteX

Objective

Adapt LiteX SoC and BIOS to boot PowerPC Linux, fixing RISC-V assumptions throughout the codebase.

Implementation

Key fixes for PowerPC compatibility:

Endianness handling - PowerPC is big-endian:

// Fixed MMIO access for PowerPC
#ifdef __powerpc__
#define readl(addr) __builtin_bswap32(*(uint32_t *)(addr))
#define writel(val, addr) *(uint32_t *)(addr) = __builtin_bswap32(val)
#endif

Boot protocol - PowerPC uses function descriptors:

// Correct Linux entry for PowerPC
typedef struct {
    void *entry;
    void *toc;
} func_desc_t;

func_desc_t *desc = (func_desc_t *)KERNEL_ADDR;
void (*kernel_entry)(void) = desc->entry;

Memory layout - Fixed for PowerPC requirements:

• Kernel at 0x400000 (not RISC-V’s 0x40000000)
• Exception vectors at 0x0
• Device tree at 0xf00000

# Build and boot Linux
./build_kernel.sh
litex_term /dev/ttyUSB1 --kernel=linux.bin --kernel-adr=0x400000

[Screenshot placeholder: Linux boot messages on serial console]

Running Linux on LiteX/Microwatt

# Build LiteX SoC with Microwatt
[LiteX build command placeholder]

# Build Linux kernel for PowerPC
[Kernel build command placeholder]

# Build device tree
[DTB build command placeholder]

# Program FPGA with complete SoC
[FPGA programming placeholder]

# Boot Linux via serial terminal
[Linux serial boot command placeholder]

# Alternative: Boot from SPI flash
[SPI flash boot command placeholder]

Boot Performance

LiteX BIOS on Microwatt/VCU-118
CPU:    100MHz
RAM:    256MB
Kernel: 2.3MB loaded
Boot:   45 seconds to prompt

Bugs Fixed

• Wrong entry point handling for PowerPC
• Endianness issues in all MMIO access
• Memory barriers for PowerPC architecture
• Cache management operations
• Exception vector locations

Code: codeberg.org/PowerCommons/litex-powerpc

PowerCommons A2O - A2O Core Revival

💬 Get Involved! Join the A2O revival discussion on Matrix: #powercommons:matrix.org - connect with developers, share ideas, and help bring this legendary processor back to life!

Project Overview

The PowerCommons A2O initiative revives and modernizes IBM’s A2O processor core - a proven architecture that powered the world’s most powerful supercomputers. By making this enterprise-grade technology accessible on modern FPGA platforms, we’re democratizing access to high-performance, transparent computing.

Project Status: 🟡 Active Development Timeline: September 2025 - March 2026 Funding: €50,000 (NLnet Foundation - pending) Repository: codeberg.org/PowerCommons/powercommons-a2o

Why A2O?

Proven Heritage

The A2O processor isn’t experimental - it’s battle-tested technology that ran in production for years:

• Powered Blue Gene/Q supercomputers
• Achieved 16.32 petaflops in Sequoia system
• Demonstrated reliability at massive scale
• Optimized for power efficiency

Technical Excellence

• 64-bit PowerPC Architecture: Full ISA 2.06 compliance
• Out-of-Order Execution: Advanced performance optimization
• Multi-Threading: 4-way SMT capability
• Vector Processing: QPX floating-point unit
• Cache Hierarchy: Sophisticated L1/L2 cache design

Open Liberation

IBM released A2O as open source, but the code has suffered from:

• Incompatibility with modern toolchains
• Broken build systems
• Missing documentation
• Lack of community support

PowerCommons fixes these issues, making A2O accessible to everyone.

Technical Objectives

Phase 1: Infrastructure Setup (Months 1) 🚧✅

• Assess current codebase state
• Identify toolchain incompatibilities
• Document build requirements
• Establish development environment

Phase 2: Core Revival, Implementation & Software (Months 3-4) 🚧

• Fix Vivado 2025.x compatibility issues
• Resolve timing closure problems
• Update synthesis constraints
• Create automated build system

Phase 3: Integration and Documentation (Months 5-6) 📋

• Implement missing peripherals
• Add LiteX integration
• Create FPGA reference designs
• Roadmap

Current Challenges

Build System Issues

// Example of outdated synthesis directive
(* ram_style = "block" *)  // Vivado 2025 requires different syntax
reg [63:0] cache_data [0:1023];

The original build system uses obsolete Xilinx tools and scripts incompatible with modern Vivado versions.

Timing Closure

Critical paths in the original design exceed timing constraints on modern FPGAs:

• Cache access paths
• Out-of-order execution logic
• Vector unit operations

Software Stack

Limited software support requires development of:

• Modern GCC toolchain
• Linux kernel patches
• Bootloader implementation
• Debug infrastructure

A2O Processor Revival - Task Breakdown

💬 Join the Community! Discuss A2O revival on Matrix: #powercommons:matrix.org

This document outlines the specific tasks for reviving the OpenPower A2O processor core based on the NLnet funding proposal. The project is structured across three phases over 6 months.

Project Overview

Timeline: 6 months Budget: €50,000 Primary Goal: Restore full functionality to the A2O processor core for modern FPGA platforms

Phase 1: Infrastructure Setup (Months 1-2)

Status: 4 open, 0 closed (0/4 complete)

Phase 2: Core Implementation & Software (Months 3-4)

Status: 8 open, 0 closed (0/8 complete)

Phase 3: Integration & Documentation (Months 5-6)

Status: 8 open, 0 closed (0/8 complete)

Cross-Cutting Tasks

Status: 3 open, 0 closed (0/3 complete)

Milestones

Month 2: Build System Complete

• Modern, reproducible build infrastructure
• Vivado 2025.x compatibility
• Comprehensive development environment docs

Month 4: Working A2O on FPGA

• A2O booting on VCU-118
• Basic functional tests passing
• Cross-compiler toolchain operational
• Simple bootloader running

Month 6: Production Ready

• Comprehensive documentation complete
• Alternative FPGA board support
• Future roadmap planning (formal verification, performance benchmarking)
• Community infrastructure established

Success Criteria

• ✅ A2O successfully synthesizes with Vivado 2025.x
• ✅ Timing closure achieved at ≥100 MHz on VCU-118
• ✅ Basic instruction tests pass on hardware
• ✅ Bootloader runs and provides debug console
• ✅ Cross-compiler produces working binaries
• ✅ Documentation enables new contributors to build and deploy
• ✅ Roadmaps for future development (Linux boot, formal verification, performance optimization)

Note on ISA 3.1 Compliance

The full ISA 3.1 compliance upgrade is tracked separately in the A2O Upgrade project, which details 9 workstreams covering instruction set updates, hypervisor support, interrupt architecture, MMU modernization, and VMX/VSX implementation.

Resources

• Repository: https://codeberg.org/PowerCommons/a2o
• Chat: #powercommons:matrix.org
• Website: https://powercommons.org/projects/a2o
• Funding: NLnet A2O Proposal

This task breakdown is based on the PowerCommons A2O OpenPower A2O Processor Revival Initiative funded by NLnet Foundation.

Technical Specifications

Coming Soon!

Development Roadmap

Coming soon!

Build Instructions

Coming soon!

A2O ISA Compliance - Workstream Summary

💬 Join the Community! We’re building the A2O upgrade together! Join us on Matrix: #powercommons:matrix.org to discuss implementation details, ask questions, share ideas, or collaborate on workstreams. New to Matrix? It’s a federated, open-source chat platform - get started here.

Instruction Count Summary

• Total New Instructions: 463+ (40 scalar + 400 VMX/VSX + 18 prefixed + 5 other)
• Total Removed Instructions: 38+ (15 user-mode + 7 interrupt + 15 MMU + 1 hypervisor)
• Net Instruction Growth: +425 instructions

Dependency Order & Execution Strategy

Phase 1 - Foundation (No Dependencies):
┌─────────────────────────────────────────────┐
│ WS1: Instructions   (12-16 weeks)           │
│ WS3: Interrupts     (10-12 weeks)           │
│ WS4: MMU/Radix      (20-24 weeks) ← CRITICAL│
│ WS6: PMU            (6-8 weeks)              │
└─────────────────────────────────────────────┘
         ↓                    ↓
Phase 2 - Dependent on Phase 1:
┌─────────────────────────────────────────────┐
│ WS2: Hypervisor     (16-20 weeks) ← WS3     │
│ WS7: VMX/VSX        (24-32 weeks) ← WS1     │
│ WS8: Prefixed       (10-12 weeks) ← WS1     │
└─────────────────────────────────────────────┘
         ↓
Phase 3 - Dependent on Phase 2:
┌─────────────────────────────────────────────┐
│ WS5: Debug          (8-10 weeks)  ← WS2     │
└─────────────────────────────────────────────┘
         ↓
Phase 4 - Integration:
┌─────────────────────────────────────────────┐
│ WS9: Integration    (16-20 weeks) ← ALL     │
│      ★ COMPLIANCE SUITE EXECUTION           │
└─────────────────────────────────────────────┘

Start in Parallel:

• WS1, WS3, WS4, WS6 (week 1)
• WS4 (MMU) is on critical path - must complete first

Start When Dependencies Met:

• WS2 starts when WS3 complete (week 12)
• WS7, WS8 start when WS1 complete (week 16)
• WS5 starts when WS2 complete (week 28)
• WS9 starts when WS4, WS2 substantially complete (week 36)

Where Compliance Suite Runs

Primary Execution: WS9 - Integration & Verification (Weeks 36-56)

Timeline:
├─ Week 36-40: Initial compliance suite execution
│  ├─ Book I tests (user mode)
│  ├─ Book II tests (virtual mode)  
│  └─ Book III tests (privileged mode)
│
├─ Week 41-48: Debug compliance failures
│  ├─ Fix identified issues
│  ├─ Re-run failed tests
│  └─ Iterate until passing
│
├─ Week 49-52: Final compliance verification
│  ├─ Full suite re-run
│  ├─ Linux Test Project
│  └─ glibc test suite
│
└─ Week 53-56: Certification
   ├─ Generate compliance report
   ├─ Document any deviations
   └─ Submit for certification

Test Suites Used

1. OpenPOWER Foundation ISA Compliance Tests

   • Source: https://github.com/OpenPOWER-Foundation
   • Coverage: All three ISA books
   • Format: Automated test vectors

2. Linux Test Project (LTP)

   • Validates OS-level ISA compliance
   • Tests system calls, threading, signals
   • Execution: On booted Linux

3. glibc Test Suite

   • Critical for LCS compliance
   • Tests VMX/VSX usage in standard library
   • Execution: During Linux userspace bring-up

4. KVM Selftests

   • Validates hypervisor functionality
   • Tests guest isolation, nested paging
   • Execution: Under KVM on Linux

Testing Infrastructure

Test Execution Strategy

Phase 1 (Weeks 36-40): Discovery
└─ Run full compliance suite
└─ Identify all failures
└─ Categorize by workstream
└─ Assign to responsible teams

Phase 2 (Weeks 41-48): Resolution  
└─ Fix bugs in parallel
└─ Re-test incrementally
└─ Track pass rate improvement
└─ Target 95%+ pass rate

Phase 3 (Weeks 49-52): Certification
└─ Achieve 100% pass rate
└─ Document exceptions (if any)
└─ Performance validation
└─ Generate compliance report

Phase 4 (Weeks 53-56): Validation
└─ Boot Linux distributions
└─ Run application workloads
└─ KVM multi-guest testing
└─ Final sign-off

Workstream Dependencies & Critical Path

Critical Path (56 weeks total):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

WS4: Storage Management (Radix MMU)
[████████████████████████] (20-24 weeks)
                         ↓
           WS2: Hypervisor & Virtualization
           [████████████████] (16-20 weeks)
                         ↓
              WS9: Integration & Verification
              [████████████] (16-20 weeks)

Parallel Workstreams (Off Critical Path)

Week: 0    10   20   30   40   50   56
      |    |    |    |    |    |    |
WS1:  [████████████]
WS3:  [██████████]
WS6:  [██████]
WS5:      [████████]
WS8:         [██████████]
WS7:  [████████████████████████████]

Key Outcomes by Workstream

WS1: Instruction Set Updates

✓ 40+ new arithmetic, logic, and bit manipulation instructions
✓ Quadword atomic operations (lq/stq/lqarx/stqcx)
✓ Set and compare instructions (setb, cmpeqb, cmprb)
✓ Modern CPU instructions (darn for random numbers)
✓ Clean removal of deprecated Book III-E instructions

WS2: Hypervisor & Virtualization

✓ LPAR support with LPCR, HRMOR, PCR
✓ Per-thread partitioning (critical for KVM)
✓ MSR[HV] replaces MSR[GS] with proper privilege model
✓ Hypervisor-specific SPRs (HSRR0/1, HSPRG0/1, HDAR, HDSISR)
✓ Enables unmodified KVM with multi-threaded guests

WS3: Interrupt Architecture

✓ Single HSRR0/1 save/restore (removes GSRR, CSRR, MCSRR)
✓ rfid and hrfid for proper privilege transitions
✓ LPCR[AIL]/[HAIL] for flexible interrupt addressing
✓ System Call Vectored (scv/rfscv) for modern syscalls
✓ Book III-S compliant interrupt vectors

WS4: Storage Management (CRITICAL PATH)

✓ Full radix tree page table walker
✓ Two-level (radix-on-radix) translation for LPAR
✓ Page walk cache for performance (<100 cycle TLB miss)
✓ PTCR, partition table, process table support
✓ Clean removal of Book III-E TLB management
✓ Enables modern Linux memory management

WS5: Debug Facilities

✓ DAWR0/1 and DAWRX0/1 for data watchpoints
✓ CIABR for instruction breakpoints
✓ Trace interrupt support
✓ ISA-compliant debug architecture

WS6: Performance Monitor Unit

✓ Architected PMU with MMCR0/1/2/A
✓ PMC1-6 performance counters
✓ SIER for sampled instruction events
✓ Standard event codes for portability

WS7: VMX/VSX Implementation (FOR LCS)

✓ 400+ vector and scalar instructions
✓ 32 x 128-bit vector registers (VR0-31)
✓ 64 x 128-bit VSX registers (VSR0-63)
✓ Enables glibc and standard Linux distributions
✓ Required for Fedora, Ubuntu, RHEL

WS8: Prefixed Instructions (v3.1)

✓ 64-bit instruction support
✓ 18 prefixed load/store instructions
✓ paddi for large immediates
✓ Enhanced addressing modes

WS9: Integration & Verification

✓ Full ISA compliance test suite execution
✓ OpenPOWER certification
✓ Unmodified Linux distribution boot
✓ KVM functionality validation
✓ Performance benchmarking
✓ Final release preparation

Decision Points

Decision #1: ISA Version

• v3.0C: Skip WS8, simpler (54 weeks total)
• v3.1C: Include WS8, current spec (56 weeks total)
• Recommendation: v3.1C (stay current)

Decision #2: Compliance Level

• SFFS: Skip WS7, custom Linux only (32 weeks saved)
• LCS: Include WS7, run standard distros (56 weeks total)
• Recommendation: LCS (enables wider adoption)

Decision #3: VMX/VSX Strategy

• Build: 24-32 weeks, full control
• License: 8-12 weeks, $$$ cost
• Open Source: 12-16 weeks, integration effort
• Recommendation: Evaluate open source cores first

Testing Locations Summary

Resource Requirements

Engineering Team

• Core RTL Engineers: 6-8
• Verification Engineers: 4-5
• Integration Engineers: 2-3
• Total: 12-16 engineers

Infrastructure

• High-performance simulation servers
• FPGA prototyping boards (optional but recommended)
• Compliance test licenses
• Linux distribution access

Timeline

• Aggressive: 18 months (high risk)
• Nominal: 20-22 months (recommended)
• Conservative: 24 months (low risk)

For detailed task breakdowns, see individual workstream documents.

Get Involved: 💬 Matrix Chat | 📧 Contact | 💻 Code | 📖 Full Docs

Technical Specifications

💬 Technical Questions? Join #powercommons:matrix.org to discuss ISA specifications, architectural decisions, and implementation details.

A2O Architecture: From Embedded to Server-Class ISA Compliance

Heritage and Current Architecture

The A2O processor core represents a significant piece of open-source Power architecture heritage, originally developed by IBM for the Blue Gene/Q supercomputer program. The A2 family comprises two variants:

• A2I (In-order): A 4-way simultaneously multithreaded (SMT4) in-order execution core
• A2O (Out-of-order): A 2-way simultaneously multithreaded (SMT2) out-of-order execution core with advanced speculation and dynamic scheduling

Both cores were designed to the Power ISA v2.06 Embedded specification, optimized for high-efficiency parallel computing environments where power consumption, thread density, and deterministic behavior were paramount. The A2 cores successfully powered some of the world’s most energy-efficient supercomputers, demonstrating exceptional performance-per-watt characteristics.

Embedded Architecture Foundation

As Book III-E (Embedded) implementations, the A2 cores feature:

• Software-loaded TLB with hardware support for radix tree lookups via “indirect” entries
• Embedded Hypervisor model using MSR[GS] (Guest State) for virtualization
• Multiple SRR pairs (SRR0/1, CSRR0/1, DSRR0/1, MCSRR0/1) for nested interrupt handling
• Implementation-specific debug facilities (DAC, DBCR, IAC registers)
• Implementation-specific performance monitoring (custom PMU counters and controls)
• No VMX/VSX support (Vector/SIMD extensions)

This embedded-focused design made the A2 ideal for embedded, real-time, and specialized HPC workloads but created barriers for running modern general-purpose software stacks.

The Compliance Gap: v2.06 to v3.1C

The journey from Power ISA v2.06 Embedded to v3.0C/v3.1C compliance represents a fundamental architectural transformation, not merely an incremental update. This upgrade bridges the gap between embedded and server-class implementations, enabling compatibility with mainstream Linux distributions and modern virtualization frameworks.

Two Compliance Targets

SFFS (Scalar Fixed-point and Floating-point Subset)

• Core instruction set compliance without vector extensions
• Sufficient for custom software stacks and embedded Linux
• Smaller implementation footprint
• Approximately 40+ new scalar instructions

LCS (Linux Compliancy Subset)

• Full compliance including VMX/VSX vector extensions
• Required for modern glibc (depends on VMX for optimized string operations)
• Enables compatibility with Fedora, Ubuntu, RHEL, and other mainstream distributions
• Adds 400+ vector/scalar instructions on top of SFFS requirements
• Essential for running unmodified Linux distribution binaries

Book I: User-Mode Instruction Set Evolution

The Book I (user-mode) changes represent the most visible transformation, adding powerful new capabilities:

New Instruction Categories

Atomic Operations: Quadword load/store atomic (lqarx/stqcx.) enable lock-free algorithms on 128-bit data structures, critical for modern concurrent programming.

Bit Manipulation: New bit permutation and manipulation instructions (cnttzw, cnttzd, extswsli) improve performance for cryptographic operations, compression algorithms, and bit field processing.

Prefixed Instructions (v3.1): 64-bit instruction encoding enables PC-relative addressing with ±8 EiB range and immediate operands up to 34 bits, dramatically improving code density and position-independent code generation.

Message Synchronization: Architected message-passing primitives improve inter-thread communication efficiency.

VMX/VSX Vector Extensions

For LCS compliance, implementing the complete VMX (Vector Multimedia Extension) and VSX (Vector-Scalar Extension) instruction sets represents the largest single implementation effort:

• 128-bit SIMD operations: 32 vector registers (VR0-VR31) for parallel data processing
• 64-bit scalar floating-point: 64 VSX registers overlaying FPRs and VRs
• Fused multiply-add operations: High-throughput floating-point computation
• Permute and shuffle: Flexible data reorganization within vectors
• Load/store vectors: Efficient memory access for parallel data

Modern glibc depends on VMX for optimized implementations of memcpy, memset, strcmp, and other fundamental library functions, making VMX/VSX essential for running unmodified Linux distributions.

See: WS1 - Instruction Set Updates | WS7 - VMX/VSX Implementation | WS8 - Prefixed Instructions

Book III: Privileged Architecture Transformation

The Book III changes represent a complete rearchitecture from embedded (Book III-E) to server (Book III-S) privileged facilities. This transformation touches every aspect of privileged operation.

Hypervisor Model: From Embedded to Server

Current (Embedded Hypervisor):

• MSR[GS] bit distinguishes guest from hypervisor
• Flat privilege model with limited partitioning
• Suitable for single-guest environments

Target (Server Hypervisor):

• MSR[HV] bit defines hypervisor mode
• LPCR (Logical Partitioning Control Register) for per-partition configuration
• HRMOR (Hypervisor Real Mode Offset Register) for hypervisor address space isolation
• PCR (Processor Compatibility Register) for ISA compatibility modes
• Per-thread partition IDs enabling true KVM support
• Two-level memory translation (guest virtual → guest real → host real)

This transformation enables the A2O to run modern KVM-based virtualization stacks, supporting multiple isolated virtual machines with hardware-assisted memory protection.

See: WS2 - Hypervisor & Virtualization

Interrupt Architecture Consolidation

Current: Multiple save/restore register pairs (SRR0/1, CSRR0/1, DSRR0/1, MCSRR0/1) for nested interrupt contexts, typical of embedded designs.

Target: Consolidated HSRR0/1 (Hypervisor SRR) with streamlined interrupt handling:

• System Call Vectored (scv) instruction for low-latency system calls
• Return from scv (rfscv) with reduced context switching overhead
• Simplified interrupt priority and masking

This consolidation reduces hardware complexity while improving interrupt latency for hypervisor and operating system transitions.

See: WS3 - Interrupt Architecture

MMU: From Software TLB to Hardware Radix Translation

The MMU transformation represents one of the most significant architectural changes:

Current State:

• Software-loaded TLB (operating system manages TLB entries explicitly)
• Radix tree support via “indirect” TLB entries (hardware walks radix trees for indirect entries)
• Hybrid approach with software control

Target State:

• Full hardware radix tree page table walker
• Page-walk cache for translation caching (reduces memory accesses for address translation)
• Two-level translation for LPAR (Logical Partitioning):
  • Level 1: Guest virtual → Guest real (managed by guest OS)
  • Level 2: Guest real → Host real (managed by hypervisor)
• Guest-real addressing mode for hypervisor efficiency
• Nested page table support for KVM

This MMU upgrade enables:

• Modern Linux memory management compatibility
• Efficient large page support (64KB, 2MB, 1GB pages)
• Hardware-accelerated address translation
• Industry-standard LPAR implementation for cloud and virtualization workloads

See: WS4 - Storage Management (MMU)

Debug Facilities Modernization

Replace: Implementation-specific registers (DAC, DBCR, IAC)

With: Architected debug facilities:

• DAWR/DAWRX (Data Address Watchpoint Register) for data breakpoints
• CIABR (Completed Instruction Address Breakpoint Register) for instruction breakpoints
• Standardized debug event handling

See: WS5 - Debug Facilities

Performance Monitor Unit (PMU) Standardization

Replace: Custom implementation-specific PMU counters

With: Architected PMU:

• MMCR0-2 (Monitor Mode Control Registers) for event selection and configuration
• PMC1-6 (Performance Monitor Counters) for standardized event counting
• SIER (Sampled Instruction Event Register) for precise event attribution
• Compatibility with standard Linux perf tools and profilers

See: WS6 - Performance Monitor Unit

Implementation Strategy and Priorities

Phase 1: SFFS Compliance Foundation

1. Book I scalar instructions (40+ new instructions)
2. Basic Book III-S structure (MSR[HV], LPCR, HSRR0/1)
3. Simplified interrupt architecture
4. Debug and PMU standardization
5. Custom Linux kernel support

Phase 2: MMU and Hypervisor

1. Hardware radix page table walker
2. Page-walk cache implementation
3. Two-level translation for LPAR
4. Full KVM support with per-thread partitioning
5. Guest-real addressing mode

Phase 3: LCS Full Compliance

1. VMX instruction set (128-bit SIMD)
2. VSX instruction set (64-bit scalar + vector extensions)
3. Vector register file (32 × 128-bit VRs)
4. Mainstream Linux distribution compatibility (Fedora, Ubuntu, RHEL)

Phase 4: v3.1 Advanced Features

1. Prefixed instruction support (64-bit encoding)
2. PC-relative addressing infrastructure
3. Extended immediate operands (34-bit)

See: Workstream Summary for detailed timeline and dependencies

Instruction Set Summary

Total Changes

• New Instructions: 463+ (40 scalar + 400 VMX/VSX + 18 prefixed + 5 other)
• Removed Instructions: 38+ (15 user-mode + 7 interrupt + 15 MMU + 1 hypervisor)
• Net Growth: +425 instructions

By Workstream

The Value Proposition

This comprehensive upgrade transforms the A2O from a specialized embedded processor into a server-class, general-purpose Power architecture core capable of:

• Running unmodified Linux distributions (Ubuntu, Fedora, RHEL, Debian)
• Hosting KVM virtual machines with hardware-assisted isolation
• Supporting modern development toolchains (glibc, GCC, LLVM)
• Enabling cloud and datacenter workloads with industry-standard LPAR
• Maintaining open-source heritage while achieving commercial viability

The A2O upgrade represents a unique opportunity in the open-source hardware ecosystem: transforming a proven, high-efficiency supercomputer core into a fully capable, ISA-compliant processor suitable for general-purpose computing. By bridging the embedded-to-server gap, PowerCommons enables the A2O to serve markets ranging from sovereign computing initiatives to academic research, embedded systems to cloud infrastructure—all while remaining fully open source.

This is not merely a compliance exercise; it is the revival of a world-class processor architecture for the next generation of open, auditable, and trustworthy computing systems.

Resource Requirements

Engineering Team

• Core RTL Engineers: 6-8
• Verification Engineers: 4-5
• Integration Engineers: 2-3
• Total: 12-16 engineers

Timeline

• Aggressive: 18 months (high risk)
• Nominal: 20-22 months (recommended)
• Conservative: 24 months (low risk)

Infrastructure

• High-performance simulation servers
• FPGA prototyping boards (VCU-118 recommended)
• Compliance test licenses
• Linux distribution access

Compliance and Verification

The A2O upgrade targets full compliance with Power ISA v3.0C or v3.1C specifications through comprehensive testing:

Test Strategy

1. Unit tests during development (WS1-WS8)
2. Integration tests for cross-workstream validation (WS9)
3. ISA compliance suite execution (WS9, weeks 36-52)
4. Linux Test Project for OS-level validation
5. glibc test suite for ABI compliance
6. KVM selftests for hypervisor validation

See: WS9 - Integration & Verification | Compliance Testing Strategy

Related Documentation

• Workstream Summary - Full task breakdown and dependencies
• A2O Revival Project - Restoring current A2O functionality
• Compliance Testing Strategy - Verification approach
• Individual workstream pages (WS1-WS9) - Detailed task lists

For implementation questions and collaboration opportunities, join us on Matrix: #powercommons:matrix.org

ISA Compliance & Testing Strategy

💬 Discuss Testing: Join #powercommons:matrix.org to discuss ISA compliance testing strategies, share test results, and collaborate on verification efforts.

When Compliance Testing Happens

Location: WS9 (Integration & Verification)
Timing: Weeks 36-56 of project
Duration: 20 weeks

Week 36-40: Initial test runs, identify failures
Week 41-48: Fix bugs, iterative re-testing  
Week 49-52: Final verification, achieve 100% pass
Week 53-56: Linux validation, certification

Test Suites

1. OpenPOWER ISA Compliance Tests

• Source: https://github.com/OpenPOWER-Foundation
• Coverage: Book I (user), Book II (virtual), Book III (privileged)
• Purpose: Official ISA certification

2. Linux Test Project (LTP)

• Purpose: OS-level ISA validation
• Tests: System calls, threading, signals

3. glibc Test Suite

• Purpose: Validate VMX/VSX usage in standard library
• Critical for: LCS compliance

4. KVM Selftests

• Purpose: Hypervisor functionality
• Tests: Guest isolation, nested paging

Testing Platforms

Test Execution Process

Phase 1: Discovery (Weeks 36-40)

1. Run full compliance suite on all platforms
2. Categorize failures by workstream
3. Assign to responsible teams

Phase 2: Resolution (Weeks 41-48)

1. Fix bugs in parallel
2. Re-test incrementally
3. Track pass rate improvement
4. Target: 95%+ pass rate

Phase 3: Certification (Weeks 49-52)

1. Achieve 100% pass rate
2. Document any exceptions
3. Performance validation
4. Generate compliance report

Phase 4: Validation (Weeks 53-56)

1. Boot Linux distributions (Fedora, Ubuntu)
2. Run application workloads
3. KVM multi-guest testing
4. Final sign-off

Success Criteria

• Pass 100% of ISA compliance tests (Book I/II/III)
• Boot unmodified Linux distributions
• KVM functional with multi-threaded guests
• Performance within 90% of baseline

Test Coverage by Workstream

Detailed Test Issues

See WS9 section in WS5-WS9_Additional_Workstreams.md for:

• Issue #371: ISA compliance test suite (30 days)
• Issue #372: Regression suite (20 days)
• Issue #373: Linux kernel bring-up (15 days)
• Issue #374: Distribution testing (20 days)
• Issue #375: KVM testing (15 days)

Work Stream - User Mode Instructions

Owner: TBD Duration: 12-16 weeks Priority: High

💬 Discuss WS1: Join #powercommons:matrix.org to discuss instruction implementation, bit manipulation strategies, and decoder modifications.

Objectives

Implement new user-mode instructions added since v2.06 and remove/relocate deprecated instructions.

Deliverables

1. RTL for 40+ new instructions
2. Decoder updates for new instruction encodings
3. Test cases for all new instructions
4. Removal/sandboxing of deprecated instructions

Roadmap

Phase 1: Analysis & Planning (Weeks 1-2)

• Review ISA specifications for all new instructions
• Identify decoder modifications needed
• Plan execution unit assignments

Phase 2: Basic Arithmetic/Logic (Weeks 3-5)

• Implement bit manipulation instructions
• Implement count/byte operations

Phase 3: Load/Store Extensions (Weeks 6-8)

• Implement quadword atomics
• Implement new synchronization

Phase 4: Floating Point (Weeks 9-11)

• Implement FP control instructions
• Implement FP merge operations

Phase 5: Cleanup & Verification (Weeks 12-16)

• Remove deprecated instructions
• Integration testing
• Performance validation

Dependencies

• Decoder infrastructure
• Execution unit availability
• Test framework

Risks

1. Timing closure for complex bit manipulation instructions
2. Integration conflicts with existing instructions
3. Test coverage gaps

Success Criteria

• All 40+ new instructions functional
• All deprecated instructions removed/sandboxed
• 100% instruction decode coverage
• Pass ISA compliance tests for Book I
• No timing degradation

Issues

Status: 45 open, 0 closed (0/45 complete)

Last updated: 2025-12-05 16:48:17

WS2: Hypervisor & Virtualization Facilities

Owner: TBD Duration: 16-20 weeks Priority: Critical

💬 Discuss WS2: Join #powercommons:matrix.org to discuss LPAR implementation, hypervisor state transitions, and KVM enablement strategies.

Objectives

Transform embedded hypervisor model (Book III-E) to ISA v3.0C/v3.1C hypervisor/LPAR model.

Deliverables

1. MSR[HV] bit implementation (replacing MSR[GS])
2. LPAR support with LPCR, HRMOR, PCR
3. Hypervisor-specific SPRs (HSRR0/1, HSPRG0/1, HDAR, HDSISR)
4. Per-thread partition support
5. Hypervisor Emulation Assist Interrupt (HEAI)

Roadmap

Phase 1: Architecture Study (Weeks 1-2)

• Analyze Book III-E vs Book III-S differences
• Design state transition model
• Plan SPR remapping

Phase 2: Core State Logic (Weeks 3-8)

• Implement MSR[HV] bit
• Remove MSR[GS] logic
• Rework privilege checking

Phase 3: SPR Implementation (Weeks 9-13)

• Implement new hypervisor SPRs
• Remove embedded hypervisor SPRs
• Update SPR access control

Phase 4: LPAR Support (Weeks 14-17)

• Implement LPCR/HRMOR/PCR
• Add per-thread partition support
• Implement HEAI

Phase 5: Integration (Weeks 18-20)

• System-level testing
• KVM validation
• Performance optimization

Dependencies

• WS3: Interrupt Architecture (interrupt routing changes)
• WS4: Storage Management (LPIDR integration with MMU)

Risks

1. Per-thread partition support adds significant complexity
2. KVM compatibility issues
3. Privilege state transition bugs
4. Performance degradation in partition switching

Success Criteria

• MSR[HV] operational, MSR[GS] removed
• All hypervisor SPRs implemented
• LPAR fully functional
• Per-thread partitioning working
• KVM boots and runs guests
• Pass ISA hypervisor compliance tests
• <10% overhead for partition switching

Issues

Status: 27 open, 0 closed (0/27 complete)

Last updated: 2025-12-05 16:48:17

WS3: Interrupt Architecture

Owner: TBD Duration: 10-12 weeks Priority: Critical

💬 Discuss WS3: Join #powercommons:matrix.org to discuss interrupt vector migration, HSRR0/1 implementation, and scv/rfscv strategies.

Objectives

Migrate from Book III-E interrupt model to ISA v3.0C/v3.1C interrupt architecture.

Deliverables

1. Replace multiple save/restore register sets with HSRR0/1
2. Implement rfid and hrfid instructions
3. Remove IVPR/GIVPR, implement LPCR[AIL]/[HAIL]
4. Implement scv/rfscv instructions
5. Update interrupt vectors per ISA

Roadmap

Phase 1: Analysis (Weeks 1-2)

• Map Book III-E to Book III-S interrupt differences
• Design new interrupt flow
• Plan SPR transitions

Phase 2: Save/Restore Logic (Weeks 3-6)

• Remove GSRR0/1, CSRR0/1, MCSRR0/1
• Remove rfgi, rfci, rfmci instructions
• Implement hrfid

Phase 3: Vector Control (Weeks 7-9)

• Remove IVPR/GIVPR
• Implement LPCR[AIL]/[HAIL]
• Update vector address calculation

Phase 4: New Instructions (Weeks 10-11)

• Implement scv/rfscv

Phase 5: Integration (Weeks 12)

• System testing
• Performance validation

Dependencies

• WS2: Hypervisor facilities (HSRR0/1, LPCR, MSR[HV])

Risks

1. Interrupt priority changes may affect real-time behavior
2. Vector address calculation complexity
3. Interaction with hypervisor interrupt routing

Success Criteria

• All Book III-E interrupt mechanisms removed
• ISA-compliant interrupt vectors
• scv/rfscv functional
• LPCR[AIL]/[HAIL] operational
• Pass ISA interrupt compliance tests
• Interrupt latency within 5% of baseline

Issues

Status: 27 open, 0 closed (0/27 complete)

Last updated: 2025-12-05 16:48:17

WS4: Storage Management (MMU/Radix Translation)

Owner: TBD Duration: 20-24 weeks Priority: Critical

💬 Discuss WS4: This is a critical workstream! Join #powercommons:matrix.org to discuss radix tree translation, page walker design, and two-level LPAR support.

Objectives

Replace Book III-E TLB-based MMU with ISA v3.0C/v3.1C radix tree translation, including two-level (radix-on-radix) support for LPAR.

Deliverables

1. Radix tree page table walker
2. Page walk cache implementation
3. Two-level translation for LPAR
4. PTCR, partition table, process table
5. New TLB management instructions
6. Removal of Book III-E MMU

Roadmap

Phase 1: Architecture & Design (Weeks 1-4)

• Study ISA radix translation
• Design page walker architecture
• Design page walk cache
• Plan TLB integration

Phase 2: Single-Level Radix (Weeks 5-12)

• Implement partition/process tables
• Implement radix page walker
• Implement page walk cache
• Basic TLB integration

Phase 3: Two-Level Translation (Weeks 13-18)

• Implement nested radix translation
• Update page walker for 2-level
• Update page walk cache

Phase 4: Cleanup & Optimization (Weeks 19-22)

• Remove Book III-E MMU
• Performance optimization
• TLB management updates

Phase 5: Integration (Weeks 23-24)

• Full system testing
• Performance validation

Dependencies

• WS2: Hypervisor facilities (LPIDR, LPCR)
• Memory subsystem for page walker
• TLB hardware

Risks

1. High Complexity: Radix walker with two-level translation is complex
2. Performance: Page walk latency could be high without good caching
3. Verification: Comprehensive testing required for correctness
4. Schedule: Most time-consuming workstream, likely on critical path

Success Criteria

• Radix page walker functional for all page sizes
• Two-level translation working for LPAR
• Page walk cache achieves >90% hit rate
• TLB management instructions compliant
• All Book III-E MMU removed
• Pass ISA MMU compliance tests
• Linux boots with radix translation
• TLB miss latency <100 cycles (with cache hits)

Issues

Status: 40 open, 0 closed (0/40 complete)

Last updated: 2025-12-05 16:48:17

WS5: Debug Facilities

Owner: TBD Duration: 8-10 weeks Priority: Medium

💬 Discuss WS5: Join #powercommons:matrix.org to discuss DAWR/CIABR implementation and debug facility migration strategies.

Objectives

Replace Book III-E debug facilities with ISA v3.1C debug architecture.

Tasks

Additional Privileged Changes

Workstream: Miscellaneous Privileged Updates

Owner: Distributed across other workstreams Duration: Integrated with other work

SPR Removals

Instruction Removals

SPR Additions

Success Criteria

• All deprecated SPRs/instructions removed
• All new SPRs/instructions implemented
• Pass ISA compliance tests

Issues

Status: 23 open, 0 closed (0/23 complete)

Last updated: 2025-12-05 16:48:17

WS6: Performance Monitor Unit

Owner: TBD Team Size: 1-2 engineers Duration: 6-8 weeks Priority: Medium

💬 Discuss WS6: Join #powercommons:matrix.org to discuss PMU architecture, event mappings, and Linux perf integration.

Objectives

Replace implementation-specific PMU with architected ISA v3.1C PMU.

Background

The A2 core currently implements A2-specific performance monitoring registers (AESR, CESR, IESR, MESR, XESR). To achieve ISA v3.1C compliance, we need to replace these with the architected Performance Monitor Unit (PMU) defined in Book III-S.

The architected PMU provides:

• Standardized interface: MMCR0/1/2/A control registers
• Six performance counters: PMC1-6 (SPR 771-776)
• Event sampling: SIER for sampled instruction data
• Portability: Standard event codes across POWER implementations
• Linux perf support: Required for perf command and performance analysis

Tasks

Remove A2-Specific PMU Registers

Implement Architected PMU Registers

Event Mapping

Testing and Validation

Implementation Notes

Counter Overflow Handling

When PMC[i] overflows (bit 0 transitions from 0 to 1):
1. Set MMCR0[PMAO] (alert occurred)
2. If MMCR0[PMAE]=1, trigger Performance Monitor Interrupt
3. Freeze counters if MMCR0[FCECE]=1
4. Sample instruction data into SIER if enabled

Performance Monitor Interrupt

• Vector: 0xF00 (Performance Monitor Exception)
• Saves PC in SRR0
• Must be enabled via MSR[EE] and MMCR0[PMAE]
• Critical for profiling tools

Linux Integration

The architected PMU enables:

• perf stat - hardware counter statistics
• perf record - sampling-based profiling
• perf top - real-time profiling
• perf annotate - instruction-level profiling

Register Summary

Dependencies

• None (can start immediately)
• Parallel with WS1, WS3, WS4

Success Criteria

• All A2-specific PMU registers removed
• All architected PMU registers implemented
• At least 10 architected events supported
• PMU interrupts working correctly
• Counters count accurately (verified against RTL simulation)
• Linux perf command works on A2 core
• Pass ISA compliance PMU tests

Performance Impact

• Minimal impact on core frequency
• Counters run in parallel with execution
• Event detection should not be on critical timing path
• Target: No frequency degradation

Documentation Requirements

• User Manual chapter on Performance Monitoring
• List all supported events with descriptions
• Example code for programming PMU
• Performance monitoring best practices

Open Questions

1. Event Selection: Which architected events are feasible to implement in A2?
2. Sampling Frequency: What is acceptable overhead for SIER sampling?
3. Backwards Compatibility: Do we provide emulation for old A2 PMU registers?

References

• Power ISA v3.1C Book III-S, Chapter 4: Performance Monitor
• OpenPOWER ELF v2 ABI: PMU Programming Interface
• Linux kernel: arch/powerpc/perf/ implementation
• IBM POWER PMU documentation

Issues

Status: 10 open, 0 closed (0/10 complete)

Last updated: 2025-12-05 16:48:17

WS7: VMX/VSX Implementation

Owner: TBD Duration: 24-32 weeks Priority: High (Critical for LCS Compliance)

💬 Discuss WS7: This is our most complex workstream! Join #powercommons:matrix.org to discuss VMX/VSX implementation strategies, share resources, or collaborate on this critical component.

Objectives

Implement VMX (AltiVec) and VSX (Vector-Scalar Extension) for Linux Compatible Subset (LCS) compliance.

Critical Importance

This is the largest and most resource-intensive workstream. Without VMX/VSX:

• ❌ Cannot run standard Linux distributions (Fedora, Ubuntu, RHEL)
• ❌ glibc requires VMX/VSX for optimized string and memory operations
• ❌ Many applications fail (compiled with -mcpu=power8 or later)
• ❌ Only achieves SFFS (Server Floating Point Subset), not LCS

With VMX/VSX:

• ✅ LCS Compliance - industry standard for Linux on POWER
• ✅ Run unmodified distros - Fedora, Ubuntu, RHEL work out-of-box
• ✅ Application compatibility - vast majority of ppc64le software works
• ✅ Performance - SIMD operations for HPC, multimedia, crypto

Background

VMX (Vector Multimedia Extension)

Also known as AltiVec, VMX provides:

• 32 x 128-bit vector registers (VR0-VR31)
• SIMD operations on integer and floating-point data
• Data types: byte, halfword, word, single-precision float
• ~200 instructions for parallel processing
• Introduced in POWER6, based on original AltiVec

VSX (Vector-Scalar Extension)

VSX extends VMX with:

• 64 x 128-bit registers (VSR0-VSR63)
  • VSR0-VSR31 overlay FPR0-FPR31 (scalar FP registers)
  • VSR32-VSR63 overlay VR0-VR31 (VMX vector registers)
• Double-precision floating-point SIMD
• Scalar and vector operations in unified register file
• ~200 additional instructions
• Introduced in POWER7

Register File Organization

VSX View (64 x 128-bit registers):
┌─────────────────────────────────────────┐
│ VSR0-31  (overlay FPR0-31 in low 64b)  │ ← Scalar FP + VSX
│ VSR32-63 (overlay VR0-31)              │ ← VMX vectors
└─────────────────────────────────────────┘

Legacy View:
FPR0-31:  64-bit scalar floating-point (existing A2 registers)
VR0-31:   128-bit VMX vector registers (NEW)

Tasks

Phase 0: Planning and Architecture (Weeks 1-2)

Phase 1: Register File and Basic Infrastructure (Weeks 3-6)

Phase 2: VMX Integer Instructions (Weeks 7-12)

VMX Integer Arithmetic

VMX Integer Logic and Shift

VMX Integer Compare and Permute

Phase 3: VMX Floating-Point Instructions (Weeks 13-16)

Issues #262-283: VMX Single-Precision FP (22 instructions)

• Priority: High
• Duration: 15 days total
• Categories: Arithmetic, Compare, Convert, Rounding, Estimate

Key Instructions:

• Vector FP add/subtract: vaddfp, vsubfp
• Vector FP multiply-add: vmaddfp
• Vector FP compare: vcmpeqfp, vcmpgtfp, vcmpgefp, vcmpbfp
• Vector FP convert: vcfsx, vcfux, vctsx, vctux
• Vector FP rounding: vrfin, vrfiz, vrfip, vrfim
• Vector FP estimate: vrefp, vrsqrtefp, vlogefp, vexptefp
• Vector FP min/max: vmaxfp, vminfp

Implementation Notes:

• Reuse existing FPU if possible
• May need 4-way SIMD FPU (expensive)
• Consider multi-cycle execution
• Ensure IEEE 754 compliance
• Labels: phase:3-vmx-fp, category:fp-ops, precision:single

Phase 4: VMX Load/Store Instructions (Weeks 17-18)

Issues #284-315: VMX Memory Operations (32 instructions)

• Priority: High
• Duration: 10 days total
• Categories: Load, Store, Pack, Unpack

Key Instructions:

• Vector load: lvx, lvxl (aligned)
• Vector store: stvx, stvxl (aligned)
• Vector load element: lvebx, lvehx, lvewx
• Vector store element: stvebx, stvehx, stvewx
• Vector load splat: lvsplatb, lvsplath, lvsplatw
• Vector alignment: lvsl, lvsr (load vector for shift left/right)
• Pack/unpack: vpkuhum, vpkuwum, vpkuhus, vpkuwus, vpkshss, vpkswss, vpkshus, vpkswus, vpkpx, vupkhsb, vupkhsh, vupklsb, vupklsh, vupkhpx, vupklpx

Implementation Notes:

• Most VMX loads/stores require 16-byte alignment
• Unaligned access requires multiple operations + permute
• Trap on misalignment or emulate in software
• Pack/unpack operations convert between widths with saturation
• Labels: phase:4-vmx-load-store, category:memory, category:pack-unpack

Phase 5: VSX Scalar Instructions (Weeks 19-22)

Issues #316-367: VSX Scalar Double-Precision (52 instructions)

• Priority: High
• Duration: 20 days total
• Categories: Arithmetic, Compare, Convert, Estimate, Special

Key Instructions:

• Scalar FP add/subtract: xsadddp, xssubdp
• Scalar FP multiply/divide: xsmuldp, xsdivdp
• Scalar FP multiply-add: xsmaddadp, xsmaddmdp, xsmsubadp, xsmsubmdp, xsnmaddadp, xsnmaddmdp, xsnmsubadp, xsnmsubmdp
• Scalar FP compare: xscmpudp, xscmpodp, xscmpeqdp, xscmpgtdp, xscmpgedp
• Scalar FP convert: xscvdpsp, xscvspdp, xscvdpsxds, xscvdpsxws, xscvdpuxds, xscvdpuxws, xscvsxddp, xscvuxddp, xscvsxdsp, xscvuxdsp
• Scalar FP sqrt: xssqrtdp
• Scalar FP reciprocal estimate: xsredp, xsrsqrtedp
• Scalar FP abs/negate/copy sign: xsabsdp, xsnabsdp, xsnegdp, xscpsgndp
• Scalar FP max/min: xsmaxdp, xsmindp
• Scalar FP round/truncate: xsrdpic, xsrdpim, xsrdpip, xsrdpiz, xsrdpi

Implementation Notes:

• VSX scalar ops use VSR0-63 (overlap with FPR0-31)
• Higher precision than VMX single-precision
• IEEE 754 compliance required
• Labels: phase:5-vsx-scalar, category:fp-ops, precision:double

Phase 6: VSX Vector Instructions (Weeks 23-26)

Issues #368-456: VSX Vector Instructions (89 instructions)

• Priority: High
• Duration: 48 days total
• Categories: FP Arithmetic, FP Compare, FP Convert, Logical, Permute, Load/Store

VSX Vector FP Arithmetic (Double/Single Precision):

• Vector FP add/subtract: xvadddp, xvaddsp, xvsubdp, xvsubsp
• Vector FP multiply/divide: xvmuldp, xvmulsp, xvdivdp, xvdivsp
• Vector FP multiply-add: xvmaddadp, xvmaddmdp, xvmsubadp, xvmsubmdp, xvnmaddadp, xvnmaddmdp, xvnmsubadp, xvnmsubmdp (both DP and SP variants)
• Vector FP sqrt: xvsqrtdp, xvsqrtsp
• Vector FP reciprocal estimate: xvredp, xvresp, xvrsqrtedp, xvrsqrtesp
• Vector FP max/min: xvmaxdp, xvmaxsp, xvmindp, xvminsp

VSX Vector FP Compare & Convert:

• Vector FP compare: xvcmpeqdp, xvcmpeqsp, xvcmpgtdp, xvcmpgtsp, xvcmpgedp, xvcmpgesp
• Vector FP convert: xvcvdpsp, xvcvspdp, xvcvdpsxds, xvcvdpsxws, xvcvdpuxds, xvcvdpuxws, xvcvspsxds, xvcvspsxws, xvcvspuxds, xvcvspuxws, xvcvsxddp, xvcvsxdsp, xvcvsxwdp, xvcvsxwsp, xvcvuxddp, xvcvuxdsp, xvcvuxwdp, xvcvuxwsp
• Vector FP round/truncate: xvrdpic, xvrdpim, xvrdpip, xvrdpiz, xvrdpi, xvrspic, xvrspim, xvrspip, xvrspiz, xvrspi
• Vector FP abs/negate/copy sign: xvabsdp, xvabssp, xvnabsdp, xvnabssp, xvnegdp, xvnegsp, xvcpsgndp, xvcpsgnsp

VSX Permute & Logical Operations:

• Permute: xxpermdi, xxsldwi
• Select: xxsel
• Merge: xxmrghw, xxmrglw
• Splat: xxspltw
• Logical: xxland, xxlandc, xxlor, xxlorc, xxlxor, xxlnor, xxleqv, xxlnand

VSX Load/Store Operations:

• Load/store doubleword: lxsdx, stxsdx
• Load/store word: lxsiwax, lxsiwzx, stxsiwx
• Load/store vector: lxvd2x, lxvw4x, stxvd2x, stxvw4x, lxvdsx

Implementation Notes:

• VSX vector operations process 2x double-precision or 4x single-precision values in parallel
• Uses VSR0-63 (full 128-bit registers)
• Requires careful SIMD execution unit design
• Labels: phase:6-vsx-vector, category:fp-ops, category:logical, category:permute, category:memory

Phase 7: Exception and Context Management (Weeks 27-28)

Issues #457-460: Exception and Context Management (4 issues)

• Priority: Critical
• Duration: 32 days total
• Categories: Exception handling, Context switching, Register coherency

Phase 8: Testing and Verification (Weeks 29-32)

Issues #461-464: Testing and Verification (4 issues)

• Priority: Critical
• Duration: 60 days total
• Categories: Unit testing, Integration testing, Performance testing

Instruction Count Summary

Note: Actual count varies by ISA version, some instructions optional.

Integration with A2 Core

Pipeline Integration

┌─────────┐   ┌────────┐   ┌─────────┐   ┌────────┐   ┌──────────┐
│ I-Fetch │ → │ Decode │ → │ Issue   │ → │ VMX/   │ → │ Write-   │
│         │   │        │   │         │   │ VSX    │   │ back     │
│         │   │        │   │         │   │ EXU    │   │          │
└─────────┘   └────────┘   └─────────┘   └────────┘   └──────────┘
                                              ↓
                                         VR0-31, VSR0-63
                                         Register File

Key Integration Points

1. Instruction Decode: Recognize VMX/VSX opcodes
2. Issue Logic: Schedule to VMX/VSX execution unit
3. Register Renaming: Extend to vector registers (if applicable)
4. Execution: New 128-bit datapath
5. Writeback: Write 128-bit results to register file
6. Load/Store Unit: Handle 16-byte vector operations
7. Exception Logic: VMX/VSX unavailable exceptions

Potential Issues

• Frequency Impact: 128-bit datapath may slow critical path
• Area: Large register file (64 x 128-bit = 8KB)
• Power: Vector operations consume more power
• Verification: 400+ new instructions to verify

Dependencies

• WS1: Some VMX/VSX instructions depend on base ISA updates
• Parallel with WS2, WS3, WS4
• Must complete before WS9 (integration)

Success Criteria

• All mandatory LCS VMX/VSX instructions implemented
• Register file (64 x 128-bit) functional
• Exception handling (unavailable exception) works
• Context switching validated
• Pass ISA compliance VMX/VSX tests
• glibc test suite passes (critical for LCS)
• Linux boots with VMX/VSX enabled
• Standard Linux distributions (Fedora, Ubuntu) boot

Critical Risks

Risk 1: Schedule Overrun

Probability: High Impact: Critical Mitigation:

• Evaluate open source options early
• Consider phased approach (VMX first)
• Allocate contingency time

Risk 2: Frequency Degradation

Probability: Medium Impact: High Mitigation:

• Multi-cycle execution for complex operations
• Pipeline vector operations
• Careful physical design

Risk 3: Verification Complexity

Probability: High Impact: High Mitigation:

• Start verification early
• Reuse ISA compliance tests
• Automated test generation

Deliverables

1. ✅ VMX/VSX architecture specification
2. ✅ RTL implementation (all instructions)
3. ✅ 64 x 128-bit register file
4. ✅ Exception handling
5. ✅ Test suite (unit and integration tests)
6. ✅ Verification report (compliance test results)
7. ✅ Integration guide
8. ✅ Performance benchmarks

Timeline Visualization

Week   Phase                          Key Deliverable
----   -----                          ---------------
1-2    Planning                       ✓ Architecture spec
3-6    Register file                  ✓ VR0-31, VSR0-63
7-12   VMX integer                    ✓ ~75 instructions
13-16  VMX floating-point            ✓ ~50 instructions
17-18  VMX load/store                ✓ ~25 instructions
19-22  VSX scalar                     ✓ ~50 instructions
23-26  VSX vector                     ✓ ~100 instructions
27-28  Exception handling             ✓ Context switching
29-32  Testing & integration          ✓ LCS compliance

Risk Windows:
Week 3-6:   High (register file area and timing)
Week 13-16: High (floating-point implementation complexity)
Week 29-32: Medium (verification and debugging)

References

• Power ISA v3.1C Book I, Chapters 6 & 7
• AltiVec Programming Interface Manual
• VSX Programming Guide
• glibc source: sysdeps/powerpc/powerpc64/
• Linux kernel: arch/powerpc/kernel/vector.S
• OpenPOWER Foundation: VMX/VSX compliance tests

Status: Planning Next Step: Requirements analysis and open source evaluation (Issue #170)

Issues

Status: 295 open, 0 closed (0/295 complete)