Rateless Wireless Networking Decoder Mikhail Volkov Edison Achelengwa Minjie Chen

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... m n Break the message into k-bit segments M i Apply h to generate a spine

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 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

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 message (192-bit packet) Decoding Stages Code Enumeration Add-Compare-Select Suggestion Update Spine Evaluator Update Get output message

Decoder rcv (put) Send_stat Symbol Mapper f(*) Spine Evaluator Puncturing Scheduler Input bit Streams I Q backtrackMem mkSalsa, h(*) seeding parameters curr_schedule curr_suggcosts schedule params getOutMsg updateSymQ out_msg (get) mkDecoder Sorting module doEnumerate doACS suggupd outbitsQ getSchedule Schedule getput EnumReq Vect(B*2^k, EnumResp ) Symbol Msg updateTree getMsg getBestMsgs put get Vect(B*2^k, MarkedCost ) Vect(B, MarkedCost ) Vect(B, Mark ) Msg toACSQ get evalupd

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

Decoder rcv (put) Send_stat Symbol Mapper f(*) Spine Evaluator Puncturing Scheduler Input bit Streams I Q backtrackMem mkSalsa, h(*) seeding parameters curr_schedule curr_suggcosts schedule params getOutMsg updateSymQ out_msg (get) mkDecoder Sorting module doEnumerate doACS suggupd outbitsQ getSchedule Schedule getput EnumReq Vect(B*2^k, EnumResp ) Symbol Msg updateTree getMsg getBestMsgs put get Vect(B*2^k, MarkedCost ) Vect(B, MarkedCost ) Vect(B, Mark ) Msg toACSQ get evalupd

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

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 MHz. Different Salsas gives the same FPGA frequency.

Performance Analysis – Frequency, Latency, Throughput

Performance Analysis - Area Sorter and SpineEvaluator take the most area

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 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 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.5Mbits/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 = 240Mbits/s.