CRKit Status + Future direction

1. CRKit Status + Future direction Khanh Le, Ivan Seskar Date : Jan 27, 2012

2. Motivation • Why CRKit Framework ? • Complete Radio system design is a complicated and elaborated process • Many man-hours required with expertise in many different areas e.g. HW, SW, Communication, RF … • With Framework, we can abstract the lower level design complexities from users • Let users concentrate on the creative side of the problems such as communication algorithms, system level considerations… • Split radio system into static and dynamic domains. • Static – System-on-Chip which has been predesigned and tested. It will be open-sourced, but maintained by CRKit team. • Dynamic – Communication Applications -> swappable according to user’s needs and applications • Create a library of open-sourced Communication Applications, no need to create designs from scratch. • Concentrate on what matters the most : creativity, new innovations.

3. CRKit Overview • CRKIT currently consists of following major components : • Ethernet Port (static) • Gigabit Ethernet rate • frame synchronization • frame generation/formatting • Support Jumbo frames • Packet Processor (static) • Simple packet classification/forwarding scheme based on IP/UDP • Control packets -> Processor Core • Data packets -> APP • Support a subset of VITA Radio Transport protocol • Memory management for APP data • IP/VITA packet generation/formatting • Application (dynamic) • User specific designs e.g. simple QPSK/QAM, OFDM, FHSS, DSSS… • Support up to 4 APPs simultaneously (number of APPs is restricted by FPGA size) • APPs can be swapped as needed by users. APPs can either reside in RAM or downloadable through Ethernet port. • Will require partial reconfiguration • RF Port (static) • interfacing to DA/AD • RMAP Processor (static) • Sub-system interfacing • Address decoding • RF SPI Control • Processor Core (static) • 32-bit processor (Microblaze) • interfacing to 32MB DRAM • interfacing to 16MB FLASH

4. CRKit Transport Layers Application domain (dynamic) Framework domain (static) Framework Domain : • ETH Layer – Ethernet Physical layer only, no MAC. Only Ethernet frames with Broadcast MAC or matching destination MAC address are forwarded to IP layer. • IP Layer – only a subset of IP and UDP functions. No support for TCP for data paths as this is implemented in HW. However, the control path does support TCP as this is done in SW e.g. processor core. Note, at this point, IP packets are terminated at the IP layer, we do not forward IP packets further down to APP domain e.g. APP data is “raw”, no encapsulation, unless users want to add another layer in the • Application domain. • VRT Layer – VITA Radio Transport layer, only a subset of VITA standard is supported. We may add more functionality as needed in the future. Note, VRT layer is optional, we may bypass this layer if not used. VRT is particularly useful to mux multiple radio streams to a single pipe, and demux at the other end. Furthermore, it has a standardized radio control messaging scheme. Application Domain : • User Specific Layer - since we are in the APP domain, users have their freedom to add any new layers they may wish. • Wireless PHY – again user specific implementation.

5. CRKit Current Status • Up until recently, we have mostly concentrated on building the static domain of the framework. We did create some simple dynamic APPs to verify and test the functionality of the framework. • Essentially, all major components of the framework are completed and are running live on the LX50 SDR radio platform with our simple APPs (spectrum sensing with FFT block as receiver, and simple switching between noise and sine wave generator as transmitter) • Obviously, we still have some bugs here and there which need to be addressed, but in overall the framework is stable. Upon radio bootup, we are able to request an IP address through DHCP. All initial network configuration related traffic are routed to and from the processor core. Once a network based link to the host machine has been established, we are • able to send control messages to the CRKit to configure the HW and RF. Furthermore, spectrum sensing data (energy level of each FFT bin) are forwarding back to Host for further processing. • Moving forward, we plan to build more advanced APPs. We have recently kicked-off a Cognitive Radio related project using the framework, we have a couple of undergrads working as their senior year project. The overall goal is to build a radio system which can automatically detect which channels are available, and autonomously switch to the same available channel. The challenge resides in the fact that both radios must make decisions independently and establish a link through some discovery algorithms. To build such cognitive radio system, we must have the following functions : • QPSK/QAM Rx and Tx APPs • Spectrum sensing APP • Simple medium access control scheme based on for ex. ALOHA/TDD • Algorithms to detect and select available channels • Algorithms to establish a link to the other radio (using for ex. beacons) • Software work at both CRKit and Host level.

6. CRKit Future Directions • Short/medium term goals : • Port Framework to LX110 SDR and SX95 WDR platforms. The WDR platform has a different DA/AD interfacing scheme, which include a more elaborated clock architecture. The goal is to make the framework as transparent as possible to the underlying hardware. This work has commenced already. • Develop more APPs, including integration of CU OFDM design into the APP domain. • Feedback information from APP development to improve further the Framework with emphasis on APP domain clock architecture and partial reconfiguration. • APP domain clocking scheme should be flexible and programmable by user, either through programmable DCMs/PLLs and/or clock enables. We will need to fully understand the limitation of APP clocking ability for APP developments, and look for potential ways to alleviate the deficiency. • Since the Static domain clock is fixed, whereas the APP domain clocks are programmable. We will need to add a clock abstraction layer between the Static and Dynamic clock regions e.g. clock domain crossing. This should be transparent to the user as users should be unaware of the clock domain transfer. • Look into partial reconfiguration options in further details. What are the protocols required to initiate APP swapping ? What are the limitations of partial reconfiguration ? • Add a simple switch at the interface between APPs and RF ports. APP data can be routed to any RF front ends. This should part of the Static domain.