| View file | ||
|---|---|---|
|
...
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.
...
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].
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.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.
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.
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
...
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µm2, which easily fits within a die area of 1mm2 . Assuming an incident power of 1mW per mm2 in direct sunlight, CMOS solar cells with at least 10% conversion eficiency should be able to provide 100µW per mm2 of die area in direct sunlight. Therefore, this design (when run with an operating voltage 0.9V ) requires approximately 1mm2 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 2mm2 of area for the circuits themselves, and 2mm2 of area for additional solar cells. With these numbers in mind, the Single Chip Mote requires a total die area of 6mm2.
Given that the thickness of the die is about 200µm, and the density is similar to that of crystalline silicon (2.33g/cm3), 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.
...
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.
...
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.
...
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
...
Verilog, standardized as IEEE 1364, is a hardware description language (HDL) used to model electronic systems.
Review
1 word= 16 bits
Copied from: https://openwsn.atlassian.net/wiki/spaces/OW/overview
...