Is hardware/software co-development ready for prime time? Yes, but much remains to be done, according to panelists at the May 12 EE Times System on Chip "Virtual Event." Panelists discussed hardware/software partitioning, benefits of co-design and co-verification, barriers to adoption, what's realistically available today, where models come from, and what's missing from tool sets.
The panel , titled "Hardware/Software Co-Design, Co-Verification, and Integration," was moderated by Clive "Max" Maxfield of Maxfield High-Tech Consulting. Panelists included:
The one-day virtual conference, sponsored by Cadence, also Included a panel on high-level synthesis, a panel on IP/SoC integration, a webcast on the emerging DDR4 standard, and a keynote speech by veteran EDA investor Jim Hogan on SoC Realization. A listing of blogs about these events is located at the end of this post.
Here are some of the questions - and answers - that I found interesting in the hardware/software co-development panel.
Q: When faced with a function that can be implemented in hardware or software, how do you decide which way to go?
Avinun: Software functions are programmable and it is easier to change them. Hardware functions are more restricted but can provide better performance. You can have multiple options - from fixed hardware, to programmable logic, to designing your own processor. You can design software at a very low level or go up to the applications level.
Black: Try to keep as much as you can in software because there is a lot of flexibility. The big question becomes, how do you know if the performance is adequate?
Bailey: It's not just a choice of hardware of software. It could be something in between like an FPGA. We are looking at a continuum of possibilities, not just two extremes.
Dare: Remember that the choice of hardware or software impacts your verification.
Q: Why are co-design and co-verification necessary? Who benefits the most?
Bailey: One thing that's really changed in the last ten years is the level of software. It used to be that you only needed to do co-verification on your drivers. That's not the integration level any more. What's needed now is the integration of the hardware and software functionality.
Avinun: At the end of the day the benefit is in the product or user experience. That's what really translates into revenue. Otherwise, you have different teams doing excellent jobs in their own domains, but when you've integrated it all together you get a surprise.
Black: The software group is the biggest benefactor of co-development, because it allows them to provide feedback into a hardware process. However, the verification group wins too, because they get to see how the software uses the hardware. They can use the software to drive things and get a better sense of what needs to be verified.
Q: Hardware/software co-design seems like it's still in a research mode. What is actually available?
Dare: I would advise people to have a fresh look at what's available now in terms of design methodologies. We have virtual platforms, but it's amazing how many people don't realize they are out there now.
Avinun: Tools that automatically partition hardware and software are still in a research mode. But there are tools in the market that allow you to make tradeoffs. What's more important is to have a handshake between hardware and software groups. This interaction between hardware and software designers is what will make or break the product in the end.
Q: What is the correct abstraction level for co-verification?
Bailey: It depends on what you're trying to do. Hardware/software functional verification is probably untimed. Hardware architecture verification is probably approximately timed. Back-end verification will be cycle accurate. There's no one right answer.
Black: A lot of people create four different models. They start out with untimed, refine and move to loosely timed (LT), and finally add approximately timed (AT) or cycle accurate. You need a switch so you can turn those models on and off.
Avinun: If you look at the overall process here, there is no one level of abstraction or tool that can address all the needs. We need to provide a continuum of platforms that are connected and integrated so as you run your software on top of hardware, you'll be able to migrate from one platform to another.
Q: Most designs include legacy IP, third-party IP, and new IP. How do we get all the needed models?
Dare: That is the classic problem. The pessimist in me says you'll have to look and look and look. The optimist in me says this problem is recognized and we have recently seen a lot of people offering design technology.
Bailey: 18 months ago I would have joined Gary in being pessimistic. Everyone had proprietary models. But in the past 18 months, standards have provided the necessary consistency in the industry. As we get standards in place, it becomes more likely that IP providers will start providing the models we really need.
Black: Models are improving and standards are coming out. But not all models are created equal and you have to evaluate what's coming from providers.
Q: What's missing in tool sets and how do we fill those holes?
Avinun: We went to customers during the past two to three years and asked this question. We found that a lot of customers are spending time refining and changing their environments as they move from one tool or one platform to another. We still see, in some cases, that modeling is based on a proprietary format and that customers have to go back to the supplier to make changes. The System Development Suite that we introduced [May 3] addresses these issues.
Dare: One issue that's a little further out into the future, but not that far off, is support for debugging multiple cores.
Avinun: With our virtual platform, we are providing a single debug environment for hardware and software that supports multiple processors.
Black: The Cadence Virtual System Platform tool is excellent for debugging those [multi-core] platforms. But there's still the fact that you may have 12 or 20 different processors and sometimes heterogeneous operating systems, and the engineer has to navigate a minefield. There has to be some thinking about how you can reduce the complexity at this point.
Bailey: Constrained-random [verification] doesn't have as much value as it used to. People are going back to directed testing at the system level. We need to reinvent whole methodologies to make verification more efficient.
Q: What's the biggest impediment to adoption of hardware/software co-development?
Black: It's the organization of the company and its culture. Too often groups are centered around hardware or software and don't communicate well. It really requires a higher level of management insisting that this work. It's not a technical challenge, it's a management challenge.
Bailey: We see more people using [co-design] than we give it credit for. But it's still at the leading edge. For some companies the problem is not complex enough for them to migrate.
Q: What will the optimal verification environment be like in 10 years?
Dare: In most verification environments today prototyping runs slower than the actual product. What if you could turn that around and have live prototypes running at speed, where boundaries between simulation and emulation disappear?
Bailey: Today everything is bottom up. We need to turn that upside down and do it without a lot of redundancy.
Avinun: Apps are driving design, and you will see more situations where a systems company will say, this is what my customer needs from a verification point of view. Who can make the best user experience? Who is the best provider to create this? A lot of this work will be done in advance rather than at the end.
Other blog posts about the EE Times SoC Virtual Event:
The DDR4 SDRAM spec and SoC design. What do we know now? (Steve Leibson)
Jim Hogan details his views of SoC opportunities and again reveals his SoC Realization investment shopping list (Steve Leibson)
Panel Discussion: Applying High-Level Synthesis in an SoC Flow (Jack Erickson)
Panelists Discuss Solutions to SoC IP Integration Challenges (Richard Goering)