Balancing Emulation And FPGA-Based Prototyping For Software Development

This year’s Design Automation Conference (DAC) has just finished and confirmed some of the trends I discussed in my last blog, “The Top Five Trends in Verification to Watch For at DAC 2016”, specifically when it comes to the set of connected engines, or “COVE” as Jim Hogan dubbed it. The Cadence Theater at DAC is always a good opportunity to listen to hands-on customer experiences, and one of my personal favorites this time around was Amlogic, who showed how they reduced bring-up time of their first software release from by a factor of 5X, from 75 days to 15 days, using emulation and FPGA-based prototyping.

Amlogic is a leading SoC supplier for Smart TV, Over the Top (OTT), and Smart Home applications, and Jerry Cao, their Director for Platform Software, presented on “Pre-Silicon Software Development with Protium/Palladium”. The full presentation will eventually be posted on Cadence’s DAC microsite. Jerry underlined the importance of software as an enabler for SoC volume shipments, conversely delaying revenue if it is delayed. Classically, its delivery and development was dependent on hardware availability. The increase of software complexity is staggering, given the trend towards multi-core, multi-task real-time systems, multiple layers of software from firmware to kernel drivers and complex software frameworks, and millions of lines of code—Jerry showed this graphic on number of lines of code in the Linux kernel spiking above 11M in Linux Kernel version 3.0.

Jerry talked about some of the specific software development challenges and why software use case scenarios can become very complicated very fast. For example, they spent days on a problem where the USB host could not enumerate the device in a real chip despite the VLSI simulations passing by debugging the USB controller. It turned out that the root cause was due to wrong settings in the memory controller’s access policy.

So Amlogic went looking for a system to allow software to jump-start development, a complete pre-silicon prototype system that behaves like the real chip, is able to enable all software development from firmware through kernel drivers and applications, and is available early during silicon design to allow concurrent hardware/software development. One of the key requirements was ease of use—they needed to be able to compile software, download images, run on the platform, and allow multiple users to remotely connect. Speed was crucial as they wanted to boot simple Linux kernels in minutes and full Android in hours. On the software side, debug was important with requirements to support UART and JTAG, memory dumps, and probing of internal signals. They also wanted to run performance analysis to measure system performance and power consumption.

When looking into traditional FPGA-based prototyping, they found it difficult to achieve timing closure, model the memories, and partition the design to map to multiple FPGAs. Overall, the design bring-up was time consuming as they needed to modify the design to make it fit and they were facing limited peripheral availability for USB and video display cards.

Using the multi-fabric compiler technology that unifies the front-end flows for the Palladium and Protium platforms—I have described it in several blogs like “Top 15 Integrating Points in the Continuum of Verification Engines” before—Amlogic built the environment shown in the graphic above. They achieved their main requirements:

• Design bring-up was quick—Required no RTL modification as the Palladium and Protium platforms share same compilation flow and are available as a complete pre-silicon platform as early as RTL is ready
• The setup was scalable and flexible to accommodate future designs and allowed to run multiple small designs concurrently
• The setup also achieved good speed—1MHz on the Palladium XP platform and 5MHz on the Protium platform in fully automatic mode with no manual guidance and optimization, which could improve the speed significantly as we have seen in other customer engagements

In terms of balancing the engines, Amlogic confirmed that they used the Palladium XP platforms for early software driver debug and verification, running minimum software to verify driver functionality and used memory save and restore to speed up software startup. They also partitioned the Palladium platform to run modularized chip design, allowing them to parallelize verification of different software drivers.

For full system verification, they migrated to the Protium platform, booted the entire software stack with Android boot up to display, verified full-system functionality like video decode and display, and ran performance benchmarks like lmbench and Antutu.

At the end, Amlogic concluded that the “Palladium and Protium [platforms] are invaluable to software development”, providing a “turnkey” solution to enable quick prototype bring-up, allowing continuous software development before silicon is back and offering unique debug capabilities to perform root cause analysis. Amlogic also pointed out some of the limitations, such as verification of the analog and differences in the digital to analog interface, but as a result of this flow, the software was ready when silicon returned. They literally had basic Android running in 30 minutes after silicon came back and were able to show full function Android demos within three days, down from 15 days without using pre-silicon hardware-assisted development.

Life is good—and it is great when customers confirm what we product managers thought the value would be! There were other cases at DAC about which I will blog soon…