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 : 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) 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. 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. • VRT Layer – VITA Radio Transport layer, only a subset of VITA standard is supported. Add more functionality as needed in the future. Note, VRT layer is optional, we may bypass this layer if not used. VRT is useful if muxing multiple radio streams to a single pipe, and demux at the other end. Furthermore, it has a standardized radio control messaging scheme.

5. CRKit Current Status • Up until recently, we have mostly concentrated on building the static domain of the framework. We have some simple dynamic APPs to test the static section of the framework. • Essentially, all major components of the framework are completed and are running live on the 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 minor bugs here and there which need to be addressed, but in overall the framework is stable.