User Perspective: Hardware-Software Co-Design

By Ann Steffora Mutschler
With software teams today twice as large as hardware teams for any given complex SoC project, there is no doubt it is an ideal time to agree on the best way for these worlds to intersect. And even though the semiconductor industry has been actively discussing hardware-software co-design for at least a decade a mainstream solution has yet to be commercialized.

Progress is being made, however. Philippe Magarshack, general manager of central CAD and design solutions and design enablement director at STMicroelectronics, shared his thoughts with Low-Power Engineering.

Magarshack pointed out that ST has been leading the methodology paradigm shift from having a sequential set of activities where hardware is designed first, and after silicon is obtained then software development would be started. Now, he said, ST works in a much more parallel fashion where the IP and SoC hardware are modeled earlier. This allows ST’s hardware engineering team to provide very high-level, typically transaction-level, models to the software team such that the software can start not exactly at the same time as hardware but maybe one quarter behind hardware development starts and literally three or four quarters before silicon.

“The paradigm shift enablement is performed when we proposed to the rest of the industry this level of function called transaction-level modeling–TLM–which is built onto a SystemC syntax. Not only did we propose this new paradigm, but we also structured it initially in a standardization committee body rounding up EDA partners, other system houses and eventually this was transferred into Accellera where it is now in very good hands in terms of evolution,” Magarshack explained.

Another challenge that comes into play here is that IP is very complex and typically a processor core or peripheral IPs have to come equipped with software drivers; engineers developing the IP now need to have this development environment such that it is not only hardware but software. As such, ST is working to standardize the development and verification methodology for IP developers as well as the methodology to stitch together the IPs not only in the hardware world but also the software world, he pointed out.

Low-power challenges
Low-power design brings special challenges when doing hardware/software codesign, Magarshack acknowledged. “That’s definitely a direction that we have been working on for a while—not only in wireless but also in the space of consumer starting from the hardware angle and moving up.”

To address the need for low power, he noted that ST developed process-specific solutions like transistors, capacitors, resistors and power switches that are tuned toward bringing low-power solutions for wireless products. “On top of that we develop hardware IPs that are very much tuned for low-power. For instance specific RAM compilers or analog blocks like PLLs. Also, we eventually build a whole model of the SoC that is not only a functional model but is also a power-aware model. This is at an abstract enough level that we can actually run some software and typically get some indication of what the power consumption is of this particular piece of software on the hardware. By having an elaborate debug methodology we are able to look at where most of the power is consumed in the software and find out what can be done differently either in the software or in hardware to get to better power consumption.”

While not quite yet in production, ST is in prototyping mode in terms of methodology that allows the software developer to at last be aware of the impact of software development before the silicon comes out of the fab.

At a higher level, Magarshack also shared his thoughts on the top three challenges today with hardware-software co-design. “The most difficult challenge I can think of is the fact that culturally, hardware developers don’t function the same way as software developers. That’s really the number one challenge—to put together people that have different ways of working. With software, even after it is released to the customer you can fix a bug in five minutes so bugs are not as important and there is a constant stream of fixes that is possible. With hardware designers, if there is a bug on silicon the cycle time to fix it is three or six months. Just this simple difference brings a whole slew of different methods in different attention to quality. Attention to the tradeoff between quality and innovation and risk is very different. And when you bring those two communities together, we do see that it is a very big challenge.”

He observed that in some sense hardware development is looking more like software because engineers are writing RTL code, and this is very similar software. While this may be true, “at the end of the day you have to freeze the whole thing out to silicon and if there is a single bug this is typically a three to six month cycle time to fix that.”

The next challenge is that because engineers are used to working sequentially, to suddenly have to work in parallel requires addressing a stream of dependencies that are different. “There is back and forth and haggling that happens, so in terms of project management this is a much more complex scenario that you have to manage,” Magarshack explained. “The good consequence is that at the end of the day it saved two or three quarters.”

Finally, looking at tooling, he believes the next frontier after reasonably solving the problem of functional code design and code verification between hardware and software, is definitely power-aware design for low-power simultaneously of hardware and software.

Again, while a prototype solution exists within ST, he reiterated that it is not a fully streamlined tool. Still needed is some standardization and definition of the right format and syntax. To this end, ST is working on an extension of the System C language to enable that.

But it is safe to say it will be another five years until it reaches the designers desktop, Magarshack added.