BlackParrot: a small open RISC-V multicore that boots Linux

An open multicore aiming to be the default

The BlackParrot tagline in the README is a Linux-capable Accelerator Host RISC-V Multicore, and the project status line states the aim: BlackParrot aims to be the default open-source, Linux-capable, cache-coherent, RV64GC+ multicore used by the world.

That is a large ambition stated plainly, and the surrounding text explains where it comes from. Although originally developed by the University of Washington and Boston University, BlackParrot strives to be community-driven and infrastructure agnostic, a core which is Pareto optimal in terms of power, performance, area and complexity.

The use cases are named in the same paragraph, and they set the audience more precisely than the ambition does. BlackParrot is ideal as the basis for a lightweight accelerator host, a standalone Linux core, or as a hardware research platform.

A lightweight accelerator host is the case that makes the most sense of the design. When you are building a domain specific accelerator, the host processor exists to move data, run a small runtime and schedule work, and every square millimetre and every milliwatt of it competes with the accelerator itself. A core small enough to be a supporting player, and capable of running Linux so that you can reuse ordinary software, is exactly what that role needs.

The primary language is SystemVerilog, the licence is BSD-3-Clause, the last push to the repository was on 2026-10-14, and the repository has no GitHub releases.

The second and third use cases, a standalone Linux core and a hardware research platform, are for people who want to study or modify a coherent multicore rather than ship a product.

Be Tiny, Be Modular, Be Friendly

Three principles are used to guide development, and they are stated as a manifesto rather than as guidance, which tells you they are meant to be used when there is a disagreement.

Be Tiny: when deliberating between two options, consider the one with least hardware cost and complexity.

Be Modular: prevent tight coupling between modules by designing latency insensitive interfaces.

Be Friendly: combat NIH, welcome external contributions and strive for infrastructure agnosticism.

The first two are technical and they pull against each other in an interesting way. Being tiny pushes towards a minimal implementation, but being modular pushes towards well defined interfaces between pieces, and interfaces cost area. The resolution the project gives is latency insensitive interfaces, which is the right answer: a handshake based interface costs more in wires and protocol logic than a shared clock domain, but it decouples the modules so they can be changed independently, and in a project that has been through four tape-outs and multiple versions, that independence is what has kept the core configurable.

The third principle is aimed at the community rather than the hardware. Combatting NIH is an unusual thing to write in a hardware README, and it reflects the history of academic processor projects, where a design built for one paper or one tape-out tends to become unmaintainable once the students graduate. The current repository bears this out, with a GitLab CI pipeline badge, a contribution guide, a mailing list, and separate repositories for the SDK, the HDK and the simulation environment.

The stated priority order is also revealing. Development efforts have prioritized ease of use and silicon validation as first order design metrics, so that users can quickly get started and trust that their results will be representative of state-of-the-art ASIC designs. That is a statement about what kind of user is expected, which is someone building real chips rather than someone running a teaching simulation.

Four tape-outs, and a quad core running in the lab

The news section is where the evidence is, and it is physical evidence rather than benchmark charts.

A 12nm quad-core BlackParrot multicore chip was taped out in July 2019. A 12nm BlackParrot dual-core accelerator host was taped out in July 2020. A 28nm heterogeneous dual-core BlackParrot was taped out in August 2022, and a 28nm heterogeneous dual-core BlackParrot was taped out in January 2025.

Four tape-outs across two process nodes in six years, with the shape of the design changing from a quad core to a dual core accelerator host, and then to a heterogeneous dual core. That progression is a good indication of what the project is actually for: the centre of gravity moved towards a small heterogeneous pair of cores as an accelerator host, and the quad core served the research platform role.

The release history in the project status section is consistent with that. BlackParrot v1.0 was released in March 2020, and quad core silicon has been running in the lab since April 2020. BlackParrot v2.0 was released in January 2024 and has been up and running in the lab since then. BlackParrot v2.1 was released in November 2025.

So the current code corresponds to the 2.1 line, and there has been hardware running the design for over a year.

For an adopter, the distinction between the two roles matters, because the README describes a size-optimized single core with under 16 KiB of total SRAM and a 16 core and above cache coherent multicore with a distributed LLC, and the silicon that exists is a quad core and a dual core. The middle of the range is where the experience is, and the ends are configurations rather than products that have been taped out.

The instruction set and privilege level that Linux actually needs

The currently supported list is short, and each item is a decision that someone had to make.

RV64IMAFDCSU_Zfencei_Zicsr User Mode 20191213 extensions with Privilege Mode 1.11 support is the whole instruction set story. That is the ratified 2019 user mode extension set, plus the Zfencei and Zicsr extension modules, running with a version 1.11 privileged architecture.

The privileged version number is the detail that matters for Linux. A privileged specification version is not the same as the base ISA version, and the two move independently. Linux needs a specific privileged architecture version to boot, and 1.11 is the version the current branch targets. The user mode extension date, 20191213, tells you which set of frozen user mode extensions is implemented, and the date suffix matters because those extension sets are frozen in time.

Then there is baseline user and privileged functionality to run Linux, SPEC and other standard workloads. That sentence is a claim about what has been made to work, and the inclusion of SPEC alongside Linux is the interesting part. SPEC is a CPU benchmark suite, so the claim is not only that a Linux kernel boots but that the core is intended to run the workloads people use to characterise a processor.

This is where the project's name, BlackParrot, comes from in spirit. The design philosophy is a small core that still runs the operating system, so that the ecosystem of Linux software is available on a processor small enough to sit next to an accelerator.

One core under 16 KiB, or sixteen cores with a distributed LLC

The configuration range is stated as two bullet points, and the spread between them is the interesting part.

Configuration scaling up to a 16 core and above cache coherent multicore with distributed LLC. Configuration scaling down to a size optimized single core with under 16 KiB of total SRAM.

That is more than a decade of processor design in one line, and it is enabled by the modularity principle. The cache coherence directory, the LLC and the network are separate modules connected by latency insensitive interfaces, so a single core instance does not have to carry the coherence fabric, and a large system can spread the last level cache across the machine instead of centralising it.

The cache coherence protocol itself has a caveat that matters for anyone planning research on it. There is experimental micro-coded BP-BedRock cache coherence support, marked as not fully featured. BP-BedRock is the name of the protocol, and the README says the implementation is experimental and micro-coded, which means it is not the kind of thing you would put in a tape-out without reading the code first.

The distributed LLC is the other half of the scalability story, and it is where the difference between a research platform and a product shows. A distributed last level cache changes the memory hierarchy into something with a network topology, and the performance characteristics of the system then depend on placement and routing as much as on the cores. The README does not quote any performance figures, and for a design that is still being validated, the absence is understandable.

Building the libraries, and picking an environment first

The getting started section is short, and it starts with a warning that the repository is not the thing you run.

This RTL repo is intended to be used with a specific SDK and an HDK, depending on the simulation, FPGA or ASIC environment desired. For first time users, the README recommends starting from the BlackParrot Simulation Environment, which packages the BlackParrot RTL and SDK in a compatible manner. The intent is to release several examples of BlackParrot environments which package the RTL, SDK and HDK together for evaluation, and currently BlackParrot Simulation and ZynqParrot are supported. Users can of course set up their own environments based on these examples.

That is a sensible arrangement, because the combination of RTL, software development kit and hardware development kit is what determines whether your results are meaningful, and a mismatched combination is the classic way to get an FPGA result that says nothing about an ASIC result.

The libraries themselves can also be built directly in this repository, and the make targets are listed for that case.

    make libs_lite;     # minimal set of simulation libraries
    make libs;          # standard libraries
    make libs_bsg;      # additional libs for BSG users

The maintenance targets are listed alongside, including checkout for submodules, which the README says should be done before building libs, help, and bleach_all which wipes the whole repo clean, so use with caution. The lesser tested operations are clean, tidy and bleach.

The Makefile in the repository root shows what those targets expand to. libs_lite builds dramsim3 and bedrock, and libs and libs_bsg are built on top of it.

Once an environment is set up, the evaluation guide at docs/eval_guide.md is the document to follow to test the core RTL.

Running Linux, writing bare metal, and one guide that needs help

The software development kit section has a practical argument in it that is worth quoting in substance.

BlackParrot is Linux-capable, so it is possible to run all programs which run on BusyBox. However, for more targeted benchmarks which do not want operating system management overheads, or the overheads of a long Linux boot time in simulation, it is preferable to write for bare-metal. Additionally, some platform specific features are only available at the firmware level.

So the SDK supports two modes of use, and the choice depends on what you are measuring. If you want to run real software, Linux and BusyBox give you a familiar userspace and the whole application layer above it. If you want to measure the core, you strip the operating system away, because a kernel scheduler and a long boot sequence in simulation are overheads that have nothing to do with the processor you are characterising.

That is a mature position for a research platform, and it also has a cost: two environments to maintain and two sets of results to interpret.

The accelerator developer guide is the weak spot, and the README is honest about it. The specific instructions there are outdated, and there is a help wanted to resurrect examples and re-document them.

That single line tells you a lot about the state of the project. The core is validated and the environments are packaged, but the examples that show a newcomer how to build an actual accelerator on top of BlackParrot have gone stale, and the project is asking for help to bring them back. For anyone evaluating BlackParrot specifically as an accelerator host, that is the gap to weigh, and it is a documentation gap rather than a technical one.

Editorial conclusion

BlackParrot suits a hardware team that wants a small, modifiable, cache coherent RISC-V core to build an accelerator host on, to use as a research platform, or to take to silicon with a design that has already been taped out four times. It does not suit a team looking for a general purpose processor, a binary compatible ecosystem, or an existing software stack, since the whole point of the design is its size and its customisation. Before you commit, read the evaluation guide at docs/eval_guide.md and pick an environment deliberately, because the RTL is meant to be used with a specific SDK and HDK and the simulation environment is the recommended starting point for first time users, and note that the last push to the repository was on 2026-10-14 with no GitHub releases, so you track master rather than a tag.

Frequently asked questions

Official sources

1. black-parrot/black-parrot on GitHub
2. Issues
3. License: BSD-3-Clause
4. README