Get email delivery of the Cadence blog featured here
As part three of the “Making Hardware Design Great Again” series, let’s see how high-level synthesis (HLS) is helping designers create SoCs for WiFi, Bluetooth, and 5G.
A common challenge in all three wireless spaces is that their standards are evolving… rapidly. Each new specification, or sub-specification, opens new opportunities. It’s a good opportunity for companies to establish themselves as providers for the new standard. On the flip side, it can also be a negative opportunity for the current leaders if they give up their leadership position by not being one of the first providers.
For example, let’s look at Wi-Fi. As of April 2017, IEEE has eight additional 802.11 projects (evolving standards) underway. Each of these presents opportunities, good or bad, for SoC providers.
IEEE Std P802.11ba
Wake Up Radio
IEEE Std P802.11az
Next Generation Positioning
IEEE Std P802.11ay
Next Generation 60GHz
IEEE Std P802.11ax
High Efficiency WLAN
IEEE Std P802.11ak
IEEE Std P802.11aq
IEEE Std P802.11aj
China Millimeter Wave
IEEE Std P802.11ah
Sub 1 GHz
(Source: IEEE, http://www.ieee802.org/11/Reports/802.11_Timelines.htm)
Similarly, Bluetooth is undergoing rapid development. Bluetooth 5 was just adopted in December.
5G is still in the early phases, but targeting a much-anticipated 2020 rollout. To that end 3GPP anticipates a functional freeze date for the 5G standards with stable protocols in September 2018.
For now, it’s the wild wild west when it comes to determining which protocols and waveforms will be used in 5G. A Google search about this will give you all sorts of 5G information. If you prefer an “all-in-one” collection, I have found Signal Processing for 5G: Algorithms and Implementations, edited by Fa-Long Luo and Charlie Zhang to be a good resource.
It’s tempting (and easy) to suggest that it’s all about a productivity boost, the implication being that HLS-based design and verification enables a shorter turnaround time from specification to hardware. But when you talk to these designers, you realize that’s not the actual value…
So let’s go back to the our five design steps once again, and I’ll relate some anecdotal data.
1) Get requirements from management and marketing
In this case, everyone knows the requirements are most likely going to change, so this isn’t a surprise.
In some cases, part of the requirement is to produce an SoC in advance of the final standard. In some cases, this is simply a business requirement, as in “we shall be first to market.” In other cases, it’s even more interesting. Hardware developed in the early phases of a new standard is done, in part, to help advance the standardization process. It moves the process forward from theoretical analysis to empirical analysis.
2) Understand and clarify the requirements
When the early hardware is part of the standardization process, the design team may be explicitly asked to make (and document) pragmatic decisions required to flesh out the hardware. For example, they may need to fill holes in the standard, or consider multiple options.
By working with high-level models (SystemC, C, C++), the design team can analysis a broad spectrum of options in detail, getting hard data on each. Feedback from this design analysis directly or indirectly becomes feedback into the standards body. This feedback is especially valuable when provided with empirical data from the next two steps…
3) Consider multiple options to implement the hardware
4) Prototype the best options
In some cases, the empirical feedback on the options is the highest value deliverable, as it helps steer the standardization process.
5) Implement hardware
As I previously explained, after the above steps, you already have an implementation that can be committed to hardware. That also means you already have an implementation with which the verification team to begin work. In the case of hardware design for an emerging (pre-ratification) standard, the likelihood of a significant change to requirements is high… very high.
To make it worse, that “lightning bolt of change” can hit at any moment, and it’s likely it will hit more than once. That is, multiple changes throughout this process.
By using high-level synthesizable models throughout the process, from design analysis through implementation, these inevitable changes become manageable. Or at least, they are more manageable than before. Make the changes in the original model, and then “turn the crank” with HLS to synthesize one or more implementations.
THAT, I’m told, is the true value of HLS when designing hardware for emerging standards. The entire design and verification process becomes more nimble.
This three-part series focused on how hardware design is better when using high-level models and high-level synthesis. It produces better results, and it is also more fun than coding thousands of lines of RTL.
I have one other suggestion for some real fun.. put on your headphones and click on The Escape Club's “Wild Wild West” music video. Allow yourself four minutes and five seconds of nostalgia during your otherwise hectic day.