The 5G Design Dilemma

Nothing says low power and high performance like an emerging wireless standard that promises to increase link bandwidth, latency, and overall capacity by orders of magnitude while also reducing power. That emerging standard, of course, is 5G.

With the number of devices that are projected to use 5G, it’s no surprise that 5G is a strategic initiative for many companies. This explains why design starts for 5G silicon are happening now, even though the deployment of 5G isn’t expected to start until 2020 or later.

In fact, some flavors of 5G silicon are already appearing. “5G-ready,” “5G-aware,” and “5G-capable” silicon and networks have been announced. However, it’s those qualifiers of “ready,” “aware,” and “capable” that hint at the challenges.

Designing silicon before the standard
The challenge of developing silicon while the specification is still underway is not unique to 5G. For example, the newer 802.11 Wi-Fi standards (“ax” and “ah” come to mind) have also had similar challenges.

On the business side, there is a huge market advantage to being among the first to deliver silicon or IP for a new standard, especially one as far-reaching as 5G. At the same time, early design work is a risky endeavor. Some assumptions must be made about what the final standard will look like in order to start designing hardware. Then, if the standard moves in an unexpected direction, the design work may not be viable in production silicon supporting the standard.

So, how do companies balance the risk and reward in early development of 5G silicon?

As with the early silicon supporting the newer Wi-Fi standards, many if not most of the companies doing early 5G design work have adopted a digital design and verification flow starting with high-level synthesis (HLS).

When using HLS, the digital design is described in C++ and SystemC, and the HLS tool creates the RTL implementation based on the design constraints, performance targets, and target technology library. That means one piece of IP written in SystemC for HLS (“HLS IP”) can be used to create multiple RTL implementations. For wireless standards like 5G or WiFi, that means the same HLS IP can be targeted for different end devices, such as a wearable, a phone, and a base station or router.

More to the point of risk mitigation, the HLS IP itself is easy to change. Because it is written in C++, the algorithm itself can be changed to reflect changes in the specification. The designer need not try to determine how, or if, to change thousands of RTL “always @(…)” blocks to reflect the specification change. Instead, the change is made in the C++ and the HLS tool automatically creates new RTL implementations that reflect the new functionality.

5G: the perfect storm for HLS
It shouldn’t be surprising that HLS is being used for 5G digital designs because 5G may be the perfect application space for HLS. Here’s why:

• Leading companies are designing 5G silicon in advance of the standard, requiring a flow that mitigates the risks of a changing standard.
• Functionally similar IP will be used in devices with widely varying power and performance targets, ranging from IoT sensors through base stations.
• The HLS technology itself has evolved to not only support the DSP portions of the hardware (filters, beamforming, etc.), but also the controller and switching portions.

In fact, this explains why HLS is widely used to develop silicon for all types of emerging standards and specifications, including wireless, video, imaging, and even processors. It will be interesting to watch 5G continue to unfold.