Skip to main content
RISC-V soft processor architecture diagram implemented on Arty A7 FPGA

Running a RISC-V Soft Processor on the Digilent Arty A7: A Practical Introduction

GSAS Engineering · · 6 min read

The RISC-V instruction set architecture has moved from academic curiosity to industry reality. India, in particular, has embraced RISC-V through government initiatives, academic research programmes, and a growing ecosystem of startups and established companies developing RISC-V processors and IP. For engineers who want to understand RISC-V at the hardware level, not just write software for a RISC-V chip, but actually implement and modify a RISC-V processor, an FPGA development board is the essential tool.

The Digilent Arty A7, built around the AMD/Xilinx Artix-7 FPGA, has become one of the standard platforms for RISC-V soft processor development. Its combination of sufficient FPGA resources (33,280 or 101,440 logic cells), 256 MB DDR3L memory, Ethernet, and an accessible price point makes it the natural choice for RISC-V experimentation.

What Is a Soft Processor?

A soft processor is a processor implemented in the programmable logic fabric of an FPGA, rather than fabricated as a dedicated silicon chip. The processor’s logic, instruction fetch, decode, execute, memory access, writeback, is described in HDL (VHDL or Verilog) and synthesised onto the FPGA’s lookup tables, flip-flops, and block RAMs.

The advantage is flexibility: you can modify the processor architecture, add custom instructions, change the pipeline depth, add or remove peripherals, and experiment with microarchitectural trade-offs, all by changing HDL code and re-synthesising. This is impossible with a fixed silicon processor.

The trade-off is performance: a soft processor on an FPGA runs at 50-100 MHz (limited by FPGA routing delays), compared to hundreds of MHz or GHz for dedicated silicon. But for learning, prototyping, and architectural exploration, performance is secondary to flexibility.

RISC-V Soft Processor Options for the Arty A7

MicroBlaze V (AMD/Xilinx)

AMD/Xilinx’s MicroBlaze V is the official vendor-supported RISC-V soft processor for Xilinx FPGAs. It replaces the earlier MicroBlaze (which used a proprietary ISA) with a RISC-V-compatible implementation. MicroBlaze V integrates with the Vivado/Vitis design flow, with automated peripheral generation, interrupt controller configuration, and software development tools.

Pros: Full vendor support, integrated with Vivado/Vitis, includes peripheral IP library (UART, SPI, I2C, GPIO, timer, interrupt controller), documented tutorials and reference designs for the Arty A7.

Cons: Proprietary implementation (not open-source), requires Vitis IDE for software development, vendor lock-in to AMD/Xilinx toolchain.

VexRiscv

VexRiscv is an open-source RISC-V soft processor written in SpinalHDL (which generates Verilog for synthesis). It is highly configurable, pipeline stages, instruction set extensions (M, C, F), cache sizes, and peripheral interfaces are all configurable parameters. VexRiscv is widely used in the open-source FPGA community and runs well on the Arty A7.

Pros: Open-source, highly configurable, supports RV32IM[A][F][D][C] configurations, community-maintained, runs Linux (RV32IMA + MMU configuration).

Cons: Requires SpinalHDL knowledge for deep customisation, less polished tooling compared to MicroBlaze V, community support rather than vendor support.

NEORV32

NEORV32 is an open-source RISC-V soft processor written in plain VHDL, no special HDL generators required. It implements the RV32I base ISA with optional M, C, U, and Zicsr extensions. NEORV32 is designed for simplicity and portability, making it an excellent choice for engineers learning both RISC-V and VHDL simultaneously.

Pros: Pure VHDL (no special tools needed), well-documented, includes bootloader and software framework, small resource footprint, portable across FPGA vendors.

Cons: Less configurable than VexRiscv, single-issue in-order pipeline only, smaller community.

Practical Considerations for Indian Engineers

Start with MicroBlaze V if you want the fastest path from zero to running software on RISC-V. The Vivado/Vitis integration means you can have a RISC-V system with UART, GPIO, and a simple C programme running in an afternoon. This is the right choice for engineers whose primary interest is RISC-V software development and application prototyping.

Start with NEORV32 if you want to understand the processor at the RTL level. The pure VHDL implementation is readable and well-commented. You can trace instruction execution through the pipeline, modify the decoder, and add custom instructions with direct access to the source code. This is the right choice for computer architecture courses and engineers building processor design skills.

Start with VexRiscv if you want a high-performance soft processor that can run Linux on the FPGA. The RV32IMA + MMU configuration on the Arty A7 100T boots Linux, enabling a complete software development environment on the FPGA. This is the right choice for systems engineers evaluating RISC-V for embedded Linux applications.

The Arty A7 Hardware for RISC-V Development

The Arty A7’s hardware maps well to soft processor requirements:

  • 256 MB DDR3L provides the main memory for programme and data storage, essential for any non-trivial software execution and mandatory for Linux boot
  • 16 MB Quad-SPI flash stores the FPGA bitstream and can store the processor’s boot code
  • Ethernet enables network communication, remote debugging, file transfer, and networked applications
  • USB-UART provides the serial console for bootloader interaction and programme output
  • Pmod connectors attach peripheral hardware, the soft processor’s I/O subsystem connects to Pmod modules through the FPGA fabric

The 35T variant supports simple soft processor implementations (MicroBlaze V, NEORV32). The 100T variant is recommended for VexRiscv Linux configurations and multi-processor experiments.

Why Buy from GSAS

GSAS is an authorized partner in India, providing the Arty A7 (35T and 100T), Pmod modules, and the full Digilent portfolio with INR invoicing and local support. We serve engineers, researchers, and educational institutions across Bengaluru, Hyderabad, Chennai, Pune, Mumbai, Delhi NCR, and Visakhapatnam.

Explore Arty A7 → | Visit the GSAS Store →

Interested in Digilent tools?

Talk to our application engineers for personalized tool recommendations.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.

Related Articles

GSAS Micro Systems launch key visual for the manufacturing and R&D facility at Doddaballapur, Karnataka, India
Life at GSAS

What the Doddaballapur Facility Does, and Why That Matters to a German Engineering Team

The press release covered the building. This covers what the building does: FPGA and embedded board work, vision and edge AI engineering, automotive board bring-up and production test automation, and why that combination makes GSAS an offshore development centre partner for German and DACH teams.

21 Sept 2026 · 9 min read
Horizontal stacked bar showing where an ADAS test vehicle's bandwidth budget is spent, split into cameras, lidar, radar and bus traffic, with the logger uplink limit drawn as a vertical rule crossing the bar, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

ADAS Sensor Data Logging: Bandwidth Budgets That Add Up

Every page that tells you an ADAS test vehicle produces terabytes a day states the headline and skips the arithmetic, so you cannot redo it for your own sensor set. This article publishes the arithmetic instead: one formula, every table row derived on the page, a worked eight-hour drive that chains those rows into a sustained write rate, a media count and an offload window, and the five places bandwidth budgets go wrong. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 15 min read
Two test paths leaving the same device under test, one into a conformance suite that returns a passed report and one into a partner node that surfaces a field defect, showing why an ECU can clear a published suite and still fail in a vehicle, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

Automotive Ethernet Conformance: TC8 and Testing Above It

Summarising TC8 as a layer 1 to layer 4 suite is wrong in both directions. The public OPEN Alliance ECU test documents run from transmitter distortion up to a SOME/IP chapter with its own standardised test stub, and they contain exactly one time synchronisation test case. This is what those documents enumerate, chapter by chapter, what genuinely lives above their boundary, why a passing ECU can still fail against a partner node, and how much pre-compliance work a Tier-1 in India can honestly do in-house before a test house visit. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 12 min read