Presentations at the Electronic Design Process Symposium (EDPS) April 18, 2013 gave a realistic look at the promises and limitations of electronic system level (ESL) design. Speakers noted that ESL tools are used for the lower levels of the software stack, but typically not for applications development. There is no magic tool that will fully automate hardware/software partitioning. Even so, ESL technology can be of tremendous value if properly used.
Now in its 20th year, EDPS is a small but influential IEEE workshop that brings together movers and shakers in the electronic design methodology community. Cadence was a gold sponsor this year. ESL presenters and panelists were as follows, as shown left to right in the photo below. Gary Smith, chief analyst at Gary Smith EDA, moderated the panel that followed the presentations.
- Guy Bois, founder and president, Space Codesign
- Frank Schirrmeister, group director of product marketing for the System and Software Group at Cadence
- Michael McNamara, CEO, Adapt-IP
- Gene Matter, senior applications engineer, Docea Power
- Gregory Wright, member of technical staff, Alcatel-Lucent
EDPS keynote speaker Ivo Bolsens, CTO of Xilinx, was not officially part of the ESL session - but his keynote was a great lead-in to it. Bolsens talked about the "all programmable SoC" and pointed to the Xilinx Zynq-7000 Extensible Processing Platform, noting that it has programmable logic, I/Os, DSPs, and CPUs. This platform, he said, provides "different levels of programmability so you can tailor the platform to the embedded apps you are targeting." He also talked about the Xilinx Vivado high-level synthesis tool and its role in hardware/software development. Bolsens' presentation slides are available here.
Is Hardware Driving Co-Development?
Frank Schirrmeister's talk was titled Embedded HW/SW Co-Development, It May Be Driven by the Hardware Stupid! "The interesting question is how relevant the hardware is to different pieces of software on the stack," he noted. His answer: software development has a strong hardware dependency at the driver, OS, and middleware layers, but not at the applications layer. Thus, hardware/software co-development takes place at the lower levels where the hardware dependency is strong.
With over 2 million apps in the apps stores, he noted, there is a huge number of software developers in the world. But these developers aren't using ESL tools and aren't generally aware of the underlying hardware. This is particularly true with HTML5, where software development requires only an OS simulator.
"We need to realize that a lot of software can be developed without hardware knowledge," Schirrmeister said. "Hardware/software co-development remains at the lower level - drivers, OS, middleware. No reason for despair - there are a significant number of users in that domain. Just be aware they aren't the Angry Birds developers."
Schirrmeister, who manages the Cadence System Development Suite, also talked about the importance of choosing the right hardware/software co-development platform for the task. He reviewed the advantages and limitations of virtual platforms, acceleration/emulation, RTL simulation, and FPGA-based prototyping (summarized in the chart below).
Guy Bois gave a detailed presentation about Space Codesign and its Space Studio ESL tool, which currently works with FPGAs and provides input for the Xilinx Vivado tool. Space Studio provides algorithm development, architecture design, function mapping and partitioning, performance analysis and evaluation, and co-synthesis of hardware and software.
More Abstraction Needed
Gregory Wright said he found the contents of the opening talks (Bolsens, Schirrmeister, Bois) "very scary." Why? "From the standpoint of trying to build these systems and cost pressures we're under, I'm worried. I'm fully supportive of moving towards software-driven implementation schemes. But I'm worried about addressing an increasingly narrow portion of the available pool of programmers." Many programmers these days, he noted, are not using C/C++, but that's what ESL tools target.
Wright said that "we love the Zynq, we're building products on it." But the SRAM is hard to use, and "we're not getting stuff out the door faster." What's needed, he said, is a higher level of abstraction on the hardware side, so we can get to an environment where software people are comfortable putting together the hardware blocks.
Michael McNamara introduced Adapt-IP, a new company that provides system-level design tools and techniques for deploying and configuring semiconductor IP. For each standard protocol or accelerator, the company provides a soft RTL model, firmware, a device driver, and a virtual platform model. IP is customized for the requirements of a particular project.
Gene Matter discussed the need for power and thermal modeling and simulation, and noted that the greatest potential savings are at the electronic system level. It's important to couple the thermal model and the power model with actual workloads, he said, and co-simulate with a high-level model. "We need a higher level of abstraction to start with, but you need to drive it all the way down and track the level of implementation," he said.
Presentation slides for the talks described above are available at the EDPS web site.
Panel Questions and Answers
An hour-long panel session following the presentations allowed audience members to closely question the presenters. Here are a few of the comments I found interesting.
Schirrmeister - With EDA in its current form, with the current engines, there is no way to address [applications] software developers. An HTML5 apps developer for Angry Birds just needs an OS simulator for that. EDA is still needed for the hardware underneath.
Audience member - HTML5 is not a panacea. It can't interact with a GPS, accelerometer, or hardware components needed to power a game. A lot of people are saying incorrectly that HTML5 will solve all our problems.
Question - Why is hardware/software partitioning still hidden behind a black box? Can we automate it?
McNamara - You need to have a domain expert in whatever area you're going into. They know from experience where the bottlenecks are and what system configuration is needed.
Gary Smith - There are two places where hardware/software partitioning happens. That's because we have yet to give the architect the power information he needs to make his decisions. So the SoC guy makes his own decisions, and that really throws off the architect. The architects I talk to say they'll spend a quarter of a million dollars on a set of tools if you can get me that information.
Ivo Bolsens (from audience) - I don't believe there is an ultimate tool that takes software and figures out where the boundaries between hardware and software should lay. But the big challenge for combining hardware and software is in the plumbing that's involved - it's a communications question. That's where the tools come in.
Matter - Another thing about hardware and software -- just because you have a performance enhanced system doesn't mean its energy enhanced. I've seen a lot of designs where they use techniques that are abhorrent for low power operation. Polling is death!
Schirrmeister- There are different ways of making hardware available early for software developers. The lower you get in the software stack the more hardware you need to see. Markets where [hardware/software co-development] is most applicable are mobile and consumer markets - anything loud, that makes pretty pictures, or is colorful.