PicoNode III v1'0

1
PicoNode III v1.0
multi-hop network
ad-hoc
localization
low-cost
sensors
self-sustaining
reactive
ubiquitous
low-power
small
integrated
SOC
ubiquitous
Yes
Partial
Maybe
2
Reactive Behavior Diagram
Sensor/actuator interface
App/UI
User interface
Sensor/ actuators
Transport
Aggregation/ forwarding
Network
Locationing
Power control
DLL (MAC)
Energy train
Baseband
Ranging
Reactive radio
RF (TX/RX)
Antenna
3
Optimize Scenarios Not Events
Multi-hop packet forwarding scenario (simplified)
1) We knew the DLL/Network was going to be needed
long before the data event came and woke it upby
ignoring that info, now need to buffer or delay
data
2) Also, network layer knew that the packet was
going to be forwarded here from the header info
Network
DLL
DLL
PHY RX
PHY TX
t
wakeup event
3) Ignoring info from 2 means that DLL turns off
and immediately turns back onincurring overhead
for each action
4) Also, using info from 2, the long startup
overhead for the transmitter could have begun
much earlier, reducing duty cycle of node
Useful work
Startup/init overhead
Who decides whether a block can go to sleep?
4
Enter the System Supervisor
Multi-hop packet forwarding scenario (simplified)
1) Network layer told SS that transmission is
imminent
Network
DLL
DLL
PHY RX
t
PHY TX
wakeup event
3) SS also prevents DLL from taking an
unnecessary short nap, reducing overhead while
maximizing benefits of deep sleep
2) SS told TX path to turn on, allowing latency
to be reduced through concurrency, reducing total
active power
Useful work
Startup/init overhead
Big Brother is watching
5
Example scenario

• Medium Access Controller (MAC)
• Wake-up milestones
• NET_TX_pkt
• TIMER_control_timeout
• BB_RX_pkt
• Resolving milestones
• Is control msg?
• Is TX required?
• DLL done?
• Affected external wake-up milestones
• NET_RX_pkt
• BB_TX_pkt
• DLL_msg_processor
• Transition outputs for BB_TX_pkt event
• Activate MAC (NET_TX_pkt1)
• Activate NET (NET_RX_pkt1)
• Sleep MAC, sleep net
• Activate DLL controller (DLL_msg_processor1)
• Sleep MAC

Wait for BB_RX_pkt event
1
Is control msg?
DLL done?
N
Y
2
3
Y
4
Is TXrequired?
DLL done?
N
Y
5
6
Y
DLL done?
Y
7
8
Note self-loops are implicit
6
HW Deep Sleep Considerations
Waking up is hard for even humans, so
system supervisor alerts blocks to important
events set an alarm in the system supervisor,
avoiding timers in deep sleep blocks
Set alarm 1

Alarm 1 event
Alarm 2 event

Set alarm 2

System timewheel
Preserving state complicates deep sleep, so
separate state circuitry from blocks under
power control keep a journal in the system
supervisor for small items design FSMs to
return to default state while sleeping
7
Hard vs. Soft State

• Hard state
• State that is required for operation, independent
  of implementation
• Must be preserved during sleep mode
• Soft state
• State that is required for a particular
  implementation
• If implemented carefully, can be trashed during
  idle mode
• eg.remove self loops from all but the initial
  state in a FSM

!send_pkt
Default power-up state
send_pkt
S1
done_recovering
done_receiving
!timeout !reply
S5
S2
done_receiving
reply
timeout
reply
send_pkt
S3
S6
S7
S8
timeout
S4
done_recovering
Savvy verification guys will point out that these
two FSMs are not identical. In many cases this
is fine. If they need to be identical, then that
implies some hard state.
8
SS Block Diagram

• System supervisor
• Microcoded state machine that executes only when
  a new event occurs
• Generates power control messages to functional
  units
• Since centralized, can gate clock tree globally
  instead of only locally
• Timer subsystem
• Free-running system timewheel
• Allows other blocks to go to sleep and wake up
  with alarms (callbacks)
• Interfaces to supervisor as just another event
  source
• Functional unit power control
• Gated clocks and switchable power supplies 0,
  0.3, 1.0V

9
Summary

• System supervisor
• Supports reactive nature of design
• Optimizes scenarios for reduced power
• Maintains system timewheel to allow deep-sleep of
  other blocks
• Subblock design ramifications
• Differentiate between hard and soft state to
  tolerate potential loss of soft state
• Must determine wake-up and resolution milestone
  events and apprise SS when they occur