Rateless Wireless Networking Decoder Mikhail Volkov Edison Achelengwa

  • Slides: 22
Download presentation
Rateless Wireless Networking Decoder Mikhail Volkov Edison Achelengwa Minjie Chen

Rateless Wireless Networking Decoder Mikhail Volkov Edison Achelengwa Minjie Chen

Cortex: a rateless wireless system • Very recent work here at CSAIL (Perry, 2011)

Cortex: a rateless wireless system • Very recent work here at CSAIL (Perry, 2011) • Use a novel rateless code called spinal code • Encoder and decoder agree on a seed s 0, a hash function h and an IQ constellation mapping

Spinal Encoder • Wish to transmit a message M = m 1 m 2.

Spinal Encoder • Wish to transmit a message M = m 1 m 2. . . mn • Break the message into k-bit segments Mi • Apply h to generate a spine

Spinal Encoder • Encoder performs passes over the spine, each time generating new constellation

Spinal Encoder • Encoder performs passes over the spine, each time generating new constellation points • These constellation points are sent across an AWGN channel

Spinal Decoder • Decoder knows s 0 so it can generate the 2 k

Spinal Decoder • Decoder knows s 0 so it can generate the 2 k possible candidate symbols s 1 using h • Each time decoder receives symbol y it keeps the B best symbols from 2 k candidates using ML • The transmitted message is estimated as the one with the lowest ML cost

Spinal Decoder

Spinal Decoder

Objectives • Implement decoder on an FPGA • Evaluate feasibility of Cortex in a

Objectives • Implement decoder on an FPGA • Evaluate feasibility of Cortex in a real communications system • Identify key performance bottleneck and develop a clear strategy for developing a practical Cortex system

Micro-architecture • Interface • Takes stream of constellation symbols as input • Outputs a

Micro-architecture • Interface • Takes stream of constellation symbols as input • Outputs a message (192 -bit packet) • Decoding Stages • Code Enumeration • Add-Compare-Select • Suggestion Update • Spine Evaluator Update • Get output message

Input bit Streams Decoder curr_suggcosts curr_schedule to. ACSQ suggupd do. Enumerate Msg Vect(B*2^k, Marked.

Input bit Streams Decoder curr_suggcosts curr_schedule to. ACSQ suggupd do. Enumerate Msg Vect(B*2^k, Marked. Cost) Vect(B*2^k, Enum. Resp) put Sorting module get Enum. Req Schedule get. Schedule Puncturing Scheduler put Vect(B, Marked. Cost) get Spine Evaluator mk. Salsa, h(*) Symbol Mapper f(*) get schedule params get. Out. Msg update. Tree Send_stat outbits. Q do. ACS out_msg (get) update. Sym. Q Symbol rcv (put) I Q mk. Decoder seeding parameters evalupd get. Msg backtrack. Mem get. Best. Msgs Vect(B, Mark) Msg

Micro-architecture • Sub-modules • Puncturing Scheduler • Spine Evaluator • Sorter • Backtrack Memory

Micro-architecture • Sub-modules • Puncturing Scheduler • Spine Evaluator • Sorter • Backtrack Memory

Input bit Streams Decoder curr_suggcosts curr_schedule to. ACSQ suggupd do. Enumerate Msg Vect(B*2^k, Marked.

Input bit Streams Decoder curr_suggcosts curr_schedule to. ACSQ suggupd do. Enumerate Msg Vect(B*2^k, Marked. Cost) Vect(B*2^k, Enum. Resp) put Sorting module get Enum. Req Schedule get. Schedule Puncturing Scheduler put Vect(B, Marked. Cost) get Spine Evaluator mk. Salsa, h(*) Symbol Mapper f(*) get schedule params get. Out. Msg update. Tree Send_stat outbits. Q do. ACS out_msg (get) update. Sym. Q Symbol rcv (put) I Q mk. Decoder seeding parameters evalupd get. Msg backtrack. Mem get. Best. Msgs Vect(B, Mark) Msg

Practical Salsa Implementation • In practice we cannot have infinite precision floating point numbers

Practical Salsa Implementation • In practice we cannot have infinite precision floating point numbers • Salsa produces two outputs: a 64 -bit spine and 512 -bit arrays of symbol bits

Development and Testing • 3 point development and testing plan • Critical to our

Development and Testing • 3 point development and testing plan • Critical to our success with 3 people under time constraints Step 1: Develop Decoder backbone with dummy Sorter and Spine Evaluator. Develop Sorter and Spine Evaluator independently. - Sorter tested with MATLAB. - Spine Evaluator (and Salsa) tested with Python.

Development and Testing Step 2: Integrate Decoder with Sorter and Spine Evaluator. Ensure correctness

Development and Testing Step 2: Integrate Decoder with Sorter and Spine Evaluator. Ensure correctness at the architectural level: - Modules instantiate correctly - Rules fire as expected, no deadlocks etc. - Timing is correct - Bits flowing end-to-end

Development and Testing AWGN Channel Python Encoder Python Decoder out in - Encode string

Development and Testing AWGN Channel Python Encoder Python Decoder out in - Encode string with Python encoder to produce symbols - Decode symbols and compare results out Step 3: Ensure correctness at the semantic level, i. e. “bit-by-bit debugging” Bluespec Decoder

Development and Testing • Finally, the algorithm was tested by adding noise to the

Development and Testing • Finally, the algorithm was tested by adding noise to the transmitted symbols • Strictly not our concern, as long as our implementation agreed with the source code • Algorithm worked very well • Actually “outdid” the reference code at one point: the Python code crashed but our decoder correctly decoded the message!

Performance Analysis – FPGA frequency • The synthesized FPGA maximum frequency is 98. 035

Performance Analysis – FPGA frequency • The synthesized FPGA maximum frequency is 98. 035 MHz. • Different Salsas gives the same FPGA frequency.

Performance Analysis – Frequency, Latency, Throughput

Performance Analysis – Frequency, Latency, Throughput

Performance Analysis - Area • Sorter and Spine. Evaluator take the most area

Performance Analysis - Area • Sorter and Spine. Evaluator take the most area

Performance Analysis - Area • Our implementation actually fits on the FPGA. (roughly taking

Performance Analysis - Area • Our implementation actually fits on the FPGA. (roughly taking 30% of the total area) • Different Salsa implementation don’t vary too much on device utilization.

Performance Analysis - Code • The total lines of source code was 3104. Of

Performance Analysis - Code • The total lines of source code was 3104. Of these, the total lines of test code was 1135 (36. 5%) and non-test code was 1969 (63. 4%).

How much better can we do? • We used a naive O(n 2) algorithm

How much better can we do? • We used a naive O(n 2) algorithm for the sorter module. We might be able to use other algorithm to reduce the cycle step from 149 to 32 in the best case, which brings a 5 times better performance and improve the bit rate ot 7. 5 Mbits/s. • Given the current space requirement of Salsa, we can have B (B=4) of seperate hashing modules running in parallel with each other. In this case, we can have 4 times of better performance and improve the bit rates to 7. 5*4 = 30 Mbits/s. • Suppose we have sufficient area on the FPGA, we will be able to have B*2 k = 32 of hash modules running in parallel with each other. This will bring 32 times of better performance and improve the bit rates to 7. 5*32 = 240 Mbits/s.