IOTA Crypto Core FPGA — 5th Progress Report

MicroEngineer

5 min readJul 1, 2019

This is my 5th progress report. In case you missed the 4th: link

Milestone 4 is finished!

Architecture Update

Since the EDF proposal (back in December) the architecture changed a lot and has been extended.

For instance, it wasn’t planned to support full Linux or to have USB. But since the controller was swapped to a more secure one the technical specs changed — Faster, more RAM, more periphery.

The main task of milestone 4 was the development of a SoM which can be used for high-level applications. Also the SoM should directly work with the FPGA module from milestone 3.

Originally, the Application Controller was supposed to be something simpler for bare-metal* applications but was swapped to a more potent controller which has more and better security features. Additionally, it is faster, has more RAM and can run full Linux. This gives a lot of advantages —e.g. you don’t have to care about device drivers for complex periphery like ethernet, USB or Bluetooth.

It might surprise that not only the SoM-block is marked green but also most of the Application which actually was scheduled for the 5th milestone.

The reason is quite simple — the SoM only has connectors on the bottom of the PCB so it can be plugged on a board. But how to test it without a board where it can be plugged on?

In order to avoid another test-board, I decided to move the PCB design of the Gateway into the 4th milestone and to extend it with additional interfaces.

bare metal*: applications run directly on the hardware without operating system like Linux

Linux System Module

The heart of the SoM is the ATSAMA5D27 microcontroller from Atmel/Microchip. It has following the features:

Cortex A5 SoC with 500MHz, 128MB embedded DDR2 RAM, full Linux support
socket for the IOTA Crypto Core FPGA Module
8MB QSPI-Flash (on-the-fly encryption supported)
10/100MBit Ethernet
High-Speed USB Host + Device
µSD-Card interface
several interfaces (I2C, SPI, UART)
size of 83x36mm

The microcontroller supports a lot of security features. For instance, every part of the boot-chain can be signed and verified. Also, it supports on-the-fly hardware-encryption of the external QSPI Flash memory, so the Linux Kernel can be stored encrypted without losing system performance. It also has got an internal secure memory which can be wiped triggered by an external tamper detection pin. It has ARM’s TrustZone along with hardware cryptography, RSA/ECC, memory scrambling, independent watchdog, temperature, voltage and frequency monitoring and a unique ID in each device (Overview)

An additional advantage is the power consumption which is very low — below 1/2W operating at full speed. Atmel claims it is the lowest power consumption of all SoCs (system on chip) which can run full Linux. Combined with a PMIC (power management IC) it supports dynamic voltage scaling — that mean’s it can reduce its own core voltage in IDLE mode for even lower power consumption. It also supports several sleep-modes down to the µA range. An external interrupt or the RTC (real time clock) can wake it up.

It’s imaginable that this could open the door to a low-power and low-cost Bee node and become reference hardware for IOTA.

Gateway PCB

Originally, the Gateway should have been an example application for the Linux Module, but it got more features than planned.

A Gateway needs connectivity, so it got mobile internet (ublox sara g340), Wi-Fi, Bluetooth and 10/100MBit LAN. Also because there is a full Linux running on the SoM there also is an USB host and device connector on the Gateway PCB. Additionally, there is a Mini DIN connector on the board on which — in theory — a Lora Concentrator could be plugged on.

The last interface is a bit special because it is almost not used anymore. It’s IrDA. The main reason for putting IrDA on the board is that it can be used for easy, cheap and safe pairing of devices such as Lora sensors. A Lora sensor mostly consists of a Lora radio module and a microcontroller such as STM32. Although IrDA is not very common anymore the STM32 still support it directly. Only one active component (IrDA transceiver) is needed additionally.

So, the gateway could* support sensors

connected via Bluetooth
connected via Lora**
connected locally on SPI or I2C
connected via Ethernet/Internet (I know that’s lame^^)

*: not tested yet, because it’s part of milestone 5 :)
**: sadly, it’s not in the scope of the Ecosystem project

Documentation

Gitlab-Repository for the SoM: https://gitlab.com/iccfpga/iccfpga-som
Gitlab-Repository for the Gateway: https://gitlab.com/iccfpga/iccfpga-gateway
Main-documentation: https://gitlab.com/iccfpga/iccfpga-core/wikis/home

As always everything is licensed under MIT.

What comes next?

There are several tasks left which will nicely fill the coming 2 months^^

Linux Image and Kernel customizations (modem-manager for G3 and Wi-Fi, BlueZ for Bluetooth)
Development of a sensor (you won’t believe it … That’s been forgotten in the funding proposal)
Software for the SoM which receives sensor data and submits it to the Tangle.

Thank you very much for reading!