Open

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.

Open

High-level block diagram of the Single Chip Mote and its subsystems

• 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.

Open

High-level block diagram of the Single Chip Mote digital system

• 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 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

  • This module is used to debounce the output signal from a button on the FPGA board used as the reset input to the Single Chip Mote digital system.

• ClockDiv

  • This module was originally designed by Bigazzi to divide the 100MHz input clock down to 5MHz. This module has since been parameterized to divide a clock down by any amount and is currently used to divide the 100MHz clock to 2MHz and 500kHz.

• AHBDCD

  • This module is used to determine which AHB slave is being accessed during an AHB transfer.

• AHBMUX

  • This module, is used to select the correct set of AHB slave signals (HRDATA and HREADYOUT) from the APB slave being accessed during the current transfer. The slave signals are chosen based on the MUX_SEL signal (Input from AHBDCD indicating which AHB slave is selected for the current transfer).

• AHBLiteArbiter_V2

  • This module is an arbiter designed to allow for two masters to share a single AHB-Lite bus. This module is necessary in order to allow the Cortex-M0 and the DMA to both access the data memory and the radio controller via the AHBsub bus.

• AHBDCDsub

  • This module is the same as the AHBDCD module. The main difference is that this module is designed to be used for the AHBsub bus and has two slaves: the AHBDMEM module and the RFcontroller module. Also, the width of the MUX_SEL signal is reduced.

• AHBMUXsub

  • This module is the same as the AHBMUX module. The main difference is that this module is designed to be used for the AHBsub bus and has two slaves: the AHBDMEM module and the RFcontroller module. Also, the width of the MUX_SEL signal is reduced.

• AHBIMEM

  • This module provides access to the instruction memory for the Cortex-M0. The instruction memory is composed of a 16kB ROM and a 64kB SRAM (instruction RAM).

• instruction_ROM

  • This module is a 16kB read-only memory constructed out of FPGA primitives using CORE Generator. This ROM is initialized with a COE file containing the compiled binary C code for the bootloading firmware.

• instruction_RAM

  • This module is a 64kB simple dual port SRAM constructed out of FPGA primitives using CORE Generator.

• AHBDMEM

  • This module provides access to the data memory for the Cortex-M0. The data memory is composed of a 64kB SRAM. This module is based on the AHB2MEM module provided in the ARM Cortex-M0 DesignStart kit.

• dmem_ram

  • This module is a 64kB simple dual port SRAM constructed out of FPGA primitives using CORE Generator.

• DMA_V2

  • This module is the interface between the RFcontroller module and the data memory in the AHBDMEM module. This module copies packet data from the data memory to the RFcontroller for packet transmission, and also copies received packet data from the RFcontroller to the data memory. This module operates independently without any intervention from the Cortex-M0, allowing for packets to be autonomously sent and received when the Cortex-M0 is sleeping.

• RFcontroller

  • This module is the interface between the Single Chip Mote digital system and the radio circuit. This module is responsible for both transmitting (TX) and receiving (RX) packets using the IEEE 802.15.4 standard.

    • The three finite state machines (RX,TX, mode select) are implemented in the RFcontroller module

    • the TX FIFO is implemented in the tx_fifo2 module

    • the RX FIFO is implemented in the rx_fifo module

    • the spreader is in the spreader module

    • the correlator/despreader is in the corr_despreader module

    • the RF circuit is the radio circuit on the Single Chip Mote

  • The RFcontroller module requires three separate clock domains in order to properly interface with the radio circuit. The Single Chip Mote has:

    • a 2MHz source for transmitting packets called CLK_TX

    • a separate 2MHz clock for receiving packets called CLK_RX.

    • the 5MHz system clock HCLK for the control registers and the finite state machines

  • The RFcontroller module relies on the DMA_V2 module to transfer packet data to and from the data memory. The DMA_V2 module is capable of reading and writing to the RFcontroller via the AHB bus. This is because the DMA_V2 module has an AHB master interface, and this interface shares the AHBsub bus with the Cortex-M0.

• tx_fifo2

  • This module is an asynchronous, asymmetric FIFO designed to store packet data waiting to be transmitted in the RFcontroller module.

    • This module is asynchronous since it has two different clock inputs for reading (2MHz CLK_TX) and writing (5MHz HCLK),

    • and is asymmetric since the read data width (4 bits) and write data width (8 bits) are different.

• rx_fifo

  • This module is an asynchronous, asymmetric, first word fall through (FWFT) FIFO designed to received packet data in the RFcontroller module.

    • This module is asynchronous since it has two different clock inputs for reading (5MHz HCLK) and
      writing (2MHz CLK_RX),

    • and is asymmetric since the read data width (8 bits) and write data width (4 bits) are different.

• spreader

  • This module is part of the TX state machine in the RFcontroller module. This module reads packet data out of the tx_fifo2 module 4 bits at a time, where each set of 4 bits is called a symbol. This module converts each symbol into to a series of 32-bit chips, also referred to as OQPSK codes, outputted serially to the radio circuit, via the tx_dout output of the top module.

  • The method of modulation used in the radio for the Single Chip Mote is called MSK. The MSK modulator generates a radio signal equivalent to one generated by an OQPSK modulator.

• symbol2chips

  • This module contains the combinational logic needed in the spreader module to convert 4-bit symbols to two 16-bit sets of chips for radio packet data transmission. Each symbol has one set of chips called I and one set called Q. This module uses the OQPSK_I_CODE and OQPSK_Q_CODE values defined in chips.vh to map each symbol to a series of chips.

• corr_despreader

  • This module reads the incoming data from the radio circuit in order to detect a received packet and store the data in the RX FIFO. The incoming data is a series of frequency shifts encoded into a serial binary data stream. These frequency shifts are determined using a demodulation circuit, and the Single Chip Mote uses a method of demodulation called MSK. The bits in the stream are called chips, and sets of 32 chips correspond to 4-bit sets of actual data called symbols.

• correlator

  • This module instantiates the correlator submodule to find the symbol that is the closet match to the current set of chips, as well as quantify the ‘closeness’ of that match. The ‘closeness’ of a match is defined as the Hamming Distance.

• bit_sync

  • This module synchronizes a signal from a slower clock domain to a faster one. In particular, the fast clock samples the signal from the slow clock, and outputs a single-cycle (according to the fast clock) pulse when a rising edge is detected.

• bus_sync

  • This module synchronizes a bus from a slower clock domain to a faster one. In particular, this module behaves somewhat like a FIFO with a depth of 1. The slow clock writes to the bus_sync module. The written data is copied into another register using the fast clock, and a valid signal is asserted. The faster clock then asserts its read enable signal to indicate that it read the data, and the valid signal
    is de-asserted.

• crcParallel

  • This module is used by the RFcontroller module to calculate the cyclic redundancy check (CRC) value of a radio packet conforming to the IEEE 802.15.4 standard.

• RFTIMER

  • This module is a special-purpose timer designed to interface with the RFcontroller module.

  • The timer itself is a counter connected to the CLK_RFTIMER clock with a frequency of 500kHz.

  • With the correct combination and configuration of compare and capture units, the Single Chip Mote is able to send packets or listen for incoming packets at specific times without any intervention from the software on the Cortex-M0 beyond the initial setup.

  • This module is also suitable as a timer for purposes other than sending or receiving packets.

• compare_unit

  • This module is part of the RFTIMER module, it stores a compare value and generates interrupts when the value of the counter from the RFTIMER module matches the compare value.

  • One of the interrupts is for the Cortex-M0, and the other four are triggers for the state machines inside the RFcontroller module.

  • The interrupt and trigger outputs from this module are synchronous with the timer clock (TCLK).

• capture_unit

  • This module is part of the RFTIMER module, it monitors several interrupts, and stores the value of the counter from the RFTIMER module when one of those interrupts is asserted.

  • One of these interrupts comes from the Cortex-M0 via the AHB, and the other five come from the RFcontroller module.

• AHB2APB

  • This module is designed by Bigazzi to act as a bridge connecting the AHB and the APB buses. This module is the master of the APB bus, and creates all of the APB master signals sent to the APBMUX and all APB slaves.

• APBMUX

  • This module is designed by Bigazzi to determine which APB slave is being accessed and route the correct set of slave signals to the APB master.

• APBUART

  • This module is a slightly modified version of the AHBUART module provided in the DesignStart kit.
    Bigazzi adapted the original code to be used on the APB bus instead of the AHB, and parameterized the section of the code used to send data at the appropriate baud rate.

  • The APBUART module implements a 3-wire serial interface. The data is transmitted in individual data frames containing one start bit, 8 data bits, 1 stop bit, and no extra parity bits.

  • To send a byte, write to the UART_REG__TX_DATA register. To read received data, read from the UART_REG__RX_DATA register. When the module receives one or more bytes of data, the interrupt to the Cortex-M0 is asserted. This interrupt remains active until all received data is read.

  • This module instantiates four submodules: BAUDGEN, FIFO, UART_RX and UART_TX.

• APBADC_V2

  • This module is the digital interface to the analog-to-digital converter (ADC) designed by David Burnett for the Single Chip Mote.

  • This module controls a series of inputs that activate and control the ADC; these inputs are toggled using an internal state machine.

  • The 10-bit result of the ADC is saved onto a register after the conversion is complete.

  • This module also asserts an interrupt to the Cortex-M0 when a conversion is complete.

• APB_ANALOG_CFG

  • This module contains a parameterizable amount of 16-bit programmable registers used to configure any analog circuits on the Single Chip Mote.

  • These registers are connected to outputs in the top module. On an FPGA these are connected to actual output pins, but on an ASIC they are not connected to any external pins. Instead they are connected directly to the analog circuit requiring configuration.

• APBGPIO

  • This module is an interface for up-to 16 general-purpose digital inputs and up-to 16 general purpose digital outputs. The inputs may be used for buttons and switches on the FPGA board, or any kind of digital input on an ASIC. The outputs may be used to drive LEDs on the FPGA board, or any kind of digital output on an ASIC.

• chipscope_debug

  • chipscope_debug.cdc is ChipScope definition and connection file. ChipScope is a tool from Xilinx used to sample signals from within a design as it is running on the FPGA. The module that samples these signals is referred to as an integrated logic analyzer (ILA). This tool is typically used for debugging purposes.

• Deprecated Modules

  • This section contains information on deprecated Verilog modules or modules generated in Coregen for Single Chip Mote on the Artix-7 and uRobotDigitalController on the Spartan-6.

IEEE 802.15.4 Packets
The radio circuit and RFcontroller module on the Single Chip Mote are designed to transmit and receive packets compliant with the IEEE 802.15.4 standard. In particular, the radio circuit and RFcontroller module are responsible for implementing the physical (PHY) layer of the standard.
This standard defines several different PHYs which use different frequency bands and modulation schemes. The Single Chip Mote implements the O-QPSK PHY, defined in section 10 of the standard. The binary-encoded data in the packet is separated into groups of 4-bit symbols, where 2 symbols is equivalent to a byte.
Each packet:

• begins with a preamble, beginning with 8 copies of the 4'b0000 symbol.

• The preamble is followed by the 8-bit (2 symbol) start-of-frame delimiter (SFD).

• Then follows the length of the packet payload, in bytes. This field is 7 bits wide (for a maximum payload length of 127 bytes), with 1 reserved bit to make it 8 bits (2 symbols) wide.

• Next is the payload, with an upper bound of 127 bytes.

• At the end of the packet is the 16-bit (4 symbol) cyclic redundancy check (CRC) value of the packet.

The binary data is converted from symbols to a serial bitstream of chips, and the chips modulate the transceiver on the radio circuit. The RFcontroller module operates on binary data;

• the spreader submodule converts symbols to chips for the radio circuit during transmission, and

• the corr_despreader submodule converts received chips into symbols.

Chapter 4: Single Chip Mote Software

While the majority of the work on the Single Chip Mote is focused on hardware design, the overall goal of this project is to work in collaboration with software developers to design a platform ideal for Internet of Things (IoT) applications.

The information in this chapter contains the basics for writing software that uses the digital system peripherals in order to facilitate application development.

Keil Project Settings

• Keil projects have already been created for the main software running on the Cortex- M0 and the basic firmware (chapter 5) used to load the main software onto the Single Chip Mote digital system.

• However, it may be necessary in the future to create new projects for different applications or variations of the Single Chip Mote hardware.

• This section contains the information needed to create a new project in Keil uVision 5 for the ARM Cortex-M0 on the Single Chip Mote digital system.

Required Assembly, Header, and C Files

• m0dsasm.s file contains the assembly code required by the Cortex-M0 in order to handle startup, resets, and interrupts properly.

  • The first section of this code defines the size and properties of the stack and heap.

  • The second section of this code defines the vector table. The vector table is a series of addresses defined at the beginning of a program that point to reset handlers, exception handlers, and interrupt handlers.

• ˆ retarget.c contains the C code used to implement the printf function using UART.

• ˆ Memory_map.h contains define statements for all of the peripheral memory-mapped registers.

Memory Mapped Peripherals

• Radio Timer

  • Timer Operation

  • Timer Control

  • Using a Compare Unit

  • Using a Capture Unit

  • Interrupts

  • Register Write Delays

  • Example Code

• Radio Controller and DMA

  • Radio Controller Initialization

  • Packet Storage in Memory

  • Sending a Packet

  • Receiving a Packet

  • Example Code

• UART

  • The ideal method for dealing with received data is to write the interrupt service for the UART peripheral assuming that it reads one 8-bit value at a time. (see the code)

• ADC Controller

• Analog Configuration Registers

• General-Purpose Input and Output Registers

Current Demo Software

The software currently used to test and demonstrate the Single Chip Mote digital system on an FPGA is found in the following Keil project:
scm-digital/proj/keil/uRobotDigitalController/code.uvprojx.

This software responds to several different commands sent to the Single Chip Mote via UART (cpy <string>\n, lod\n…)

• rf_global_vars.h
  This file contains the declarations for the send_packet and recv_packet buffers

• main.c
  This file contains the main function that executes after reset

• Int_Handlers.h
  This file contains the interrupt service routines for the UART, ADC, radio controller, and radio timer.

  • The UART interrupt service routine is called when a single 8-bit value is transmitted to the Single Chip Mote via UART. This demo software interprets each 8-bit value as a single ASCII character, and a series of 4 ASCII characters can indicate a particular command.

  • The ADC interrupt service routine is called when a conversion is complete.

  • The radio controller interrupt service routine prints the reason for the interrupt based on the RFCONTROLLER_REG__INT and RFCONTROLLER_REG__ERROR registers and then clears these registers.

  • The radio timer interrupt service routine reads the RFTIMER_REG__INT register to find the source of the interrupt.

Chapter 5: Bootloader

This chapter covers the details of the Single Chip Mote bootloader, the specialized hardware and software used to load compiled C code onto the instruction memory for the ARM Cortex-M0. The bootloader requires four distinct hardware/software components:

• Instruction ROM on Single Chip Mote

• Instruction RAM on Single Chip Mote

• Bootload Hardware on Nexys 3

• Bootload Firmware for ARM Cortex-M0

Chapter 6: Testing

Mistakes in the final ASIC version of this chip are extremely costly, and simulating the entire Single Chip Mote in Cadence or Synopsys is computationally intensive and slow. Therefore, it is essential that
the Single Chip Mote digital system is thoroughly tested in simulation and on an FPGA before moving on to an ASIC design.

• Unit-level testbenches and simulation are used to verify that modules or small groups of modules behave properly in isolation.

• Real-time tests on the FPGA hardware indicate that the entire system works together as expected, including interfaces with the analog and radio circuits.

Simulation Testing Using ISim

• The module or modules being tested are referred to as the device under test (DUT) or unit under test (UUT).

• Xilinx ISE uses a Verilog simulator, called ISim, to simulate testbenches added to an ISE project.

Chapter 7: Transitioning to ASIC

This chapter provides an outline of the code changes required to create an ASIC version of the Single Chip Mote digital system

• Power-On Reset and Clock Generator

  • The ASIC version of the Single Chip Mote requires a separate analog circuit, with inputs and outputs to/from the digital system to handle clocks and resets. This analog circuit is responsible for:

    • ˆ Generating the 5MHz system clock

    • Generating the 2MHz radio transmission clock (with the option of a clock enable signal)

    • Generating the 500kHz radio timer clock (with the option of a clock enable signal), and ensuring that this clock is phase-aligned with the system clock

    • Generating a 2MHz radio receive clock (with the option of a clock enable signal) using the input data from the radio transceiver

    • Buffering the 3 Wire Bus clock from a pad on the chip

    • Debouncing the input reset signal from a pad on the chip

    • Sampling the reset request signal from the Cortex-M0

    • Generating the two reset signals using the input reset and the reset request signal

• Memories

• Scan Chain Insertion and Debug Interface

• Integrated Logic Analyzer

  • may aid in diagnosing transient errors that are dicult or impossible to replicate in simulation (for example, issues when sending or receiving radio packets).

• Optical Serial Interface

• Changes to Top-Level IOs

Important terms

• MEMS microrobot: micro-electro mechanical system microrobot

• ISE: Integrated Synthesis Environment

• AHB: Advanced High-performance Bus

• APB: Advanced Peripheral Bus

• FSM: finite state machine

• ISR: interrupt service routine

• OQPSK: Offset quadrature phase-shift keying

Google search

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

• What does it mean to debounce a signal?

  Bouncing is the tendency of any two metal contacts in an electronic device to generate multiple signals as the contacts close or open; debouncing is any kind of hardware device or software that ensures that only a single signal will be acted upon for a single opening or closing of a contact.

• If a level-triggered interrupt from a peripheral device is enabled and active, but the kernel trap handler cannot immediately run the device's interrupt service routine (ISR) to clear the interrupt, the handler masks the interrupt at the GPIO pin to prevent the pin from repeatedly causing more interrupts. Later, after the ISR runs and clears the interrupt, the interrupt can be safely unmasked.

• Why do we use OQPSK?

  To overcome regeneration of sidelobes and spectrum widening, linear amplifier is employed. But linear amplifiers are less efficient. Hence OQPSK has been developed. OQPSK prevents phase transition from the origin by shifting one stream by a bit period and allowing only one bit to change between the transitions.

Review

1. 1 word= 2 bytes

2. Copied from: OpenWSN

• 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.