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. • Create standardized software API for RF control using VITA Radio Transport protocol • 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 addresses are forwarded to IP layer. • IP Layer (Fast Path) – Hardware based implementation, only a subset of IP and UDP functions. No support for TCP for data paths as this is implemented in HW. This fast track is reserved for data related traffic requiring direct access to APP domain. Data IP packets are routed to the fast track based on specific UDP port number. 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. • IP Layer (Slow Path) – Software based implemetation, control path does support TCP as this is done in SW e.g. processor core. This slow track is reserved mostly for control related traffic such as CRKit hardware configuration (register map access) and RF control. Any IP packets with UDP port number not matching the fast track UDP port number will be routed to the slow track. • Note : for Address Resolution Protocol (ARP) the IP layer is bypassed, we parse the packets based on Ethernet frame Ethertype field. • 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 • 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). • Upon radio bootup, CRKit requests 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, host can send control messages to the CRKit to configure the HW and RF. • Furthermore, fast data path is also operational (e.g. simple spectrum sensing application data are sent to host). • Slow track is operational based on the network configuration mentioned above.

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. • Integration of CU OFDM design into the APP domain. • Build CR tutorial • Build distributed application that will continuously search for available channels and perform interference avoidance for a pair of radios. The discovery algorithm will be performed mostly on the host while all of the physical layer functions will be performed by the framework application. Requires following functions : Basic modulations (QPSK/QAM Rx and Tx), Spectrum sensing APP, Simple MAC scheme (ALOHA, TDD, etc.), host software APIs and libraries. • Better clock management: • 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. • Partial reconfiguration: • Feedback information from APP development to improve further the Framework with emphasis on APP domain clock architecture and partial reconfiguration. • 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 waveform multiplexing: • Add a simple switch/multiplexer at the interface between APPs and RF ports. APP data can be routed to any RF front ends. This should be included into the Framework static domain. • Port Linux to Microblaze: • Leverage Linux support of complete networking stack • Use uCLinux derivative for embedded processor • VITA API development for radio control