Abstract

In order to create a low-power and lightweight wireless sensor node for the control of MEMS microrobots, the Single Chip Mote project aspires to integrate a fully-functioning microprocessor, radio, sensors, and solar cells onto a single die, while also eliminating the need for external components through careful architectural design. This report presents the past two years of work on the design of the Single Chip Mote digital system, complete with an ARM Cortex-M0 microprocessor, control logic for an IEEE 802.15.4 radio, special-purpose radio timers, and ADC interface. This includes details on the design and contents of the Verilog code used to describe the hardware, and the software written to run and test the Single Chip Mote digital system. The required tools and testing procedures are also explained, along with the details required to convert this FPGA-based design to an ASIC design ready for tapeout. The intention behind this report is to pass on the knowledge acquired throughout the course of this project to those who are working to improve and
iterate on this design. This report also presents preliminary power, area, and timing characteristics for the ASIC version Single Chip Mote digital system.

Chapter 1: Introduction

• The term “Smart Dust” was originally coined by Professor Kris Pister to describe low-cost, low-maintenance, and unobtrusive wireless sensor nodes on a micro scale.

• These motes form interconnected mesh networks to communicate with one another and transmit sensor information.

Wireless Sensor Nodes and the Internet of Things

• The recent rise in the popularity of the Internet of Things (IoT) has fueled the demand for consumer-quality wireless sensor node devices.

• The wireless standards used in laptops and cell phones such as WiFi and LTE are too power-hungry to be used on small wireless sensor nodes.

• Bluetooth Low Energy is appealing due to its compatibility with laptops and cell phones, at the cost of the
  associated licensing fees. It also does not support the creation of mesh networks.

• IEEE Standard 802.15.4, entitled Low-Rate Wireless Personal Area Networks (LoWPAN), is also a popular choice since it defines the PHY and MAC layers underlying many other protocols commonly found on commercial motes. This standard is designed specifically for short-range, low-power, and low-data-rate application, and does not require licensing.

• The OpenWSN project aims to create an open-source implementation of the complete protocol stack for IoT wireless sensor nodes with 802.15.4 radios. OpenWSN is compatible with a variety of software and hardware platforms, allowing different motes to communicate with one another and form mesh networks.

When Small is Not Small Enough (previous work)

1. Many of the commercially-available general-purpose motes are certainly capable of running OpenWSN and other applications within a mesh network. While these motes are small, the weight of the battery and PCB itself makes them too large and heavy to be used for microrobotic control and communication. Without the benefit of energy harvesting, these motes also need to have their batteries replaced every few days or perhaps weeks. Examples of these motes include the TelosB and OpenMote-CC2538, both with OpenWSN support [14].

2. Research projects involving low-power motes tend to focus more on cramming commercial hardware onto tiny PCBs than in new embedded architectures for low-power applications. The designs presented in [27], [28], and [7] are coin-sized, low-power, and unobtrusive motes optimized for infant observation, energy sensing, and transportation monitoring. Given the simplicity of their microprocessors, these motes are not able to implement a complex protocol stack for mesh networks. [27] and [7] also require their own base stations to communicate with the motes, whereas motes using IEEE 802.15.4 radios can communicate with any other mote or base station with an 802.15.4 transceiver. While these designs
   succeed in lowering energy consumption, they still require batteries that may only last for a few weeks, and the combination of the PCB and battery is still too heavy for a microrobot.

3. The authors of [18] claim to have developed the world's smallest wireless sensor node by designing a custom IC for their signal processing and data transmission. The custom IC die is directly bonded to a MEMS die containing all of the required sensors. The mote uses solar cells in combination with a rechargeable battery for longer battery life. This mote is small, lightweight, and has minimal external components. However, the major downside of the design in [18] is the lack of a general-purpose microprocessor, as it is designed for the sole purpose of sampling and transmitting data.

4. Perhaps the best attempt thus far towards full integration is the Michigan Micro 10Mote [20]. With as many as eight different layers containing the microprocessor, radio, sensors, and other components, the mote measures at just 2×4×4mm , and has an incredibly low standby current of 2nA. The mote can be powered completely via ambient light through its solar cells, and contains a battery layer to store any excess harvested energy. The only potential downside to this design is the increased complexity when manufacturing, aligning, and bonding eight different dies.

5. Finally, the 24/60GHz passive radio designed at Berkeley [31] proves that a low-power radio relying entirely on energy harvesting is possible on a single die. Unfortunately, the chip behaves more like an
   RFID tag instead of an autonomous computer. As a result, two of these radios cannot directly communicate with one another, and are not well-suited for forming a network of microrobots. Also, both the 24GHz receiver and 60GHz transmitter are not compliant with any current IoT standards.

Single Chip Mote to the Rescue

• The high-level block diagram in the figure below shows the various subsystems that must be integrated onto a single die in order for this project to succeed.

• The Single Chip Mote is the ideal microcontroller for the future swarms of autonomous microrobots, each with a lightweight yet fully-capable brain for performing actions beyond the simple observe and report.

• The addition of the OpenWSN protocol stack allows for these robots to create an extensive and adaptive
  mesh network, and communicate with a variety of IoT hardware platforms and sensors supporting OpenWSN.

Single Chip Mote Digital System

• A tested and functioning FPGA prototype of the Single Chip Mote digital system complete with an ARM Cortex-M0 microprocessor, radio controller, custom radio timer, and ADC interface is presented, along with the tools and procedures for designing hardware, writing software, and verifying functionality.

• A high-level block diagram of the Single Chip Mote digital system is shown below. This is far from the final iteration of the Single Chip Mote digital system; the design lacks support for integrated sensors, periodic sensing without intervention from the microprocessor, power management and low-power modes, and other potential hardware accelerators to handle repetitive and energy-consuming tasks normally executed in software.

• As an example of hardware acceleration, OpenWSN uses hardware timers to wake up the microprocessor for each step involved in sending a packet over the radio. The current Single Chip Mote digital system has custom timers designed to automatically trigger the actions required to send a packet without waking up the microprocessor, and the overall process requires less energy than a traditional microcontroller.

Preliminary Results

• Preliminary results already show the potential for improvement when using the Single Chip Mote in place of existing wireless sensor nodes. The technology used for the complete design is TSMC 65nm LP, with a clock frequency of 5M Hz and an operating voltage of 1.2V.

• The main reason for the improvement is most likely due the use of the 65nm LP processes.

• The Single Chip Mote digital system also has significantly fewer on-chip peripherals than the MSP430 or CC2538, reducing both dynamic and leakage power.

• Area is also an important consideration, since this chip must be light enough to be carried by a MEMS microrobot. The preliminary design for the Single Chip Mote digital system has a total cell area of 856600µm², which easily fits within a die area of 1mm² . Assuming an incident power of 1mW per mm² in direct sunlight, CMOS solar cells with at least 10% conversion eficiency should be able to provide 100µW per mm² of die area in direct sunlight. Therefore, this design (when run with an operating voltage 0.9V ) requires approximately 1mm² of solar cells to power the Single Chip Mote digital system. It is estimated that the analog, radio, and voltage converters for the Single Chip Mote will require 2mm² of area for the circuits themselves, and 2mm² of area for additional solar cells. With these numbers in mind, the Single Chip Mote requires a total die area of 6mm².

• Given that the thickness of the die is about 200µm, and the density is similar to that of crystalline silicon (2.33g/cm³), the estimated mass of the die is 2.8mg .

• Researchers in our group are currently designing MEMS motors and legs for walking microrobots. Each leg outputs a downward force of 300µN , and can move a mass of 30mg . The mass of the legs themselves are 15mg each, which allows for 15mg of payload per leg. With these values in mind, a one-legged MEMS microrobot generates enough downward force to support the weight of the Single Chip Mote.

Report Outline

• Chapter 2 provides an overview of the tools for hardware development for the FPGA and software
  development for the Cortex-M0 microprocessor, including the basics of their installation and use.

• Chapter 3 contains a detailed explanation of the Single Chip Mote digital system hardware.

• Chapter 4 demonstrates how to write software that uses the hardware peripherals.

• Chapter 5 covers the details on loading software onto an FPGA or ASIC containing the Single Chip Mote digital system.

• Chapter 6 describes the current testing procedures, including simulation and real-time verification.

• Chapter 7 details the changes required to convert the Single Chip Mote digital system from an FPGA design to an ASIC design.

• Chapter 8 concludes this report with a discussion the accomplishments of this project and areas for improvement.

Chapter 2: Getting Started

Git Repository

All of the source code and project files for this design is found on the following git repository: https://repo.eecs.berkeley.edu/git/projects/pistergroup/scm-digital.git

The repository contains two main directories, one for source code and one for project files specific to the hardware and software development environments:

• The source code section further divides into hardware and software code, and each of
  those sections divide further based on FPGA target or software project.

• The project files directory is also divided into sections for hardware and software IDEs, and each
  of those sections also divide further based on FPGA target or software project.

There is also a deprecated repository containing the history of the project during its early development: https://repo.eecs.berkeley.edu/git/projects/pistergroup/singlechip-digital.git

ARM Cortex-M0 DesignStart Processor

The ARM Cortex-M0 DesignStart processor is fully software-compatible with the commercial Cortex-M0; however, the provided Verilog is obfuscated and does not support JTAG debugging.

FPGA Boards

• The Digilent Nexys 3 is a digital circuit development platform containing the Xilinx Spartan-6 XC6LX16-CS324 FPGA along with various peripherals.

• The Digilent Nexys 4 DDR is a digital circuit development platform containing the Xilinx Artix-7 XC7A100T-1CSG324C FPGA along with various peripherals.

• The digital system of the Single Chip Mote was originally designed and developed on the Nexys 3 FPGA, and then was moved to the Nexys 4 DDR board.

Hardware Development Tools

Xilinx ISE Design Suite 14.6

Xilinx ISE 14.6 is the integrated development environment used for the hardware development of the Single Chip Mote on both the Artix-7 and Spartan-6 FPGAs, this version of ISE can be download directly from Xilinx.

Additional Install Directions for Xilinx are required for Windows 8/8.1/10

Synthesizing a Design and Loading a Bitstream:
In the pdf, detailed instructions demonstrate how to synthesize a design in Project Navigator and load the resulting bitstream onto an Artix-7 FPGA (on the Digilent Nexys 4 DDR board) using iMPACT.

Digilent Adept

Digilent Adept is a utility provided by Digilent that can be used to load bitstream files onto some of their FPGA boards. Adept is used to program the Nexys 3 board but does not support the Nexys 4 DDR.

Xilinx Vivado Design Suite

The Vivado Design Suite can be used for designs on the Artix-7 FPGA. Xilinx and Digilent are providing increasing support for Vivado and decreasing support for ISE.

Software Development Tools

Keil uVision5

Keil uVision5 is an IDE used for developing software running on ARM microprocessors. This IDE is part of the ARM MDK 5 Microcontroller Development Kit.

The uVision project file has an extension .uvprojx.

To compile code for the ARM Cortex M0 on the Single Chip Mote, open an existing project in Keil uVision5. Then go to the Project menu and select Build Target. This compiles the code, creates a C binary image called code.bin, and also creates a text file called disasm.txt, containing a disassembled version of the code. The C binary image is loaded into the instruction memory of the Single Chip Mote on an FPGA using the bootloader.

Bin2coe

Bin2coe is a small Windows executable used to convert C binary image les (bin) to COE files used by Xilinx to initialize FPGA memories. COE files are used to initialize the instruction ROM with software written and compiled in Keil. This is used for the bootloading ROM on the Single Chip Mote. This program limits the data widths of the COE file to 32 bits, and therefore the generated COE files are limited to memories with a width of 32 bits.

Chapter 3: Single Chip Mote Hardware

This chapter provides a detailed overview of all the hardware components of the Single Chip Mote digital system. The Single Chip Mote hardware encompasses all of the Verilog files, Verilog header files, and ISE project files used to describe the Single Chip Mote digital system.

Some of the files and designs described in this chapter are provided by ARM with the Cortex-M0 DesignStart kit, such as the Verilog for the Cortex-M0 and AHB controllers for various peripherals on the Nexys 3 board.
There are also Verilog modules designed by Francesco Bigazzi, such as the bridge between AHB and APB, and some of the APB peripherals. All other work described in this section not attributed to ARM, Bigazzi, or any other designer is original.

ISE Project Settings

ISE projects have already been created for the Single Chip Mote digital system on the Artix-7 and Spartan-6, as well as the bootload hardware for the Spartan-6. However, it may be necessary in the future to make more ISE projects for additional FPGA designs, such as running the bootload hardware on the Artix-7.

This section contains the information needed to:

• create a new ISE project for the Artix-7 FPGA on the Nexys 4 DDR board

• create a new ISE project for the Spartan-6 FPGA on the Nexys 3 board

User Constraints File:

• All ISE projects require a User Constrains File (UCF) in order to map the top module's IOs to the pins on the FPGA package.

• Given that the FPGAs are soldered onto boards designed by Digilent, not all of the available pins on the package are routed to pins accessible on the Digilent boards.

• While generic UCF files for the Spartan-6 and Artix-7 FPGAs exist (or are generated using Xilinx tools), Digilent provides master UCF files for their Nexys 3 and Nexys 4 DDR boards listing only the pins that are accessible through one of the various connectors on the boards.

• These UCF files provide net names and descriptions in the comments of each line to describe how each of the actual FPGA pins map to a physical connector on the board.

• Digilent also publishes the schematics of their boards, containing the same information as the UCF file comments in a visual form.

Digital System Architecture Overview

The figure above contains a block diagram of the top module of the Single Chip Mote digital system, uCONTROLLER, along withs its inputs and outputs to/from the other parts of the Single Chip Mote, such as the analog/RF circuits.

The Single Chip Mote digital system consists of:

• One ARM Cortex-M0 DesignStart processor connected to various peripherals through a hierarchy of buses.

• These peripherals include instruction and data memory, a radio controller, a radio timer, an ADC controller, a UART transmitter and receiver, analog conguration registers for the radio, and general-purpose digital inputs and outputs.

• The PON (short for Power-ON) module contains all of the hardware to generate the clocks and handle resets. This module is only required for the FPGA version of the Single Chip Mote digital system. On an ASIC, it is assumed that an external analog circuit handles the generation of all clock and reset signals.

• The AHB-Lite is a 32-bit bus used by the ARM Cortex-M0 to connect to memory and peripherals. The main AHB-Lite bus is composed of two modules, AHBDCD and AHBMUX. This bus has 1 master, the ARM Cortex-M0 and 5 slaves:

  • the instruction memory (AHBIMEM),

  • another AHB-Lite bus (through the arbiter AHBLiteArbiter_V2),

  • the direct memory access controller (DMA_V2),

  • the radio timer (RFTIMER),

  • and an APB bus.

• The second AHB-Lite bus is designed to have two masters (using the AHBLiteArbiter_V2 module as an arbiter) and two slaves:

  • the data memory (AHBDMEM) and

  • the radio controller (RFcontroller).

• This structure was chosen because the two slaves need to be accessed by both the Cortex-M0 and the DMA. The DMA is used to automatically transfer radio packet data between the radio controller and the data memory without any intervention from the Cortex-M0. The first AHB-Lite bus is referred to as the
  AHB. The second AHB-Lite bus is referred to as the AHBsub.

• The APB is a 16-bit peripheral bus used to access peripherals that do not require the full 32-bit data size or the low latency of the AHB-Lite. The APB is connected to the AHB-Lite using the AHB2APB module designed by Bigazzi. The bus itself is composed of the APBMUX module designed by Bigazzi. This bus has four slaves:

  • the ADC controller (APBADC_V2),

  • the UART transmitter/receiver (APBUART),

  • configuration registers for the analog circuits of the Single Chip Mote (APB_ANALOG_CFG),

  • a small set of digital inputs and outputs (APBGPIO).

For more information on the AHB-Lite protocol, the APB protocol, and each of the modules mentioned above, see the rest of this chapter. The remaining subsections are as follows:

• ARM Cortex-M0 Memory Map Specification

  • All Cortex-M0 designs have 4GB of address space used to access either actual memory or memory-mapped peripherals. Each address refers to a single byte in the memory; however, in certain regions
    of the memory map, the ARM Cortex-M0 DesignStart processor only allows word-aligned accesses.

• AMBA 3 AHB-Lite Protocol

  • Each bus transfer requires two phases, the address phase and the data phase. In the address phase, the master sets the HADDR, HWRITE, HTRANS, and other relevant signals. The next cycle is the beginning of the data phase, where the slave sets HRDATA (if the transfer is a read), performs a write (if the transfer is a write) and sets HREADYOUT if the transfer is complete. The slave can stall the master by leaving HREADYOUT low.

• AMBA 3 APB Protocol

  • Each bus transfer requires two phases, the setup phase and the access phase. The first clock cycle is the setup phase, where PADDR, PWDATA, and PWRITE are set by the master. During the second clock cycle, the PENABLE signal is asserted to indicate that it is now the access phase. The transfer completes once PREADY is high.

• Header Files and Parameters

  • The Verilog for the Single Chip Mote digital system contains two header files:

    • SYS_PROP.vh: it contains define statements used to tweak module parameters (such as the baud rate for APBUART or the number of outputs in APBGPIO).

    • REGISTERS.vh: it contains define statements used to assign addresses to peripherals on the AHB and APB and each of their registers.

• Module Hierarchy

• uCONTROLLER

  • uCONTRLLER (found in TOP_SYS.v) is the top module of the Single Chip Mote digital system. It instantiates the Cortex-M0, power-on moudle, the AHB/APB peripherals, and the AHB/APB busses.

  • uCONTRLLER is used to connect all other modules to one another and to the inputs and outputs of the design as a whole. It contains the instantiations of all the other modules, and declarations for the wires connecting these modules. Any new buses or peripherals must be instantiated in this module.

• CORTEXM0DS

  • This module, provided by ARM in the DesignStart kit, is an interface between the Verilog describing the ARM Cortex-M0 DesignStart processor (in cortexm0ds_logic) and the rest of the system.

• cortexm0ds_logic

  • This module, provided by ARM in the DesignStart kit, contains the obfuscated Verilog describing the ARM Cortex-M0 DesignStart processor. This module is instantiated only in CORTEXM0DS and must not be instantiated by any other module in the design. This module must not be modied.

• PON

  • This module is designed to handle all of the clock and reset signals in the Single Chip Mote digital system.

• pb_debounceRESET

• ClockDiv

• AHBDCD

• AHBMUX

• AHBLiteArbiter_V2

• AHBDCDsub

• AHBMUXsub

• AHBIMEM

• instruction_ROM

• instruction_RAM

• AHBDMEM

• dmem_ram

• DMA_V2

• RFcontroller

• tx_fifo2

• rx_fifo

• spreader

• symbol2chips

• corr_despreader

• correlator

• bit_sync

• bus_sync

• crcParallel

• RFTIMER

• compare_unit

• capture_unit

• AHB2APB

• APBMUX

• APBUART

• APBADC_V2

• APB_ANALOG_CFG

• APBGPIO

• chipscope_debug

• Deprecated Modules

Important terms

• MEMS microrobot: micro-electro mechanical system microrobot

• ISE: Integrated Synthesis Environment

• AHB: Advanced High-performance Bus

• APB: Advanced Peripheral Bus

Google search

• Verilog, standardized as IEEE 1364, is a hardware description language (HDL) used to model electronic systems.

Review

1. 1 word= 16 bits

2. Copied from: https://openwsn.atlassian.net/wiki/spaces/OW/overview

Protocol Stack

The standards under development most applicable for the Internet of Things are:

• The IEEE802.15.4e standard defines MAC amendment to the existing IEEE802.15.4-2011 standard. One mode, called Time Synchronized Channel Hopping, significantly increases robustness against external interference and persistent multi-path fading, while running on legacy IEEE802.15.4 hardware.

• The IETF 6TiSCH working groups standardizes mechanisms of running an IPv6-enabled protocol stack on top of IEEE802.15.4e TSCH.

• The IETF 6LoWPAN working group has standardized a mechanism for an IPv6 packet to travel over networks of devices communicating using IEEE802.15.4 radios; this includes header compaction techniques to fit long IPv6 headers into short IEEE802.15.4 frames.

• The IETF ROLL working group has standardized the RPL routing protocol, i.e. the distributed algorithm which finds the multi-hop path connecting the nodes in the network with a small number of destination nodes.

These standards can be layered one on top of another, forming the following protocol stack: