FPGAventures: Linux on RISC-V With the Microchip PolarFire SoC Icicle Kit

The Microchip PolarFire SoC Icicle Kit runs Linux on four SiFive U54 RISC-V application cores while a separate E51 monitor core and the MPFS250T FPGA fabric handle control, real-time and hardware-accelerated work. The reliable path is to boot Microchip’s supplied image using the QuickStart wiring, then move to a Yocto-built image when you need different packages, device-tree settings or FPGA-connected peripherals.

What the Icicle Kit combines

The Icicle Kit is a development board built around the MPFS250T PolarFire SoC FPGA. Microchip describes the device this way: “Microchip’s PolarFire SoC devices combine a RISC-V 5x core Microprocessor Subsystem capable of running Linux and the PolarFire FPGA fabric in a single device.” Microchip’s embedded-software guide documents the Linux-capable processor subsystem and the FPGA side together.

#	Preview	Product	Price
1		Microchip Technology, MPFS-Icicle-KIT-ES, PolarFire SoC FPGA SiFive RISC-V Icicle Kit MPFS250T...	$1,085.72	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

The current kit documentation lists 254K logic elements. The board exposes Gigabit Ethernet, USB, an SD-card slot, PCIe, CAN and expansion connectors; the exact connector arrangement and bring-up procedure are in the PolarFire SoC Icicle Kit QuickStart Guide.

Check the board revision before connecting power

Microchip documentation distinguishes the current MPFS-ICICLE-KIT from an earlier engineering-sample kit. Read the label on your hardware and use the matching revision of the Icicle Kit embedded-software documentation. Pin assignments, images and setup details should not be assumed interchangeable between revisions.

#1 Best Overall

Microchip Technology, MPFS-Icicle-KIT-ES, PolarFire SoC FPGA SiFive RISC-V Icicle Kit MPFS250T Evaluation Board (1 Item/s)

$1,085.72

Buy on Amazon

A Linux or WSL host is sufficient for the software portion of the workflow. For the initial boot, have the board’s supplied power hardware, an Ethernet cable and a micro-USB cable available. A microSD card is useful because the board has an SD-card slot, but the cited documentation does not establish one universally approved capacity or speed class.

First boot with the supplied Linux image

Use the official QuickStart sequence for the first power-on rather than starting with a custom build.

1. Identify the board revision and place the supplied boot media in the board as directed by the QuickStart Guide.
2. Connect the supplied 12 V power source.
3. Connect Gigabit Ethernet if you want network access during or after boot.
4. Connect the micro-USB UART interface to the host and open the resulting serial console with the terminal settings specified in the guide.
5. Power the board and observe the boot messages. The supplied Linux image should reach a login prompt or shell through the UART console.

If the console remains silent, check the selected USB serial device, cable, board power and revision-specific instructions before changing the image. Do not infer a failed Linux boot solely from missing Ethernet activity; the UART console is the primary first-boot diagnostic path described by the guide.

Confirm the running system

After logging in, establish what actually booted before modifying anything:

• uname -a reports the running kernel and architecture.
• ip addr shows whether the Ethernet interface received a link or address.
• lscpu identifies the visible RISC-V processors.
• ls /dev/spidev* checks whether a userspace SPI device has been enabled in the image and device tree.

These checks separate a successful Linux boot from a peripheral configuration problem. A missing /dev/spidev* node, for example, does not mean the SPI controller is absent; it can indicate that the relevant device-tree node or userspace driver was not enabled.

Build a custom Linux image with Yocto

Custom images use Microchip’s linux4microchip Yocto manifest and the Icicle board configuration. The Microchip Developer Help GPIO example provides the supported pattern for setting up the build and changing board software: PolarFire SoC GPIO application.

1. Prepare the build host

Use a supported Linux distribution or WSL environment, install the host packages required by the Yocto release referenced by Microchip, and keep the build in a case-sensitive filesystem with enough free space. The exact package list and branch move with the manifest revision, so use the commands and branch named in the current Microchip instructions rather than copying an older tutorial.

2. Initialize the Microchip manifest

Initialize the linux4microchip Yocto manifest, select the revision that matches your Icicle documentation, and synchronize the layers. This supplies the board machine configuration, kernel, bootloader and recipes used by the supported image.

3. Select the Icicle target

Choose the Icicle Kit machine or target specified by the manifest documentation before starting the build. A target for another PolarFire SoC board can produce a valid image that nevertheless has the wrong pin mux, boot media or peripheral nodes for the Icicle.

4. Add packages and hardware settings

Place application packages in the appropriate Yocto image configuration and modify the board device tree for enabled GPIO, SPI or custom logic connections. Keep hardware description changes in a layer or configuration fragment so they can be reproduced when the manifest is updated.

5. Build, deploy and validate

Run the build task named by the selected Microchip manifest, write the resulting boot media or image using the deployment method in the Icicle guide, then boot over UART. Validate the change on the board: check the expected device nodes, exercise the interface and confirm that unrelated peripherals still initialize.

GPIO development pattern

Microchip’s GPIO application guide illustrates the normal progression: configure the Yocto image, describe the board GPIO in the device tree, rebuild, deploy and test from Linux. Use that pattern for LEDs, buttons or an external GPIO header instead of hard-coding pins in an application. The page was last modified on April 17, 2026, so check it alongside the board revision and current manifest.

SPI: start in Linux userspace, then accelerate selectively

The Microchip SPI application guide shows two supported validation routes:

1. Enable the SPI controller and its chip-select in the device tree and include the userspace support needed for spidev.
2. Use spidev_test to verify transfers and chip-select wiring.
3. Move to a small C program when your protocol needs application-specific framing or error handling.
4. Only after the Linux path is understood, place timing-critical or high-throughput portions in FPGA fabric and connect them through the documented SoC interfaces.

This staged approach makes a wiring or device-tree error visible before it is hidden inside a larger FPGA design.

Decide what belongs in Linux and what belongs in the FPGA

The point of the Icicle platform is not to choose between a processor board and an FPGA board. It lets a design assign each function to the subsystem that fits its timing, throughput and maintainability requirements.

Interfaces available for a prototype

Availability of an interface on the board does not by itself enable it in Linux. The kernel configuration, device tree, FPGA design and physical pin multiplexing must agree.

Toolchain, security and evidence limits

A complete project spans the Linux/Yocto software stack and Microchip’s FPGA design flow. Select the vendor tool versions and board files that match the Icicle documentation revision; mixing a device-tree description from one revision with an FPGA design or image from another is a common source of confusing failures.

For a deployable product, evaluate secure-boot and image-signing support in the applicable PolarFire SoC and board documentation rather than assuming that a development image is production-secure. Microchip’s product overview is the starting point for the device-level feature set: PolarFire SoC FPGAs.

No independent performance benchmark or power measurement is established by the cited material. Treat the Icicle as a flexible development platform, and measure throughput, latency, thermals and power on your own design.

Troubleshooting checklist

What the Icicle Kit is best suited for

• Learning how Linux and RISC-V software interact with FPGA logic in one device.
• Building networked or storage-aware FPGA prototypes with a Linux control plane.
• Testing deterministic I/O, sensor pipelines, communications and hardware acceleration.
• Creating a reproducible Yocto distribution tailored to a custom carrier, peripheral set or application.

Bottom line

Start with the revision-matched QuickStart image and UART console. Once that baseline works, use the linux4microchip Yocto manifest to create a reproducible Icicle image, describe peripherals in the device tree, and validate GPIO or SPI in Linux before moving timing-critical functions into the FPGA fabric. That processor-plus-FPGA split is the board’s defining advantage over a Linux-only single-board computer or an FPGA-only development board.

Quick Recap

Bestseller No. 1

Microchip Technology, MPFS-Icicle-KIT-ES, PolarFire SoC FPGA SiFive RISC-V Icicle Kit MPFS250T Evaluation Board (1 Item/s)

$1,085.72

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.