ibm / esp-chisel-accelerators

Chisel wrapper and accelerators for Columbia's Embedded Scalable Platform (ESP)

ESP Accelerators in Chisel

This project provides an Embedded Scalable Platform (ESP) Accelerator socket that can be used for writing ESP-compatible accelerators in chisel3.

A concrete ESP-compliant accelerator is composed from an esp.Implementation that aligns to an esp.Specification. The resulting accelerator is then wrapped with an esp.AcceleratorWrapper that maps the interfaces of the accelerator to the expected top-level interface. The esp.Specification is abstract in a configuration that defines metadata that the ESP framework requires.

When generating Verilog from an esp.Implementation, a FIRRTL annotation is emitted containing the accelerator configuration. A custom FIRRTL transform EmitXML will convert this configuration information to XML that the ESP framework needs.

We currently provide one example accelerator, esp.examples.CounterAccelerator that always reports as being finished a run-time configurable number of cycles in the future.

To build the example accelerator, simply run:

sbt run

To run our existing tests use:

sbt test

esp-chisel-accelerators's Issues

FFT Accelerator Example

Add an FFT accelerator example compliant with an ESP socket. Low-effort integration candidates include:

• ucb-art/MixedRadixFFTGenerator
• ucb-art/fft

DMA Simulation Infrastructure

• Add DMA simulation infrastructure

.travis.yml: The 'sudo' tag is now deprecated in Travis CI

Travis are now recommending removing the sudo tag.

"If you currently specify sudo: false in your .travis.yml, we recommend removing that configuration"

Automatic Generation of Driver and Example Applications

Like with the XML metadata generation, it should be possible to emit a Linux driver and both baremetal and Linux test programs for an accelerator. This issue covers discussion related to how to do this.

Make AcceleratorWrapper names a function of wrapped Accelerator

Improve the name of the AcceleratorWrapper to reflect what it wraps. Depends on C911/C912.

Add support for newer grebe/ofdm FFT

The grebe/ofdm FFT includes the Direct/SDF FFT originating from UC Berkeley's Fall 2018 EE 290C. We currently only support this one, but there is a newer FFT in the same repo that should be supported by esp-chisel-accelerators.

Median Filter Example

• Write/add median filter example

FFT Accelerator Support 64-bit DMA configuration

Ariane support requires 64-bit DMA accesses. The current FFT accelerator only works for 32-bit DMA accesses.

ESP expects the top level module name to match the configuration name and end with '_dma<32|64>'

The FFT accelerator generates one configuration only: '_Default_dma32', however, the corresponding RTL module is assigned the name 'FFTAccelerator_Default_fft32' instead of 'FFTAccelerator_Default_dma32'

Number of accelerator pages is fixed to 0

The XML description of an accelerator includes a field named "data_size". This corresponds to the maximum number of accelerator pages needed. Typically, each page is 1 MB, so accelerator designers should enter here the size in MB of the memory region that the accelerator will access.

For example, let's consider the FFT, which operates in place and has a memory footprint equal to the input size. If the designer plans to invoke FFT to process at most 1024 input vectors, each of at most 2048 32-bits samples (real + imaginary), the memory footprint will be 1024 * 2048 * 2 * 4 B = 16 MB.
Therefore, "data_size" should be set to 16.

Note that the page size can be changed by software in case designers need to increase the memory footprint of the accelerator beyond the original estimate.

DMA test error

when I run the DmaSpec testcase, it come out the error:

[info] DmaSpec:
[info] QuickFPS.Dma
[info] DmaSpec *** ABORTED ***
[info]   java.lang.NoSuchMethodError: treadle.TreadleTester.<init>(Ljava/lang/String;Ltreadle/HasTreadleSuite;Lfirrtl/CircuitForm;)V
[info]   at chisel3.iotesters.TreadleBackend.<init>(TreadleBackend.scala:17)
[info]   at chisel3.iotesters.setupTreadleBackend$.apply(TreadleBackend.scala:147)
[info]   at chisel3.iotesters.Driver$.$anonfun$execute$2(Driver.scala:53)
[info]   at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
[info]   at logger.Logger$.$anonfun$makeScope$2(Logger.scala:166)
[info]   at scala.util.DynamicVariable.withValue(DynamicVariable.scala:62)
[info]   at logger.Logger$.makeScope(Logger.scala:164)
[info]   at logger.Logger$.makeScope(Logger.scala:127)
[info]   at chisel3.iotesters.Driver$.$anonfun$execute$1(Driver.scala:38)
[info]   at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
[info]   ...

It seem that some class has problem with running time, since I can generate .v file.

FFT Accelerator does not advance past the load transaction in full-system simulation

The RTL simulation of the FFTAccelerator integrated in ESP shows that the first DMA transaction runs correctly: the accelerator requests 32 DMA words (32 bits) and reads in 32 DMA words, however, once that first transaction completes, no more transactions occur.

Given that 32 is the number of samples used for the simulation and that each value is a 32-bit fixed point number, I suspect the accelerator should have requested 64 words on a 32-bits bus: each sample has real and imaginary values.

Auto-emit XML Configuration

ESP requires some XML to be written for an accelerator. This should be done automatically by the Chisel generation process.

conf_info Ports should be a function of the AcceleratorConfig

Right now, the Configuration ports (of Accelerator and AcceleratorWrapper) are static. However, these are supposed to be a function of the AcceleratorConfig.