RISC-V SOC on an ICE FPGA: what peripherals are available?

[cdwijs]

Hi All,

I routinely use Arduino's based on AtMega microcontrollers to measure and control stuff. It's a nice platform, but it has it's limitations:
-Not enough instances of a peripheral. For some project I need more than one i2c port, to read out multiple sensors that are not available with unique addresses. For other projects, I would like to have more than one serial port.
-Missing peripheral. I would like to have a module that handles the timing and buffering for sending and receiving Manchester encoded data.
-Flexibility. Hardware peripherals are tied to specific pins, designing the PCB would be easier when pins can be moved around,

Therefore I would like to use a FPGA, so I can define the CPU and the peripherals I need, and have more flexibility.
For the FPGA:
There's the open source toolchain "IceStorm" that can be used to program Lattice ICE FPGA's.
https://en.wikipedia.org/wiki/ICE_(FPGA)#Open_source
https://web.archive.org/web/20160304202757/http://www.clifford.at/icestorm/

For the CPU:
there's an implementation of an RISC-V CPU called "picorv32" running in an ICE FPGA:
https://github.com/cliffordwolf/picorv32

And here the picorv32 is running on the tinyFPGA BX board:
https://gojimmypi.blogspot.com/2019/01/risc-v-on-fpga-tinyfpga-via-wsl.html

For the peripherals:
Picosoc provides an UART, RAM and SPI controller:
https://github.com/cliffordwolf/picorv32/tree/master/picosoc

This projects adds a driver for the WS2812 RGB LED (neopixel):
https://blog.adacore.com/ada-on-fpgas-with-picorv32

Do you know more projects that have made peripherals?
Cheers,
Cedric

[JPortici]

How about using a microcontroller that's not from the stone ages?
-a dsPIC33CK has three hardware I2C
-There is extensive remapping capability (not all pins, but plenty of pins)
-The CLC can help you with manchester encoding and decoding (there are app notes for that)
-The CLC can help you create a DMA-Enabled driver for WS2412 LEDs that needs very little CPU time (https://www.microchip.com/forums/m1091899.aspx) no idea how different it is to WS2812 but you get the idea
-FAST core
-FAST PWM and ADC, the 12bit ADC is 11.something effective bits
-doesn't cost too much

Still can't find a really fgood reason to go with FPGA

[ataradov]

I agree. All of the things you list are addressed in almost any modern MCU.

FPGA thing is much bigger step. So if you are afraid of complexity of the newer MCUs, then you should be REALLY afraid of going with FPGAs.

Also, those ICE40 FPGAa are very slow.

[iMo]

There is only one reason to go with the FPGA I would consider pretty important and challenging - to become an FPGA expert. Long way to go, however..

[woofy]

Also, those ICE40 FPGAa are very slow.

Relative to other FPGA's, yes I agree.
However to put some perspective on that, the HX can run RISC V at 50MHz and my own 16-bit processor at 100MIPs.

[ataradov]

However to put some perspective on that, the HX can run RISC V at 50MHz and my own 16-bit processor at 100MIPs.

Yes, I stand corrected. I mentally blocked HX series, since high density devices are only available in BGA and WLCSP packages.

[MorgothCreator]

Hey, I have developed an parametrized risc-five micro core with a parametrized interrupt controller, i have done twi, spi, uart, rtc, pio, paralel lcd, paralel lcd to hdmi adapter and a little gfx 2d accelerator.
The example projects are for xilinx  and lattice.
The core eat around 850 lut’s on both platforms, the speed is about 100 mhz on xilinx artix and around 40 mhz on MachXO3LF, but may vary with implementation.
The instruction pen mhz is around 0.8 M instructions per mhz
This core is a very very simple to wire in to the system.
Is open source at: https://git.morgothdisk.com/VERILOG

[Morgan127]

Instant SoC now supports Lattice FPGAs.
So for instance if you want three I2C you just add three I2C object in the C++ code and the compiler builds a system with RISC-V processor, memories and the peripherals you added.

An example using three I2C and 2 UART Tx:

Code: [Select]

#include "fc_io.h"
#include "fc_system.h"

int main()
{
//% hw_begin
    FC_IO_Clk clk(100);         // 100 MHz   
    FC_IO_I2C iic_1(400000);    // 400 kHz
    FC_IO_I2C iic_2(400000);
    FC_IO_I2C iic_3(400000);
    FC_IO_UART_TX uart_tx_1(115200);
    FC_IO_UART_TX uart_tx_2(9600);
//% hw_end
   
    uart_tx_1 << "Hello world using UART 1";
    uart_tx_2 << "Hello world using UART 2";

    for(;;)
    {
        // Add some c++ code...
    }
   
}

This will result in a VHDL file with the following port:

Code: [Select]

entity test is
    port(
        clk : in std_logic;
        iic_1_SCL : inout std_logic;
        iic_1_SDA : inout std_logic;
        iic_2_SCL : inout std_logic;
        iic_2_SDA : inout std_logic;
        iic_3_SCL : inout std_logic;
        iic_3_SDA : inout std_logic;
        uart_tx_1 : out std_logic;
        uart_tx_2 : out std_logic
    );
end entity;

[laugensalm]

If you're looking for standard peripherals like minimal UART, SPI, I2C etc. and building or simulating a uC/SoC in VHDL (only!), you might check out this one:

https://hub.docker.com/r/hackfin/masocist/

Currently, only neo430 (msp430 clone) and ZPU/ZPUng is supported, they tend to fit well into small FPGAs like the ICE40.
RISC-V-Support for the potato (https://github.com/skordal/potato) is on the way to be released in the next weeks. With the RISC-V you might run into code size issues though...

[SiliconWizard]

I agree. All of the things you list are addressed in almost any modern MCU.

Ditto. Considering switching to a pure FPGA platform before even considering the existing MCUs is mind-boggling actually. Not willing to start yet another war, but it just looks like some Atmega/Arduino users think no other MCU even exists on the market. Crazy.

Anyway, if you're going for a RISC-V core on FPGAs, do it for a good reason, not just to get features you can easily find in tons of existing current MCUs.

[brucehoult]

Hey, I have developed an parametrized risc-five micro core with a parametrized interrupt controller, i have done twi, spi, uart, rtc, pio, paralel lcd, paralel lcd to hdmi adapter and a little gfx 2d accelerator.
The example projects are for xilinx  and lattice.
The core eat around 850 lut’s on both platforms, the speed is about 100 mhz on xilinx artix and around 40 mhz on MachXO3LF, but may vary with implementation.
The instruction pen mhz is around 0.8 M instructions per mhz
This core is a very very simple to wire in to the system.
Is open source at: https://git.morgothdisk.com/VERILOG

Very cool! Congratulations!

The interrupt handling via x0 instead of the official CSRs is a bit .. weird.

[brucehoult]

Instant SoC now supports Lattice FPGAs.
So for instance if you want three I2C you just add three I2C object in the C++ code and the compiler builds a system with RISC-V processor, memories and the peripherals you added.

An example using three I2C and 2 UART Tx:

Code: [Select]

#include "fc_io.h"
#include "fc_system.h"

int main()
{
//% hw_begin
    FC_IO_Clk clk(100);         // 100 MHz   
    FC_IO_I2C iic_1(400000);    // 400 kHz
    FC_IO_I2C iic_2(400000);
    FC_IO_I2C iic_3(400000);
    FC_IO_UART_TX uart_tx_1(115200);
    FC_IO_UART_TX uart_tx_2(9600);
//% hw_end
   
    uart_tx_1 << "Hello world using UART 1";
    uart_tx_2 << "Hello world using UART 2";

    for(;;)
    {
        // Add some c++ code...
    }
   
}


Damn, that looks slick!

Peripherals needed extracted from the actual program that will be executed. And only instructions actually used by the program are included in the generated RISC-V core? Nice.  Although I'd bet not many are left out in practice -- maybe LH or LHU or something like that. There's not a lot of fat in RV32I.

[MorgothCreator]

Hey, I have developed an parametrized risc-five micro core with a parametrized interrupt controller, i have done twi, spi, uart, rtc, pio, paralel lcd, paralel lcd to hdmi adapter and a little gfx 2d accelerator.
The example projects are for xilinx  and lattice.
The core eat around 850 lut’s on both platforms, the speed is about 100 mhz on xilinx artix and around 40 mhz on MachXO3LF, but may vary with implementation.
The instruction pen mhz is around 0.8 M instructions per mhz
This core is a very very simple to wire in to the system.
Is open source at: https://git.morgothdisk.com/VERILOG

Very cool! Congratulations!

The interrupt handling via x0 instead of the official CSRs is a bit .. weird.

Yeah, I wanted to do something very simple for me at the time, some ideas and the IO's are ported from previous Xmega core project.
I implemented even compressed instruction set to eat even less resources, off course that the processor need an application to run, and that eat resources.
I will try to implement the interrupt controller via CSR's to see how much resources will eat.

I agree. All of the things you list are addressed in almost any modern MCU.

Ditto. Considering switching to a pure FPGA platform before even considering the existing MCUs is mind-boggling actually. Not willing to start yet another war, but it just looks like some Atmega/Arduino users think no other MCU even exists on the market. Crazy.

Anyway, if you're going for a RISC-V core on FPGAs, do it for a good reason, not just to get features you can easily find in tons of existing current MCUs.

Some people are more comfortable to use FPGA's for everything, now that they discovered them, FPGA's are more hardware flexible.
For example me...
When I started with FPGA's, I create two cores, one for Xmega and one Risc-V 32 CI and the principal peripherals and even some more complex.
Now everything I do, first I think for using a FPGA (except projects with power constraints and space constraints), are some FPGA's cheaper than a MCU's now, why not
The MCU's will slowly be deprecated  , I think, or will have some fabric inside them, look at IOT's that are hungry for such fabrics that work at very low frequencies and power and do some things without MCU interventions and push data inside a FIFO.
So developers need to familiarize with FPGA logic thinking, to work with both methodologies 
So, do the job done how you think you are more comfortable

[legacy]

paralel lcd

LVDS lcds?

little gfx 2d accelerator

can you tell me more about this?

[MorgothCreator]

paralel lcd: 8:8:8 or 5:6:5 RGB, like old 16/24 bit interfaces with H and V sync wires, signals that can bee feed directly to DVI, HDMI and other serializer IP's.

little gfx 2d accelerator: is an IP that accept commends to paint pixel, draw horizontal and vertical lines, and fill rectangles, at core clock speed (not LCD bus speed).

[rstofer]

The Teensy 4 has two I2C ports and 4 UARTs but one collides with one of the I2C ports.  So, minimum, 2 I2C and 3 UART.

The board is supported on the Arduino IDE and uses the Arduino library definitions (download Teensyduino to make things work).  It also runs at 600 MHz and has a Floating Point Unit (FPU).

https://www.pjrc.com/store/teensy40.html

[tolpe]

The MCU's will slowly be deprecated  , I think, or will have some fabric inside them, look at IOT's that are hungry for such fabrics that work at very low frequencies and power and do some things without MCU interventions and push data inside a FIFO.
So developers need to familiarize with FPGA logic thinking, to work with both methodologies 
So, do the job done how you think you are more comfortable

There's one more aspect: Full cycle accurate tracing/debugging of a software program down to the interface I/O. I would very much not mind having a hard core whose HDL is open for simulation with the possibility to select a set of peripherals. Like the PSoC family from cypress, but less proprietary and coming with the full opensource model. The only reason for going "hard" is that some deep sleep logic can't just be implemented in a soft core that easy (apart from the power saving aspects in general). It's probably not much a matter of taped out hardware, the paradigm shift will be required in software for everyone to use it (many coders are just not HDL affine).
I like the InstantSoc approach BTW, from the looks of it (haven't tried). Question is of course: how do you debug it when things go wrong.

[NorthGuy]

So developers need to familiarize with FPGA logic thinking, to work with both methodologies 
So, do the job done how you think you are more comfortable

It is certainly easier to do stuff in FPGA. The simple peripgerals in MCUs are getting increasingly complex. In FPGA, you can make your project much simple by using simple custom peripherals which do exactly what you need them to do, leaving out most of the extra stuff. Simpler projects will mean less bugs and more efficiency.

The only problem is the cost, and perhaps board complexity - for a good FPGA you will need several power rails etc. If you can do your project using $3 PIC without any external elements except for LDO, it's hard to justify FPGA,

[rstofer]

This PSOC6 chip as 13 Serial Communicaions Blocks which can each be configured as SPI, I2C or UART.

https://www.cypress.com/file/460816/download

Unless there was some compelling reason, I might rather use an MCU than an FPGA.  I like FPGAs and I think the LC3 RISC core is very useful even though it is nearly a minimal CPU.  It has an interrupt structure, DMA could be added, and you could define as many IO ports as you want.  But it's an advanced topic and there is quite a steep learning curve.  The project includes an assembler and C compiler so it is very useful.  You can buy the book "Introduction to Computing Systems" by Patt and Patel, new or used.  You can also find a lot of information in the Internet.  There is a newer project, LC3B, which adds byte addressing and operations.  A really fun project!  If you like hardware design...


PSOC programming has to be experienced to be appreciated.  Being able to plunk peripherals on a drawing and have the infrastructure create most of the code is simply awesome.  There are MANY videos about the PSOC 6 and they are worth watching.  It is a truly amazing MCU.

[rstofer]

The only problem is the cost, and perhaps board complexity - for a good FPGA you will need several power rails etc. If you can do your project using $3 PIC without any external elements except for LDO, it's hard to justify FPGA,

Or maybe plunk down a 'stamp' format board onto a custom daughter card:
https://store.digilentinc.com/cmod-a7-breadboardable-artix-7-fpga-module/

I would definitely go for the 35T variant.

There are other manufacturers of 'stamp' format FPGAs.  Maybe something like this:
https://www.ztex.de/usb-fpga-2/usb-fpga-2.01.e.html