IP Roundtable, Part 6: Integration Issues Ahead

IP experts discuss why there are no tools and few standards for the integration of IP blocks and what it will take to force the adoption of a more top-down approach.

In the previous segment of this experts' roundtable we talked about the advantages EDA companies may have in developing and licensing IP. Today we turn our attention to IP integration issues. Taking part in today's discussion are: Mike Gianfagna, vice president of corporate marketing at Atrenta; Warren Savage, CEO of IPextreme; John Koeter, vice president of marketing for the solutions group at Synopsys; and Chris Rowen, Cadence Fellow and CTO at Tensilica.

Brian Bailey: There aren't many IP integration tools. Why is that?

Mike Gianfagna: We talk about IP-XACT, which appears to be a robust standard, but who's adopting it? How many people? It's interesting. In fact, we see a lot of customers that resist IP-XACT. I'm not sure why, other than change is hard. There are a lot of scripts out there for chip assembly today. More automation and sophistication is needed. But people change when forced to, not when they want to.

Brian Bailey: Are there no chip integration failures?

Mike Gianfagna: We have a product in this space that does RTL-level assembly, and we're seeing it pick up at a substantial rate. I'd like to say we were genius marketing people, but it's not that. People are starting to see the problem. When you're forced to adopt a new tool, you do, and not a minute before.

Warren Savage: I disagree, to some extent. People have been talking about automated IP assembly for 15 years, and I've never seen it adopted. People ask about IP-XACT, but I've never had a customer ask me for IP-XACT models. My theory is that the demand for subsystems is growing and the complexity of subsystems is growing faster than the EDA companies' ability to deliver a tool. These subsystems involve a lot of different pieces that are not very standardized, not easily expressed with the IP-XACT format, plus you have the software component. The complexity curve on the subsystems is growing faster than EDA can anticipate what they're going to look like.

Chris Rowen: The process of integrating these blocks is so messy and awkward that many users cannot visualize a standard methodology or set of tools that could do it. They think they need to do it themselves. A lot of people think that their problem is unique, and they're not willing to compromise their solution in order to move toward standards. The severity of the problem is tough enough that it is inevitable that they will eventually put themselves in a position where they can compromise.

I think the first step is getting people to adopt system-level modeling in a form that allows them to do both architectural exploration and find out about the traffic flow in their chip. Then that segues into becoming the verification structure in which the individual subsystems can be buttoned up, and becomes the whole chip testbench in which you can do the last round of full verification at whatever level of detail you need. You need the ability to migrate and transmogrify those models to be the universal test bench for everything -- for energy verification and signal integrity and logical correctness and software validation and all the other must-haves that constitute full-chip integration.

Brian Bailey: We have mentioned a couple of times the benefits that would come from a top-down flow. If we take power as an example, where is power specified? We would hope, at the high level, and then it pushes down as requirements into the blocks. But IP is part of a bottom-up process. How do they meet in the middle?

Chris Rowen: The old-fashioned way of doing worst-case power analysis is dead. The old-fashioned way is that you got a power specification for each of the building blocks, you found out what its worst-case power was, you added them all together, and that was your worst-case power. If you did that, you would conclude that no phone could ever work. That's not the way that power analysis is done. You have to look at 10 or 100 different scenarios that constitute the level of activity in each of the subsystems that makes up a plausible use case. This whole process of getting from worst-case analysis, which is bottom-up, to scenario analysis, which is inherently top-down, is an essential part of that transition.

John Koeter: I think you will see software-driven power intent at the TLM level. I think that's inevitable. You won't be able to get absolute power, but you'll be able to get relative power. What you have to do is implement the various power settings that are within the standards. But then you can do things like have dual-rail architectures, you can put in voltage domains, you can do all that stuff to lower your overall power.

Chris Rowen: You have to characterize power when in state 0, 1, 2, 3, 4, and you have to characterize power across different workloads. In a power-sensitive processor design, the active power between the most intensive and least intensive sequence can be as much as an order of magnitude, and therefore it isn't meaningful to say the active power is X on this processor.

Warren Savage: It's a modeling issue that is the frontier here. How, at the system level, can these things be modeled? IP providers are going to optimize their particular IP around whatever techniques or standards are available. At the system level it will increasingly involve the software guys.

It does seem like the basic definition of IP as a building block is the big problem. This locks you in to a bottom up approach. We need a "compiler" that can pull from the "library" of building block components and customize then as required to meet the high level requirements (speed, power, latency, etc). The tool would search thru the solution space to find a particular combination that fits the requirements (or comes back with a 'no solution' result). That's the direction I'd like to see things move...

In that case, please check us out, Space Codesign. We have the capability of going to implementation after algorithm design and validation, and architecture design exploration. Implementation can either map to libraries (e.g., Xilinx for FPGA) or to HLS (high level synthesis - Forte, Calypto, Xilinx, etc.) after design exploration figures out meeting your requirements.

By the way, Guy Bois, our president has a new blog article on this site discussing our approach.