420 likes | 634 Views
Wireless Transceiver. EECS150 Spring 2008 Shah Bawany. This Lab Lecture…. Timeline Checkpoint 3 Overview Checkpoint 2.5 Overview. Timeline. Checkpoint 1 Was due this week If you didn’t finish, turn it in as soon as you do for partial credit Checkpoint 2 Design Reviews were this week
E N D
Wireless Transceiver EECS150 Spring 2008 Shah Bawany EECS150 Spring 2008
This Lab Lecture… • Timeline • Checkpoint 3 Overview • Checkpoint 2.5 Overview EECS150 Spring 2008
Timeline • Checkpoint 1 • Was due this week • If you didn’t finish, turn it in as soon as you do for partial credit • Checkpoint 2 • Design Reviews were this week • Code due after break • Very easy checkpoint, but we are only postponing the due date so you can make thoughtful designs for checkpoint 3 (we will grade them much more harshly) and so that you can catch up if you’ve fallen behind (by working all break EECS150 Spring 2008
Timeline (2) • Checkpoint 2.5: 4-Port Arbiter, Frame Subsampling, Complete UI • An early start on Checkpoint 4 for those looking to work ahead. • If you make a design for the CP3 design review AND get checked off for it with CP3, you will get 5% extra credit on CP3. • Specs will be up this weekend • Checkpoint 3: Wireless Transceiver • Specs up now, Design Reviews next week • Due the week after CP2 (the 2nd week after break) • The time given for this checkpoint is justified by its difficulty EECS150 Spring 2008
Timeline (3) • Checkpoint 3 (continued) • Some additional tools will be released this weekend or early next week • Packet sniffer - For detecting what’s being transmitted on a wireless channel) • TA solution - To test transmit / receive independently • Checkpoint 4: Integration and Compression • Specs will hopefully be up before break • Lab lecture will be the week you return from break • Design reviews will be the same week CP3 is due • Final project (CP4 + extra credit) due 2 weeks after CP4 design reviews EECS150 Spring 2008
Transceiver Overview (1) • 3rd party chip mounted on expansion board. • Uses a PCB antenna. Take a look! • IEEE 802.15.4 standard support. • Transmits on unlicensed 2.4 GHz spectrum. 16 communication channels. • Overlaps with Wi-Fi. • 250 kbps maximum data rate. • In use in the project, we can achieve 16KBps • Configure, send, receive, and issue commands to chip over SPI to CC2420 registers. EECS150 Spring 2008
Transceiver Overview (2) • 33 configuration registers. • We change 3 of them. • 15 command strobe registers. • We issue 6 of them. • These change the state of the CC2420 internal FSM. • 128-byte RX FIFO & 128-byte TX FIFO • Accessed via 2 additional registers. • Also accessible as RAM (i.e. by addressing). Only for debugging! Don’t do this unless you’re a masochist EECS150 Spring 2008
Transceiver Overview (3) • You will need to read the data sheet to learn more about how the CC2420 works in more detail than what we can fit in the Spec. • MDPU • Status Registers (more info.) • Commands (more info.) • Internal state machine (very helpful!!) EECS150 Spring 2008
CC2420 Inputs & Outputs • Single bit status signals. • High level transceiver operation information. • Initialization signals. • Drive signals once and forget about it. • SPI interface. • Interface to rest of chip via CC2420 registers. • Send, receive, configuration, detailed status. FPGA VREG_EN RF_RESET_ EECS150 Spring 2008
Single Bit Status Indicators • FIFO – Goes high when there’s received data in RX FIFO. • FIFOP – Goes high when # bytes received exceeds set threshold. • CCA – Indicates that the transmission medium (air) is clear. Only valid after 8 symbol periods in RX mode. • SFD – Goes high after SFD is transmitted & low after packet completely sent. EECS150 Spring 2008
SPI Interface • Serial interface with 4 wires: • SClk – Clock signal you generate. • CS_ – Active-low chip select. • SI – Output to the CC2420. • SO – Input from the CC2420. • Interface to the chip! Initialization, configuration, TX, RX, detailed status. • Luckily for you, it’s provided as a black box. EECS150 Spring 2008
CC2420-specific SPI (1):First Byte • First byte always has above format. • Bit 7 – Set to 0 for register access. • Bit 6 – Read/write control. • Bits 5:0 – Address of register. P. 60 of datasheet. • Followed by data specific to register being accessed. EECS150 Spring 2008
CC2420-specific SPI (2):Writing to Configuration Reg. • First byte followed by 2 bytes of configuration data. • Data on SO invalid here. • Transceiver replies when first byte is sent out with status byte. • True for all SPI accesses. • Not necessary to inspect, but can be helpful for debugging! EECS150 Spring 2008
CC2420-specific SPI (3):Issuing Command Strobes • One byte only. Nothing follows. • Address sent indicates the command strobe being issued. • Note that 0x00 is NO OP. This is useful for explicitly retrieving status byte. EECS150 Spring 2008
CC2420-specific SPI (4):Saving to TX FIFO • After first byte, send n bytes of data to transmit over wireless. • SPI session only ends when CS_ is pulled high. • CC2420 replies with a new status byte with each byte that’s saved to FIFO. EECS150 Spring 2008
CC2420-specific SPI (5):Receive from RX FIFO • After first byte, send a n bytes of “don’t care” in order to receive data. • During first byte, CC2420 replies with status. Subsequent bytes are data saved in FIFO. • Must be careful not to request data from empty FIFO! • SPI session only ends when CS_ is pulled high. • Reading from a configuration register is the same. EECS150 Spring 2008
Configuration Registers EECS150 Spring 2008
Command Strobe Registers EECS150 Spring 2008
TX/RX FIFO Registers EECS150 Spring 2008
Initialization EECS150 Spring 2008
Transmit EECS150 Spring 2008
Transmit(2) • CC2420 needs 12 symbol periods to move into RX_SFD_SEARCH state after transmit done or SRXON. • 1 symbol period = 16 us. • Without enforcing wait, aggressive user of your Transceiver module will cause CC2420 to never receive data from air. EECS150 Spring 2008
CCA • If you don’t follow CCA we will dock MAJOR points • If CCA isn’t high, you must wait a RANDOM AMOUNT OF TIME • CCA may also not go high if you have buffer overflow. FIFOP & !FIFO EECS150 Spring 2008
Receive (1) EECS150 Spring 2008
Receive (2) • You must be able to receive while the random CCA wait time is expiring! • Packets are only received after CC2420 has spent 12 symbol periods in receive mode. • There must be wait time between transmissions. • Allows the transceiver to look for and receive data. EECS150 Spring 2008
Receive(3) • Refers to 2 things: • CC2420 is constantly receiving and saving data into RX FIFO as long as it’s not transmitting. Look at CC2420 internal FSM on p. 43. • You have to “receive” data from RX FIFO, filter it, then save wanted data into SPIFifo. EECS150 Spring 2008
Design Structure (1) • Transceiver – Highest level block. 32-bit input/output, channel changing, addressing. • SPI Abstraction – Takes care of details of CC2420 SPI interface. Arbitrates between TX/RX. • SPI (provided) – Handles details of interface timing. EECS150 Spring 2008
Design Structure (2) • High level FSM behavior • Upon receiving a request to transmit, load TX FIFO, but wait till CCA clear to send • If CCA not clear, check if RX FIFO has something to recieve • If data in RX FIFO, read data then check CCA again but do not assert ready until you have transmitted the last piece of data • If CCA is clear, transmit return to ready state EECS150 Spring 2008
Design Structure (3) • High level FSM behavior (continued) • Hint: One implementation of the overall FSM includes a state for initialization, a ready state, 2 CCA wait states, 2 TX states (load/send) and an RX state. Each of these states engages one of the FSMs presented on the previous slides. EECS150 Spring 2008
Packet Format • On transmit, only fill TX FIFO starting with length byte. • Preamble & SFD automatically appended. • Transmit all zeros for CRC. CC2420 will replace. EECS150 Spring 2008
Channel & Addresses • There are 16 channels. • Your group will be assigned a channel. • You must be able to change channels without reset! • DO NOT USE ANOTHER CHANNEL BESIDES YOUR OWN • This is a big class and we need to be able to partition the signal space! • Address are 8-bits wide 256 addresses. Zero is unused. 0xFF is reserved for broadcast. EECS150 Spring 2008
Interference & Debugging • Roughly 2-3 groups per channel. Each group in a particular lab has distinct channel. • Can also pick up data on neighboring channel. • Very first goal is robust channel changing during initialization. • Can pick up 802.11 packets sometimes. • Your module must recover gracefully. • Your project interferes with Wi-Fi & vice versa. EECS150 Spring 2008
Handshaking:InRequest/Invalid • SPI uses a variation of this. • You may want to use this internally. EECS150 Spring 2008
Handshaking:Ready/Start • Transceiver uses this interface for input & output. EECS150 Spring 2008
Design Structure (4) • When you receive a START signal, do not assert READY until you have issued the command to actually transmit the value you have loaded into the TX FIFO • Upon receiving a START signal, store the input into the TX FIFO, but wait for CCA to be clear before transmitting EECS150 Spring 2008
Debugging Tools • Chipscope! • We will be releasing some debugging utilities. • Packet sniffer. • Packet counter (The TA Solution does this) EECS150 Spring 2008
Get Started! • READ THE DATASHEET • Obey our CCA rules EECS150 Spring 2008
Danger! Danger! • Don’t become complacent because you’ve *been* finishing checkpoints early • Expect each checkpoint to be at least twice as difficult as the last. • 1>>2>>>>3>>>>>>>>4! • Get started early and get ahead. EECS150 Spring 2008
Checkpoint 2.5 • Complete UI: EECS150 Spring 2008
Checkpoint 2.5 • Four Port Arbiter: Wireless Out Wireless In SDRAM Controller Wireless Rec. Proc. CP3 Wireless Channel CP4 DCT/ Huffman SDRAM Arbiter Wireless Send Proc. VD Proc. Subsampler VE Proc. PIP Proc. Camera Display EECS150 Spring 2008
Checkpoint 2.5 • Check the website regularly for full the updated full spec. • It makes sense to start this as soon as you finish CP3 since you will have to do it anyway • Extra credit incentivizes it more • Any questions?