Soft Arduino and accelerated libraries

[lawrie]

I just added the generated files for the BlackSoC hello example, so that you can see what the top level module looks like, including SRAM support. Note that Clifford wrote a different uart for this project.

lawrie/icotools/blob/master/icosoc/examples/hello/icosoc.v

[uXe]

I've stitched together the Arduino RISC-V core with my VGA1306 code, and the experimental result is running a (also stitched together) version of the Adafruit SSD1306 Arduino demo sketch that outputs directly to the VGA1306 OLED emulation - all self-contained within the BlackIce II:

uXeBoy/RISCV1306

[Folknology]

Nice work @uXe I am sure that is quite a bit of Arduino stuff than can be accelerated with FPGA

[daveshah]

Video output; camera processing; smart LED strips (WS2812)/panels and motor control all spring to mind. As well as anything where you need higher-than-usual numbers of peripherals, like 32 UARTs or 100 PWM channels.

This is definitely something that could make FPGAs more accessible if done properly - not just preconfigured bitstreams but a way of adding components and their associated software drivers to the design at the same time.

[lawrie]

The way of configuring a SoC that Clifford Wolf invented with icoSoC and I used with BlackSoC is a start in being able to add components and their software drivers. The components are defined by Verilog modules, and a configuration file (icosoc.cfg) defines what components a design uses, what pins they are attached to and what memory-mapped addresses they use. Another file defines a low-level API for driving the components.

To integrate this with Arduino, Arduino libraries would need to use the generated low-level API.

A concept of a dynamically generated Arduino board would be needed to cope with things like large numbers of SPI, i2c and uart devices. For a specific board, pin mappings in Arduino are fixed and defined in board-specific headers like variant.h and variant.cpp. Such files would need to be dynamically generated from the configuration file.

In addition, the Arduino API for devices like SPI, Serial (uart) and Wire (i2c) is not suited to having large numbers of devices that use those protocols. It currently uses Serial, Serial1, Serial2 etc. So a new Arduino API for that would be needed.

[Folknology]

In addition, the Arduino API for devices like SPI, Serial (uart) and Wire (i2c) is not suited to having large numbers of devices that use those protocols. It currently uses Serial, Serial1, Serial2 etc. So a new Arduino API for that would be needed.

Doh! that is a complete PITA an array would be much better

[Folknology]

The way of configuring a SoC that Clifford Wolf invented with icoSoC and I used with BlackSoC is a start in being able to add components and their software drivers. The components are defined by Verilog modules, and a configuration file (icosoc.cfg) defines what components a design uses, what pins they are attached to and what memory-mapped addresses they use. Another file defines a low-level API for driving the components.

To integrate this with Arduino, Arduino libraries would need to use the generated low-level API.

Yeah I have played around with IcoSoc and BlackSoc it is the way we need to think. However the code is rather mangled and I can't help feeling it could be more modular and manageable.

[daveshah]

I think icosoc was very much a proof-of-concept; it could certainly be improved upon. I would like to see something that generated object-oriented drivers Arduino style. It could generate both names for people used to the Arduino way of working and an array.

The resulting C++ pseudocode would be thus:

// Static
class SerialPortDriver {
public:
	SerialPortDriver(volatile uint32_t *base) : base(base) {}
	void write(char c) { *base = c; } 
private:
	volatile uint32_t *base;
};

// Generated by codegen

SerialPortDriver Serial1(0x40000000);
SerialPortDriver Serial2(0x40000010);
SerialPortDriver Serial3(0x40000020);

SerialPortDriver &Serial[] = {Serial1, Serial2, Serial3};

[Folknology]

Hmm I'm not really clued up on the Arduino APIs, is Serial derived from Stream like wire and how is SPI handled?

[lawrie]

Serial is implemented by the class HardwareSerial which extends Stream and is in the Arduino core. There are also HardwareSerialn for n = 0..4, at least in the AVR implementation - https://github.com/arduino/ArduinoCore-avr/tree/master/cores/arduino

SPI is not in the core, but in its own library, with class SPI, not related to Stream - https://github.com/arduino/ArduinoCore-avr/tree/master/libraries/SPI/src.

Some boards have SPI1, SPI2 etc (including myStorm). There are lots of annoying variants of SPI for STM32, ESP8266 etc. with different methods supported.

Wire (i2c) is also in its own library and class TwoWire which extends Stream - https://github.com/arduino/ArduinoCore-avr/tree/master/libraries/Wire/src. Some boards (again including myStorm) have Wire1, Wire2 etc.

PWM, which is another thing we would want to support a lot of, is implemented by analogWrite, although there are board-specific methods that give more control over it. There is also the related tone function for audio tones.

pulseIn, shiftIn, shiftOut and variants are other core Arduino functions that we might want to do in hardware.

I am not sure that extending Stream would be sensible for an FPGA implementation.

[Folknology]

I am not sure that extending Stream would be sensible for an FPGA implementation.

Wouldn't this be required in order for type compatibility?

[lawrie]

Strictly yes, but I suspect that hardly any sketches or libraries rely on that. But I thinkt we need to get into the detail to decide this.

[daveshah]

I think compatibility with Arduino is definitely important given all the code that is out there - I'd rather have that than maximise performance. This then makes it a good "gateway drug" from Arduino to FPGAs.

Ideally there'd be configuration from a simple Python script - or even automatic extraction from the ino in some way or another, with things like

SerialPort("Serial1", tx=4, rx=5)

to create a serial port, exposed to the design as Serial1 and with given pin mappings. Perhaps you could create arrays of ports with syntax like this

SerialPort("SerialPorts[0]", tx=7, rx=6)
SerialPort("SerialPorts[1]", tx=8, rx=9)

Which would create everything - HDL and C++ - automatically

Obviously, other interfaces can be available where performance is important.

[lawrie]

We also need to specify the mapping between Arduino pin numbers and FPGA pin numbers/names, and say which are PWM pins, which are analog inputs, are which will be used for digital (gpio) I/O.. Any suggestion for a syntax for that?

I don't think we can deduce much about pin numbers from the ino file as they are different for each Arduino board, so the fact that it has used Serial, for example, does not tell us which pins to use. Also analysing all the files used including headers and libraries would be a lot of work.

[Folknology]

How does Arduino define which pins are available for Digital and analogue outputs?

[lawrie]

It is done in a table like this one in pins_ardiuino.h or sometimes in variants.c:

f32c/arduino/blob/master/hardware/fpga/f32c/variants/generic/pins_arduino.h

And all same definitions in variants.h:

f32c/arduino/blob/master/hardware/fpga/f32c/variants/generic/variant.h

The Zagreb University f32c/arduino Generic FPGA board has just two analog input pins and two PWM pins.

I am currently getting pinMode, digitalWrite etc. working in a TinyFPGA BX version of Soft Arduino. That is harder than making it work on BlackIce as it needs to work with the Verilog USB implementation - see https://discourse.tinyfpga.com/t/programming-the-tinyfpga-bx-with-arduino/898

[Folknology]

Well that seems simple for digital pins as they are all PWM we just need a header file with all pins listed. Does the arduino software work out if there is a conflict between using a pin as digital and say serial at the same time, or does it just rely on the user being sensible?

For analog input it willl be a register value and a channel, the channel number would suffice for the pin?

[lawrie]

There is not anything in the Arduino API that defines any of this - it is all board and implementation dependent.

All the API has is integer pin numbers and the aliases A0-An for some of the pin numbers that are used for analog input, but not analog output.

I don't believe there is anything that polices these use of pins - it relies on the user being sensible, and is very board-dependent.

icosoc has separate components for gpio and pwm (mod_gpio and mod_pwn Verilog modules), so you have to choose whether a pin is used for GPIO or PWM - it cannot be used for both. If we are to allow PWM on every pin without changing the configuration file we would need a combined GPIO and PWM component.

This is all related to how we would map Arduino pin numbers to the pin names or numbers used in the pcf file and to the pin names used in the Verilog top level module. icosoc used a Pmod-related pin number scheme that did not map well to other boards.

I don't know how analog channels will work in BlackEdge. The mapping between analog pins and channels in Arduino is board-specific.

[Folknology]

icosoc has separate components for gpio and pwm (mod_gpio and mod_pwn Verilog modules), so you have to choose whether a pin is used for GPIO or PWM - it cannot be used for both. If we are to allow PWM on every pin without changing the configuration file we would need a combined GPIO and PWM component.

One way of looking at this is that a digital pin is always PWM (say 0-255) when you want it low set it to 0 and high (fully on) 255, PWM is any value in between..

[lawrie]

One way of looking at this is that a digital pin is always PWM (say 0-255) when you want it low set it to 0 and high (fully on) 255, PWM is any value in between..

Yes, and that would need the common GPIO/PWMVerilog module. If we did it that way GPIO/PWM could be the default module that pins were connected to if they weren't mentioned in the configuration file as (say) Serial or SPI pins.

With that implementation, the user could choose in the Arduino .INO file whether to use those pins as digital or PWM, without changing the configuration file or generating and uploading a new bitstream.