A small company designed and prototyped RISC-V ASIC in 30 days using Google’s sponsored eFabless open source shuttle

Using the open source shuttle provided by Google | eFabless, SH Consulting Co., Ltd. is trying to make a prototype of the system ASIC.

Title: RISC-V Microcontroller ASIC MARMOT

Owner: Shumpei Kawasaki

Organization URL: http://www.swhwc.com/

Summary: An application specific RISC-V microcontroller, MARMOT, was developed. MARMOT stands for a Microcontroller Autonomously Resistant to Malware, Obtrusions and Tampering. Its IPs were derived from the Rocket SoC generator and mated to the Sky130A Caravel Harness. A MARMOT ASIC design objective is to capture high-frequency sampling output of the analog-to-digital converter connected to the current sensor in power rails of IoT power supply. Captured data is stored as a waveform in external PSRAM. Its goal is to analyze dynamic power behavior to structure software so overall power consumption is minimized, to monitor physical and electrical health of the components, and finally to detect malware, hardware cloning, and hardware implants.

MARMOT ASIC

Figure 1 shows the chip layout of MARMOT ASIC. Marmot block in Figure 1 contains core complex and peripheral complex logic. 0_ext_ram01, 0_ext_ram0h, 0_ext_ram1l, 0_ext_ram1h, 0_ext_ram2l, 0_ext_ram2h, 0_ext_ram3l, 0_ext_ram3h shows the I-Cache data arrays. t_ram01 and t_ram0h show tag RAM. 

Figure 1. MARMOT ASIC

Figure 2. Block Diagram of Caravel and Rocket E31

The Rocket SoC generator generated Verilog RV32IMAC RISC-V with 16KB I-Cache, and an array of peripherals. The Rocket SoC generated logic was designed to mate to the Caravel harness and I-Cache was mapped to OpenRAM. The 8KB part of I-Cache can be used as Instruction Tightly Integrated Memory (ITIM), a RAM showing up in the address map.  ITIM can hold both instructions and data. The clock frequency seems limited to around 25MHz, slow but useful for many embedded applications. The Boot ROM implemented with logic gates jumps to the first address of SPI Flash. After that, a programmer can do what needs to be done executing from the program in SPI Flash. For example, change SPI Flash from the default Single SPI to Quad SPI and copy the routine to ITIM and jump to execution. 

Why was the Rocket SoC Generator used in the first place? 

Up to 70% of design and verification man-hours in chip design can be expended in connecting a CPU, QPI interface to flash memory, PSRAM, an array of UARTs, I2C and SPI in this case. Rocket SoC generator automatically generates a top level RTL derived from sub-circuit meta class definitions. Behind automatic SoC generation is the power of a new generation digital design language called Chisel. Chisel brings in software engineering, such as object-oriented and functional languages, into digital design. Chisel allows one to express hardware at the register-transfer level but allows one to write hardware generators. 

One Month with Rocket SoC Generator and OpenLane

The month of February in 2022 had 28 days. The project took exactly 30 days. 

Feb 25, 2022: A decision was made to participate in multi-project wafer five (MPW-5)

Feb 26, 2022: MARMOT ASIC wish list was created. 

Mar 16: Rocket SoC generation and logic simulation was complete. The OpenLane logic synthesis job threw an error in the middle. 

Mar 17: One other engineer attempted to reproduce the error but ended up seeing varying errors. A conclusion was made that the error was caused by memory deprivation. Two new desktop PCs with 64GB RAM were hastily purchased.  

Mar 19: OpenLane synthesis completed. Message shows the tool consumed 35GB of memory. Due to the scale of logic the Rocket SoC generator outputs and the way OpenLane logic synthesizer works, an excess of 35 GB of RAM was consumed. Several additional iterations were made to address the hold violations. Each run took 3 hours. OpenLane layout throws DRC errors. 

Mar 20: Slack #openlane and GitHub Issue communities offered generous and articulate tips. DRC errors were suppressed. LVS errors in a similar fashion were resolved. 

Mar 21: OpenLane routing tool threw “routing congestion” error but no further analytics. A way to get congestion area information was suggested but to no avail. The MPW-5 deadline mercilessly passed on Mar 22 in Japan time zone. 

Mar 27: After trial and error, a GDS was created. The design passed local precheck. 

Engineers kept day-time jobs and work took place after hours and weekends. Obviously more can be done. FPGA mockup of the design needs to be made to validate the design. 

Floor Plan and Automatic Routing

Chip floorplanning is the engineering task of designing the physical layout of a chip. Chip floorplanning requires effort by physical design engineers to produce layouts. 

 

 

Figure 3. Floor Plan Evolution

Initial floor plan in the left of Figure 3 was made initially. This was based on a “wish list.” While wiring clogs were anticipated we proceeded with the OpenLane digital design process but some wishes were removed as we made progress. 

 

Figure 4. MARMOT ASIC Wish List

 

A wish list was created. Wish list is frequently put to the side by management and engineers but believed to constitute a critical component of the project. Frequently original wishes include everything within itself and there are many possibilities. When the wishes descend on experts’ minds, possibilities are few. Sometimes judgements interfere with perceptions.

Why an RTOS rather than a Linux? 

Figure 5. Linux IoT vs. RTOS IoT, Functions and Power Requirements

Figure 5 shows advantages and disadvantages of Linux IoT and RTOS IoT. Linux IoT offers more functions, a standardized programming environment, and consistent linear programming memory space to ease programming. RTOS systems are segmented into multiple microcontrollers which complicates programming the device. On the other hand RTOS IoT may turn off parts of the systems not being used at the time. Linux IoT may hibernate but DRAM refresh draws power even when the system is hibernating. 

Figure 6. An IoT system example MARMOT ASIC is to be applied

Figure 6 shows an example IoT system. Endpoint and Gateway operate on a solar panel for years of duration untethered from permanent power supply. 

IoT Power Supply Unit

Figure 7. Power supply unit (PSU) example for RTOS IoT

A power supply unit (PSU) in Figure 7 receives power from  multiple sources e.g. solar, lithium-ion, variable DC voltage (e.g. 2.6V-20V), and USB-C. The PSU supplies 7 independent power rails, 6 of which can be turned on and off using I2C commands. The PSU is capable of measuring current flow in each of its power rails while the IoT is in operation. The measurement circuit was designed not to cause significant power loss when current measurement is not made. An IoT service provider needs to know when its IoT device is tampered, cloned, implanted. A remote power analysis of its IoT device can reveal some physical, structural and electrical breaches of the device such as cloning, implant, and malware.

Figure 8. RTOS IoT Power Rails in Block Diagram

Figure 8 shows an example system to which MARMOT ASIC is integrated with power rail descriptions. A discrete ADC achieves a higher sample rate than a standard microcontroller. Large sample data captured is stored in PSRAM e.g. 16MB.General purpose input and output (GPIOs) are expanded for crisscrossing reset and interrupt pins.

Figure 9. A Picture of an RTOS IoT

Figure 9 shows an example system for MARMOT ASIC.  Please note multiple wireless chipsets. These chips are connected to each other via UARTs for data / control exchanges. The UARTs are used not only for IoT applications but also for over-the-air firmware upgrade (OTA).  I2Cs are needed to interface sensors and root-of-trust (RoT) hardware. 

Figure 10. Icc and Vcc waveforms for 2G/3G/4G-LTE power rail

Figure 10 shows example waveforms from a  power line, current in yellow and voltage in blue, in this case from a LTE wireless chipset. After turning on the power and initialization process is complete, the processing that consumes power is performed every 30 seconds.

Conclusions

An idea of combining ASIC leveraging Rocket SoC generator and Caravel harness to arrive at a pragmatic microcontroller ASIC at the outset appeared golden and after spending hours it still does. Deeper investigation of technical approach is needed and hopes are high for expending more hours to articulate what can be materialized from those elements. 

Acknowledgements

This work is based on results obtained from project, JPNP16007, commissioned by The New Energy and Industrial Technology Development Organization (NEDO).