Designing a Wi-Fi HaLow Baseband in Less than Six Months

At CDNLive EMEA last month, Stefan Stanic of Methods2Business (M2B) presented The Challenge of Designing a First-TIme-Right Wi-Fi HaLow Baseband in Less than Six Months. WI-FI HaLow is a standard for superior IoT connectivity. Links can be up to 1km, with superior connectivity through walls and other obstacles. It is low power, intended for mutl-year battery operation in edge devices. The data rates are "moderate" meaning several Mbps but fast enough to support standard internet connectivity protocols like TCP/IP. M2B has designed a scalable MAC and baseband (BB) platform with an embedded Tensilica core for the MAC firmware. The focus of the presentation was the baseband. Another challenge was that this is new technology, so there are no reference designs, so no existing devices that implement the protocol to use for testing.

The biggest challenge is having an aggressive schedule: to be first, and to be right. To make it more complex, they wanted to have two versions starting from the same design. One high speed and high throughput, and the other ultra-low power.

The project was kicked off in July 2018, and by August 2018 they had a MATLAB floating-point model. They validated that in September 2018 at a WiFi Alliance test event. This MATLAB model became their golden reference model for UVM verification as the project progressed. By January 2019, they had a fully implemented baseband integrated onto the M2B Wi-FI Halow FPGA system with a radio and successfully participated in the Plug Fest. Along the way, they developed a new hardware design methodology.

The methodology relies on Stratus high-level synthesis (HLS) and virtual platforms to have a parallel hardware and software development process. There is a formal and UVM-based verification embedded in a SystemC design flow. There are basically three tracks through the methodology, as you can see in the above diagram: software modeling, hardware modeling, and verification.

The baseband doesn't contain software so has a pure hardware design flow, as shown in the above diagram. Starting from the golden MATLAB model, there are two tracks: Stratus (design) in the upper tracks, and UVM (verification) in the lower track. In the end, there is verification using FPGA and over-the-air testing using a real radio. This led to a dramatic design cycle reduction.

The various phases were:

• MATLAB model, phase 1, floating point
• MATLAB model, phase 2, fixed point with hardware (basic pipeline, memories, etc)
• SystemC model, phase 1, behavioral
• SystemC model, phase 2, synthesizable

Over the period, using Stratus HLS and code optimization, they reduced the area of the design by a factor of 3, as in the graph.

The design worked at the January Plug Fest. Lessons learned:

• Validation checks are performed on all three abstractions levels and after every Stratus optimization run
• Single unified SystemC model was able to run on both behavioral and RTL levels of abstraction
• Less code. SystemC contains a lot less code that equivalent RTL
• Fast and easy debugging. Faster simulation time, more agile debugging method (using SystemC compared to an RTL-based methodology)

The diagram above shows the difference between the SystemC methodology and an equivalent RTL methodology, from when a bug is found, fixed, and verified. Using this methodology, two implementations were created which both worked successfully. One was 166.7 Kb/s and one was 7.2Mb/s.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email