This Documentation is for the Bluetooth Low Energy (BLE) Baseband. It has been synthesized on both FPGA and ASIC platforms and comes with testbenches.
This project is based off work in EE290C @ UC Berkeley 2018 fall semester as well as EE290C Spring 2018. The list of contributors can be found here.
2018 Fall EE290C, taught by Prof. Borivoje Nikolic, offers Advanced Topics in Circuit Design: VLSI Signal Processing. The course adopts Chisel, an open-source hardware construction language developed at UC Berkeley, to implement digital signal processing designs. The design could be verified by hooked up to the Rocket Chip. Our group chose to implement a BLE baseband for the final project.
The BLE baseband includes two main blocks: packet assmebler (PA) and disassmbler (PDA), which are responsible for TX and RX sides respectively. Two submodules, CRC and (de)whitening, are attached to PA/PDA to follow Bluetooth Specification v5.0. The final goal is to implement a complete BLE baseband loop chain.
The diagram of the expected BLE loop chain is shown below:
- 2018 Fall EE290C: Jerry Duan, Mingying Xie, and Yalun Zheng
- 2018 Spring EE290C: Richard Renn, Charles Huang
- PA: packet assembler, PA chain
- PDA: packet disassembler, PDA chain
- CRC: CRC
- Whitening: Whitening
- Top level: loopback
Below is an overall diagram of the BLE packet structure. As specified in Bluetooth Specification v5.0, the BLE packet includes Preamble, Access Address, PDU (header and payload), and CRC.
For LE 1M packet, the preamble is determined by the last bit of access address (AA). It should be noted here, since the AA sequence has to be flipped for transmitting, the bit we actually look at is the first bit in the AA field (if 0, preamble is 01010101; if 1, preamble is 10101010).
The standard AA for broadcasting is 0x8E89BED6. Thus the encoded AA is 0110_1011_0111_1101_1001_0001_0111_0001.
Matlab code demonstration: fliplr(dec2bin(hex2dec('8E89BED6'),32))
The PDU header contains 6 parts: PDU type, RFU, RxAdd, TxAdd, ChSel and Length.
Our project adopts ADV_NONCONN_IND in LE 1M packet implementaion.
Reserved for future use in Spec v.05.
0 means public address, 1 means randomized address. Set both to 0 in this project.
Indicate the size of payload in bytes/octets. The length should be larger than 6 (reserved for advertising address) and less than 37. For example, if we have 6 for address, 3 for headers, 6 for payload, then PDU_length is 15. Similar to AA, the transmition start with LSB, so length 15 is 11110000 to keep the correct order.
There are three sections within the payload we used, which are advertising address and two advertising data (denoted as payload1 and payload2).
The advertising address field contains the device address of the advertiser (BLE Spec Vol 6, Part B, Section 2.3.4.1). In this project, AdvA is set to the MAC address of the advertiser. This should also follow LSB-first transmission order.
The advertising data should contain 0 or more sections. Each section is consisted of one byte indicating the length of the section, one byte indicating the GAP code (refer to GAP Code definition), and one byte indicating the data. For example, in the current packet, the payload1 is 0x02 (length), 0x01 (“flags”), 0x05 (flag data). The payload2 is 0x05 (length), type 0x08 (“short name”), data 0x32 0x39 0x30 0x43(ASCII code for “290C”).
For this part, please refer to CRC and whitening.
BLE Spec has an explanation about whether we have to reverse the bit sequence: "Multi-octet fields, with the exception of the Cyclic Redundancy Check (CRC) and the Message Integrity Check (MIC), shall be transmitted with the least significant octet first. Each octet within multi-octet fields, with the exception of the CRC (see Section 3.1.1), shall be transmitted in LSB first order. For example, the 48-bit addresses in the advertising channel PDUs shall be transmitted with the least significant octet first, followed by the remainder of the five octets in increasing order."
-
Add-on features like FEC mentioned in Bluetooth 5 Spec
-
Besides advertising PDU type, implement scan type (eg.
SCAN_REQ), connect (CONNECT_REQ) and so on -
Apply more random-generated test cases
-
Take operation frequency into considerations when the digital BLE baseband has to talk with analog circuits
Here is our appreciation to Prof. Borivoje Nikolic, Prof. Kristofer Pister and the GSI Paul Rigge for guiding us in this project. Their valuable suggestions and feedback help us move forward. Also the work from last semester's group inspired us greatly and here is their tape-out work has been integrated into this repo. Lastly, we would like to thank David Burnett and Rachel Zoll for helping us get on board and explain BLE packet structure and tests.