SoC Design

Official rules to not say anything at all about the SoC design or required infrastructure, this information has to be gathered from the overall requirements.

Complete list of minimal SoC requirements per rules

Resource	Requirement
User IO	1 LED * note 1
Code memory	>16K # note 2
Data memory	tbd
Total Memory	32KByte * note 3

Note 1: On Microsemi we could even forget the LED and say that SmartDebug should be used to monitor the SoC output, this would be valid by the rules.

Note 2: Dhrystone compiled with -march=rv32i -mabi=ilp seems to produce over 16K, RV32IM may go just below 16K, Philosophers is over 16K

Note 3: Minimum total/shared memory footprint is 32KByte when using power of 2 numbers.

User IO

From minimum requirements a complete design with "some" Zephyr application must be provided to be able to run on the selected FPGA target board. This could be Zephyr Blink LED as the rules do not say that Philosophers or Synchronization FPGA images have to be supplied. This would allow Zephyr testing on the first board suggested by the rules

http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCE40UltraPlusBreakoutBoard

that board has no console so only user IO is a LED, this would be all that is needed.

So if we take the rules very strictly then the minimum requirement for user IO is single LED. We can always emulate UART console by sending Morse code to the LED. This would be acceptable by the rules. We can also blink the RV32I compliance test signatures using Morse code, this would be acceptable as well.

You could connect upper bit of program counter to LED and let the address decoder to wrap (mirror code space), this would give an almost 0 LUT LED GPIO.

Memory

We must provide enough memory to boot Dhrystone, Philosophers and Synchronization applications. We are a bit constrained by the rules in the regard of Dhrystone compiler and library optimization, but for Zephyr we can take all measures we want to decrease the memory requirement. From the compiler results so far it does not seem possible that those applications compile into total memory footprint under 16K Byte. The actual minimum code+data is less than 32K in all cases. This amount of memory must be accessible to the CPU.

We could make a case saying that the SoC runs on FPGA only Zephyr Blinky as required by the rules, and boots other tests and applications in verilator only with increased memory footprint as Philosophers boot is required on the SoftCPU only by the rules and not directly on the target FPGA board. But this is really narrow path better not be taken, so we should better have the same amount of memory in the FPGA implementation and verilator.

SoC boot Microsemi

Options for Application boot:

Type	Bootstrap location	preferred for
UART bootloader	LUTROM	fast
SPI bootloader	LUTROM	fast
eNVM bootloader	LUTROM	fast
XiP from SPI Flash	none	small only
XiP from eNVM	none	small only
SRAM init from eNVM	FPGA logic FSM	fast
Cortex-M3 assisted boot	eNVM/eSRAM	fast/small

LUTROM BOOTROM issue - as Microsemi Smartfusion2 and IGLOO2 do not include any FPGA fabric memories with init function then any ROM memory in the FPGA would be implemented as LUTROM. As per rules those ROM LUT's would count as used resourced.

As a workaround SmartDebug could be used to init BOOTROM inside LSRAM. It would not be very fun to boot the SoC that way over SmartDebug GUI, but it would be acceptable by the rules.

SoC boot on Lattice

Options for Application boot:

Type	Bootstrap location	preferred for
UART bootloader	EBR	fast/small
SPI bootloader	EBR	fast/small
XiP from SPI Flash	none	small only
Multi-boot	previous bitstream	fast/small

Placing all code in EBR is not an option as the total EBR memory in UP5K is less than 16K and we need more than 16K to start Dhrystone. So we must provide either a bootloader or execute in place from external SPI flash.

Both bitbang UART and SPI bootloader would fit into single EBR (but using only one EBR would require 2 clock cycles to fetch from memory).

Note: Unless you are using UART bootloader option you need to support boot or execute in place from external SPI Flash. Also build instructions are needed to create the image for the external flash instructions how to program the flash with the bitstream and merged CPU code.

The ultimate lowest resource usage would be when using multiboot where one bitstream loads SPRAM and forces reboot from RISC-V bitstream leaving SPRAM content unmodified.

Peripherals

As a minimal requirement for peripheral devices is single bit output only GPIO used for LED. For UART transmit only is acceptable (unless you use UART bootstrap). UART could be bitbanged using GPIO. This GPIO could be implemented as memory mapped register (using custom instruction for GPIO also acceptable).

Memory mapped peripheral list (minimal)

Register	Width	Note
GPIO OUT	1 WO	for bitbang UART
RISCV_MTIME_BASE	64 RW	counter
RISCV_MTIMECMP_BASE	64 RW	counter compare reg

Additional GPIO bits or peripherals may be needed depending on the boot option. UART Peripheral may of course be included - in that case proper Driver is needed for Zephyr and the LUT used would be counted for total resources used.

Interrupts

To fully pass RISCV compliance and Zephyr requirements external interrupts and full PLIC are not required. It is sufficient if machine timer interrupt is implemented, this requires two 64bit memory mapped registers to be present to arm the machine timer.

Addresses to those registers should be defined in soc.h for your cpu, for engine-V as example it would in zephyr tree

https://github.com/micro-FPGA/zephyr/blob/v1.13-branch/arch/riscv32/soc/riscv-privilege/ev/soc.h

/* Timer configuration */
#define RISCV_MTIME_BASE             0xE000
#define RISCV_MTIMECMP_BASE          0xD000

Zephyr core will not access any other memory mapped registers than those two.