PowerCommons SoC - Complete Open Verifiable System-on-Chip

Executive Summary

PowerCommons SoC represents a groundbreaking initiative to create the world’s first fully open, verifiable system-on-chip using OpenPower architecture. Building upon successful Microwatt and A2O processor implementations, this project delivers a complete computing platform with zero proprietary dependencies - from processor cores to firmware to board management controllers.

Project Duration: 12 months
Requested Funding: €50,000
Chief Technical Advisor: Prof. Peter Hofstee (IBM/Delft University of Technology)
Supporting Organization: OpenPower Foundation

Project Abstract

A complete, open, and verifiable SoC built using OpenPower Microwatt and A2O cores.

In the Power9 generation, IBM released a system reference design that included open firmware, which remains available today. However, that reference design relied on a board management controller (BMC) that was not open. While the OpenPOWER processor ISA is open and license-free, the Power9 implementation is not open-source and proprietary.

In this project, we aim to make progress towards a fully open, license-free, and verifiable SoC and system infrastructure. The LibreSOC project’s challenges stemmed from attempting novel processor architectures without sufficient hardware verification resources. In contrast, our project takes a more incremental approach, maximizing the leverage of existing fully open Power architecture cores, such as “Microwatt” and the “A2” family of cores, specifically the A2O out-of-order processor core, as well as open-source firmware infrastructure.

Our initial objective is to create a demonstrator of a fully open system architecture, including a fully open system software stack. This will provide a boost to multiple open hardware projects including the The PowerPC notebook project that pursued an open-system design, but eventually resorted to a commercial processor that is not open-source.

Project Overview and Expected Outcomes

PowerCommons SoC aims to create the world’s first fully open, verifiable system-on-chip using OpenPower architecture. Building on successful Microwatt and A2O implementations, we’ll deliver a complete computing platform with zero proprietary dependencies - from processor cores to firmware to board management. This proposal builds upon a companion proposal to bring OpenPower A2O processor to life under the PowerCommons umbrella. It reuses the A2O core brought back to life and couples it with Microwatt in an open, secure SoC.

Key Deliverables

Impact

This creates a trustworthy computing foundation for critical infrastructure, research institutions, and security-conscious organizations. Unlike existing “open” systems that hide proprietary components in firmware or management controllers, PowerCommons provides complete transparency and auditability.

Timeline

Success enables truly sovereign computing infrastructure free from hidden dependencies or backdoors.

2. Relevant Experience and Contributions

My involvement with OpenPower Foundation since May 2025 has provided hands-on expertise in OpenPower processor implementation, particularly through to the Microwatt project and broader ecosystem support.

Specific Technical Achievements

VCU118 Platform Enablement: I successfully added VCU118 FPGA board support to Microwatt SoC, enabling the processor to boot on this high-performance Xilinx platform. This required adapting the SoC infrastructure to the VCU118’s specific resources and constraints, including clock generation, I/O pin mappings, and resource utilization optimization.

DRAM Integration and Linux Boot: I further improved Microwatt Soc integration by adding support for VCU-118 DRAM controller transforming it from a demonstration core to a practical, Linux-capable system. This involved integrating DDR4 memory controllers, solving complex timing calibration issues. The successful Linux boot on VCU118 validated the complete hardware-software stack.

LiteX Framework Integration: While LiteX had limited Microwatt support, Linux boot was impossible as LiteX BIOS and bootstrapper only supported RISC-V. I enabled full Linux boot capability by::

• Adding PowerPC architecture support to the build system and BIOS
• Integrating new memory controller with proper timing calibration
• Resolving boot stack incompatibilities between LiteX and PowerPC
• Fixing interrupt controller memory region issues between Litex BIOS, Linux and Microwatt

These contributions established critical integration patterns that PowerCommons will extend for multi-core SoC development.

Community Infrastructure Support

I’ve assisted OpenPower community members in accessing multiple FPGA boards in remote environments, setting up:

• Board sharing protocols enabling 24/7 development across time zones
• Administering powercommons.org website and corresponding repositories
• Documentation and assisting new members

Open Source Contributions

My work has resulted in multiple upstream contributions:

• Microwatt repository: VCU118 platform support and DRAM integration
• LiteX repository: PowerPC architecture fixes and improvements
• Documentation: Setup guides and troubleshooting resources

You can refer to powercommons.org - I built and maintain the site along with build infrastructure and Git repositories.

This practical experience with real hardware, complex system integration, and community collaboration provides the foundation necessary to tackle PowerCommons’ ambitious goals of creating a fully open, verifiable SoC platform.

3. Budget Breakdown and Funding Utilization

We request a total funding of EUR 50,000. Note that the numbers below are indicative - given the highly complex nature of the project some funds may have to re-directed to secure equipment and/or licenses. Additionally, some costs might be shared with our companion proposal for bringing A2O core to life in case it is accepted leaving more room for personnel costs.

Budget Summary

Detailed Budget Breakdown

Personnel Costs (€40,000 - 80%)

I will serve as the lead developer while actively searching for an experienced contributor within the EU who is willing to work at these rates. Given the specialized expertise required and budget constraints, finding such a candidate may prove challenging. If we successfully identify a qualified second contributor with deep technical knowledge, the budget will be allocated between us. Otherwise, I will continue the work independently and allocate the personnel budget accordingly.

Verification and Testing (€2,500 - 5%)

Documentation and Dissemination (€1,000 - 2%)

Contingency and Flexible Allocation (€6,500 - 13%)

This contingency budget provides flexibility to address actual project needs as they arise, whether for hardware acquisition, additional tools, or unexpected technical challenges.

Other Funding Sources

The OpenPower Foundation provides in-kind support through technical expertise and testing infrastructure. No direct monetary funding is currently secured, though follow-on funding from EU Horizon Europe is planned for production implementation phases.

4. Comparison with Historical Efforts

PowerCommons represents a fundamental shift in approach compared to previous open processor initiatives. Where others attempted revolutionary designs or accepted proprietary components as necessary evils, we pursue evolutionary improvement while maintaining absolute openness.

Formal verification opportunities

Unlike previous OpenPower processor initiatives that resulted in designs too complex for comprehensive formal verification, our approach creates unique opportunities for mathematical validation. MicroWatt, despite being a full-fledged 64-bit processor capable of booting Linux, maintains a remarkably small codebase (~20,000 lines of VHDL) that makes formal verification feasible. This compact yet powerful design enables us to pursue formal proofs of critical properties such as memory safety, instruction correctness, and absence of timing side-channels. By pairing the formally verifiable MicroWatt as a secure boot processor with the performance-oriented A2O core, PowerCommons can offer unprecedented security assurances—something impossible with proprietary processors or overly complex open designs like LibreSOC. This positions our project to deliver not just open hardware, but mathematically proven secure hardware, addressing critical infrastructure needs where verification is paramount.

IBM Power9 Reference Design Limitations

IBM’s Power9 reference platform provided open firmware (Hostboot/Skiboot) but relied on proprietary ASPEED BMCs and, critically, the Power9 processor itself remained closed-source. Organizations deploying these systems must trust IBM’s implementation without ability to verify or modify processor behavior. PowerCommons eliminates these trust dependencies by using fully open processor cores whose every logic gate can be inspected and verified.

LibreSOC’s Overreach

LibreSOC attempted to create a novel hybrid CPU/GPU architecture with advanced vector processing capabilities. This revolutionary approach required solving multiple research-grade problems simultaneously:

• New instruction set extensions
• Novel microarchitecture designs
• Unproven synthesis techniques

The project struggled with verification complexity and lack of incremental validation milestones. PowerCommons instead leverages proven, working processor cores (Microwatt and A2O), focusing innovation on system integration rather than core architecture. This allows incremental validation at each integration stage.

PowerPC Notebook’s Integration Gaps

The PowerPC notebook project correctly identified market demand for open computing platforms but relied on NXP’s proprietary T2080 processor. While they developed open board designs and some firmware, the critical processor and its initialization sequences remained black boxes. PowerCommons ensures every component from transistor to application remains modifiable and maintainable by the community.

System76/Purism’s Partial Openness

Companies like System76 and Purism market “open” computers but rely entirely on proprietary Intel/AMD processors with Intel Management Engine or AMD Platform Security Processor. These hidden processors run unauditable code with full system access, negating security benefits of open firmware. PowerCommons provides genuine transparency with no hidden processors or unauditable code paths.

RISC-V Initiatives’ Fragmentation

While RISC-V offers an open ISA, implementations remain fragmented with varying degrees of openness. SiFive’s processors are proprietary, while open implementations like BOOM lack the maturity and ecosystem of OpenPOWER. Furthermore, the RISC-V ecosystem’s manufacturing and design capabilities are heavily concentrated in specific geographic regions, with the majority of commercial RISC-V development occurring in China. This concentration raises concerns for organizations requiring supply chain diversity and technological independence. PowerCommons benefits from OpenPOWER’s 30-year ecosystem maturity, extensive software support, proven enterprise deployments, and geographically distributed development community spanning Europe, North America, and other regions.

Our Differentiation

PowerCommons succeeds by:

1. Incremental complexity - Starting with working cores, adding integration layers progressively
2. Complete openness - No proprietary dependencies anywhere in the stack
3. Verification focus - Every component formally verifiable and reproducibly buildable
4. Ecosystem leverage - Building on OpenPOWER’s mature software ecosystem
5. Practical deployment - Targeting real use cases in security-critical applications

Unlike academic projects that prioritize novel research, or commercial efforts that accept proprietary components for convenience, PowerCommons delivers practical, fully open computing infrastructure. This positions it uniquely as the first genuinely trustworthy computing platform where every transistor’s behavior can be verified.

5. Technical Challenges

PowerCommons faces several interconnected technical challenges that push the boundaries of open hardware development while maintaining practical deployability.

Heterogeneous Multi-Core Integration

Integrating Microwatt (in-order, control-optimized) with A2O (out-of-order, compute-optimized) processors requires sophisticated cache coherency protocols and interconnect design. The processors have different pipeline depths, memory access patterns, and timing characteristics. Creating efficient communication between asymmetric cores while maintaining coherency requires careful protocol design and extensive verification.

Open BMC Implementation

Replacing proprietary BMCs represents uncharted territory in open hardware. BMCs handle critical functions including:

• Power sequencing
• Thermal management
• Fault detection
• Out-of-band management

Creating an open BMC requires implementing complex state machines for power management, developing thermal control algorithms, and ensuring fail-safe operation under all conditions. The BMC must monitor dozens of voltage rails, temperature sensors, and system health indicators while maintaining real-time response guarantees. This requires careful co-design of hardware monitoring capabilities and software control loops.

Firmware Stack Complexity

Adapting OpenPOWER’s Hostboot/Skiboot firmware for our open cores requires deep understanding of:

• Processor initialization sequences
• Memory training algorithms
• Secure boot flows

The firmware must handle differences between our implementation and IBM’s Power processors, including different cache sizes, TLB structures, and performance monitoring capabilities. Self-Boot Engine (SBE) equivalent functionality must be reimplemented for our open cores, handling early initialization before main firmware takes control.

Security Architecture Without Proprietary Elements

Implementing secure boot and attestation without proprietary security processors presents novel challenges. We must:

• Create hardware root of trust using open FPGA logic
• Implement cryptographic operations in verifiable hardware
• Ensure attack resistance without security-through-obscurity

This includes protecting against fault injection, side-channel attacks, and physical tampering while maintaining complete design transparency.

Performance Optimization Within FPGA Constraints

Achieving usable performance on FPGA platforms requires aggressive optimization across multiple dimensions. Clock frequency limitations of FPGAs (typically 100-200MHz) demand architectural optimizations to maintain acceptable performance. This includes:

• Implementing efficient cache hierarchies
• Optimizing critical paths
• Potentially adding specialized accelerators for common operations

Memory bandwidth limitations of FPGA boards require careful data flow optimization and potentially custom memory controllers.

Verification and Validation Complexity

Verifying correct operation of a complete SoC requires sophisticated methodologies combining:

• Formal verification
• Simulation
• Hardware testing

Cache coherency protocols must be formally proven correct, while system-level behaviors require extensive simulation. Creating comprehensive test suites that exercise all corner cases of multi-core interaction, interrupt handling, and error conditions requires significant effort. Hardware-software co-verification becomes critical when firmware depends on specific hardware behaviors.

Build System and Reproducibility

Ensuring reproducible builds across the entire stack - from HDL through firmware to operating system - requires sophisticated build system design. Different toolchains (Vivado for FPGA, GCC for firmware, Linux build systems) must be coordinated. Version management across hundreds of dependencies while maintaining build reproducibility demands careful infrastructure design. Supporting multiple FPGA targets with different resource constraints requires parameterizable designs and automated resource optimization.

Real-Time Operating Constraints

The BMC portion must maintain real-time guarantees for thermal management and fault response while running on resource-constrained soft processors. This requires:

• Careful RTOS selection or development
• Worst-case execution time analysis
• Interrupt latency optimization

Balancing real-time requirements with security features like secure boot verification adds additional complexity.

These challenges require expertise spanning computer architecture, FPGA design, embedded systems, security engineering, and formal verification - a combination rarely found in single teams. Our approach addresses this through modular design allowing parallel development, extensive reuse of proven components, and incremental integration with continuous validation.

6. Ecosystem Engagement

Core Ecosystem Partners

The OpenPOWER Foundation remains our primary ecosystem anchor, providing technical guidance, testing infrastructure, and community connections. Their working groups on security, firmware, and compliance ensure PowerCommons aligns with industry standards while pushing open hardware boundaries.

Academic and Research Engagement

Universities with hardware security research programs form natural early adopters, using PowerCommons for verifiable security research and education. We’ll establish partnerships with:

• [To be determined based on engagement]
• [Additional institutions to be identified]

These partnerships provide early access to designs and collaborative research opportunities. The reproducible builds and formal verification aspects appeal to academic researchers in formal methods and verification, creating opportunities for joint publications and tool development collaborations.

Government and Critical Infrastructure

European governmental agencies concerned with digital sovereignty represent key stakeholders. We’ll engage with initiatives like:

• Germany’s Sovereign Tech Fund
• [Additional agencies to be identified]

This positions PowerCommons as enabling truly sovereign computing infrastructure. Critical infrastructure operators requiring verifiable security - power grids, water systems, telecommunications - benefit from PowerCommons’ auditability. Early engagement with sector-specific security requirements ensures practical deployability.

Risk Mitigation Strategies

Technical Risks

• Multi-core integration complexity: Mitigated through incremental integration and extensive simulation
• BMC development challenges: Addressed by leveraging existing OpenBMC framework components
• Performance constraints: Managed through architectural optimization and selective hardware acceleration

Project Risks

• Schedule delays: Buffered through parallel development tracks and modular design
• Resource constraints: Mitigated through OpenPower Foundation support and community engagement
• Adoption barriers: Reduced through early stakeholder engagement and practical demonstrations