Hardware Accelerator for Hyperspectral Image Processing

Hi, community!

I’m writing this post because I’d like to share one of the projects I have been working on, a hardware accelerator written in SystemVerilog for processing hyperspectral image vectors.

First of all, I want to give some context about this project.

Unlike a normal RGB image, a hyperspectral image can contain tens or even hundreds of spectral bands for each pixel. This makes this technology very useful for agriculture, environmental monitoring, remote sensing or material identification, but it also generates a large amount of data that must be processed.

For this reason, I wanted to explore how some vector operations could be moved from software to dedicated hardware, reducing the workload of the main processor.

The accelerator

The current version supports two operations:

• Dot product
• Cross product

The design uses two input FIFOs and one output FIFO. Internally, a finite-state machine controls the complete process, from reading the vectors to calculating and storing the result.

I also developed a wrapper with an OBI-compatible register interface, allowing the processor to configure the operation, select the number of bands, start the accelerator and read its busy, done and error status.

The accelerator was integrated into the X-HEEP ecosystem, using a RISC-V processor for control and a DMA controller to transfer the input and output data without requiring continuous CPU intervention.

Verification

For verification, I used Verilator together with C++ testbenches.

I created individual tests for:

• The FIFO memories
• The vector processing core
• The OBI wrapper
• The complete integrated accelerator

The testbenches verify normal operations, invalid configurations, empty and full FIFO conditions, signed calculations and register access.

The simulations achieved more than 90% coverage over the instrumented lines and signals. I also generated VCD files to inspect the internal behaviour using GTKWave.

Results

The functional tests confirmed that the accelerator correctly performs the dot and cross products and responds correctly to invalid operations and boundary conditions.

For the cross product, the latency per pixel becomes stable once the finite-state machine has started processing data.

For the dot product, the latency increases linearly with the number of spectral bands because the multiply-accumulate operations are performed sequentially.

The tests also showed something very important: the vector core itself was not the main bottleneck in the evaluated workloads.

The largest limitation came from moving data between memory and the accelerator.

The DMA introduces a fixed startup delay for every transfer. Because each operation requires two input transfers and one output transfer, this overhead has a significant impact when processing only a small number of vectors.

As a result, the software version can still be competitive for small datasets. The hardware accelerator becomes more useful with medium or large datasets, when the initial DMA cost can be distributed across more operations.

The measurements up to 4000000 vectors also showed a mostly linear behaviour, without clear memory saturation or cache-related steps in the evaluated range.

Image above shows the latency vs the compute data size for the vectorial product operations.

Conclusions

The main conclusion from this project is that developing the arithmetic unit is only one part of hardware acceleration.

The complete system performance also depends heavily on the memory architecture, bus bandwidth and data-transfer strategy.

The accelerator demonstrated that a custom SystemVerilog block can be successfully integrated into an open RISC-V platform and operate autonomously through an OBI interface and DMA transfers.

However, using dedicated hardware does not automatically make every workload faster. For small datasets, the communication overhead can cancel out the benefit of the accelerator.

For larger workloads, the hardware solution becomes more interesting because the fixed transfer cost is amortised and the CPU is released to perform other tasks.

In future versions, I would like to explore double buffering and overlapping DMA transfers with computation. I also want to support larger spectral vectors, improve the internal accumulator and finally synthesise the design on an FPGA to analyse resource usage, maximum frequency and power consumption.

One of the biggest lessons I learned is that a good accelerator must not only calculate quickly: it must also receive and return data efficiently.

I’m very happy with the results so far, and I would love to hear your feedback and suggestions!

If any person want to get mor info about this project I can share the github link.