Heard at DAC: is IP integration the real high-level design?
In the continuing debate over system-level design, one seemingly important aspect of the question is often overlooked. Using a dialect of C to model an SoC at behavioral level and then synthesizing the model into RTL is not the only possible way to increase the level of abstraction at the beginning of the design process. For many design teams the most important abstraction is encapsulated IP-treating blocks of IP, often from third parties, as nearly black-box representations of functions during the design flow.
Heavy IP reuse can substantially alter the design flow, changing it from a process of successively recreating the system at decreasing levels of abstraction to a process of integrating an assembly of functions based on rather limited information about their implementation. So it is not surprising that the challenge of IP integration and its relationship to system-level design became recurring themes in the Management Day track and its concluding panel at the Design Automation Conference last week.
The discussion began in presentations by engineering managers earlier in the day. In his presentation Qualcomm senior director of engineering Karim Arabi said “Design creation is not the bottleneck. We are spending an increasing amount of time on integration, not on design. We need IP that we can plug in and use, and we need tools that automate the integration process.” Arabi went on to say that as IP blocks grew into subsystems, the integration problem was simply moving inside these new megablocks. “We may have a modem subsystem that itself is made up of many IP blocks,” Arabi said. “They still all have to go through the integration process.”
The topic resurfaced at once in the panel discussion. Asked what-if any-respite the panelists saw for the growing resource crunch on design teams, LSI director of technical marketing Robert Madge cited design reuse. Arabi added his call for integration automation. No one mentioned high-level synthesis.
Asked further to elaborate on the balance between block design and integration, Applied Microcircuits director of central engineering Jitu Kahne estimated that on short designs, 80 percent of the chip is reused IP, and perhaps 15 percent comes from within the company. Between 60 and 70 percent of the project is IP integration, Kahne said, and better tool support for this task could significantly shorten the design cycle.
Arabi agreed, saying that often 80 to 90 percent of the IP in an SoC is unchanged from the previous design. “But we still have to do the whole integration cycle. There are no tools to automate qualifying or integrating IP, and when you have to make changes the process becomes manual.”
Rather surprisingly, Intel strategic technology solutions manager Michael Jassowski said that IDMs struggle with IP integration as well. “If you have your own processes you have to develop much of your own IP,” Jassowski said. “But Intel is going through a mind shift. We have a central IP development team, and the problem for the chip design teams is to reuse the IP instead of following their instincts and tweaking it. Altering reusable IP is destroying value.”
Ken Wagner, vice president of engineering at the Communications Products Division at PMC-Sierra, also zeroed in on the IP integration, but citing the IP itself as the main issue. “I think tool vendors might be surprised to hear there is no support for IP integration,” he objected. “IP-Xact, for one, is out there. But the IP itself is often a mirage. Getting third-party IP to work is a large effort-in our experience, it is 30 to 50 percent as much work as doing an internal design. Hard IP requires more effort than soft IP”
Arabi was equally critical. Third-party IP quality is poor,” he generalized. “It turns out that whatever you ask for from the IP vendor isn’t really there. We prefer to do our design internally if we can afford it.”
Khane added that Applied was trying to build clusters of IP that could be treated as a single block, reducing the scale of the problem. But LSI’s Madge said that in the end, the key to understanding IP was to see it as a design collaboration, not as an off-the-shelf product.
Even through the panel was critical of IP integration, the panelists clearly didn’t see high-level synthesis as an alternative, at least in their worlds. “It’s very early still in the development of high-level synthesis,” Jassowski offered diplomatically. Wagner added, “High-level synthesis is still domain-specific. And there are unresolved issues in using it within a flow, such as equivalence-checking and verification.”
“The biggest value of high-level design,” Arabi said, is that it forces an early start to verification and software development. But then it makes the ECO process very hard.”
If the statements of the panelists are in any way representative of leading-edge design practice, there should be a message here to the EDA industry. First, IP still has not met the promise it made to the industry nearly a decade ago. Plug-and-play functional blocks are still a fiction. More accurate perhaps is to say that IP blocks have become the behavioral requirements specification for a joint development to be executed between the chip design team and the IP vendor. Thus IP should be qualified as one would evaluate a design partner, not as one would evaluate a component. Further, IP integration, including the struggle not to have to pry open the blocks, has become the dominant, and least-automated, activity in front-end design. There is a need there, so much so that design managers are vocal about it.
And finally, EDA vendors need to understand that despite their latest state-machine synthesis algorithms and visions of high-level verification, design managers still see C-dialect descriptions of blocks as point tools with specific uses in the design flow, and applicable only to specific sorts of blocks. Telling them otherwise, or spinning scenarios of high-level synthesis at the chip level, is speaking against their experience. More to the point might be to recognize that high-level synthesis remains a point tool, and to explain how to conduct the integration process when the blocks include both third-party soft IP and soft blocks synthesized from high-level code. Given the universal concern about tracing-back design data into the high-level environment, that could be an entertaining discussion.
Mohamed Salem commented:
IP integration would be resolved if IP vendors provide IP sub_systems that include but not limited to:
Digital Controller
Digital PHY layer front end
PHY Analog layer
Application Layer (Firmware) that ships in transactions and scenarios that state the various protocol behavior.
VIP interfaces that validate and monitors the legal and illegal behavior of the IP sub_system
In other words, ESL would be looked as bundling IP low components into sub_systems.
This would reduce the verification effort into the SOC as integration involves extra verification efforts that has been taken into account in separate IP parts but sub_system would uncover these issues and respond to it by an additional validation effort before shipping to customers for integration. Hence IP Sub_Systems would be a positive trend towards an easier smoother integration.
Raimund commented:
garydpdx, without having checked the mentioned paper: can these tools really do an automatic (!) creation and optimization of the interconnect just based on band-width and latency requirements of the IPs + constraints of clock frequency of the interconnect + constraints/features of the memory system? In addition the NXP tool is certainly not a commercial one I could buy for my company, isn't it? But thanks for the hints anyway.
garydpdx commented:
Raimund, see papers by NXP from the past IP (IP-SOC) conferences ... they created an in-house tool called NxBuilder, built atop Platform Express (from Mentor Graphics), which processed the IP-XACT information and within the tools (not part of the IEEE 1685 standard), interpreted it including extra data for configuration of IP's including interface sizing. Other tools from Magillem and Synopsys could be used this way, maybe using slightly different approaches, check out their papers as well!
Raimund Soenning commented:
Ron, I'd like to bring up another thing here: one of the major challenges of today's SoC integration is the interconnect (or NoC) between the IPs - to get the right trade off between performance, area and power here. I do not really understand why this field is not addressed by design automation by I would call it "interconnect synthesis". This is another form of HLS - so to say - but you just need to pick from a library the right blend of arbiters, routers, bridges and so on. You can do it with e.g. AMBA designer but only in manual way. I'd like to see a tool where I just specify the interface features of my IPs (bus standard, bus width, etc. - ideally described by IP-XACT or similar standard) and their bandwidth requirements and the tool does generate the best optimized fabric for me. I have seen academic work on this at DATE 3 years ago but nothing has been turned into a usable product yet. I don't think that the HLS tools of today can handle this as they are purposely made for a different area. So, I still hope that some EDA company will come up with a solution here. But maybe I am the only one ...
garydpdx commented:
IP in a design is an 'object' that can be modeled as both ESL and RTL for reuse in both the system and circuit level of design. If your FFT function comes from library XYZ, ideally you would have a SystemC representation as well as a Verilog or VHDL. Rather than run the SystemC through HLS (e.g., Catapult, etc.), you map to its RTL representation. Ken Wagner of PMC-Sierra remarked on IP-XACT (IEEE 1685) but that doesn't exist in isolation. Resources need to be applied at some point in the IP supply chain to create the XML file documenting the IP along the IP-XACT schema, and EDA tools (e.g., Magillem, Synopsys, etc.) make use of that information. See past papers from the IP (or IP-SOC) Conference in Grenoble by NXP or STM, on how they used it.
Steve Cox commented:
Intel's Michael Jassowski's comment ("the problem for the chip design teams is to reuse the IP instead of following their instincts and tweaking it. Altering reusable IP is destroying value.") points out the natural tension between IP development and IP (re)use. For anything other than standards-based IP, it is nearly impossible for any IP development team to imagine the requirements of all of their customers (whether internal or external). This reality puts the IP integration team in a pickle. Is it more valuable to use the IP as is, even if a more suitable/powerful/efficient solution is possible? Or is it better to "tweak" the IP to improve its functionality/performance/efficiency for this particular use case (and eliminate the "pre-verified" value that the IP offers)?
Fortunately, there are options for adding "flexibility" into IP from the start. One such option is to implement the IP in the form of an ASIP (Application Specific Processor). By offering a programmable method for IP customization, the integration team can tweak the functionality of the IP by changing the software that runs on the ASIP. IP built in such a way is a win-win situation, because the integration team is more likely to avoid RTL changes, and the IP development team is more likely to satisfy a wide audience of customers/users.
Mark De Souza (ChipStart) commented:
We (ChipStart - www.chip-start.com) are well into one solution to these issues with an EDA tool that can churn out the infrastructure side of a chip in under 2 days - leaving the design team to work on their secret sauce. Our SoC System Manager then provides control from application software to the chip to help keep everything efficient & stable.
We are ready for beta customers ....
sos commented:
test. do these comments actually work?
Bill commented:
ESL and IP are hitting at the same type of issues (faster exploration, implementation and verification). Neither is a perfect solution at this point and varies greatly from supplier to supplier. But I seriously doubt that ESL will ever replace IP. In fact, I could argue that IP could replace ESL at some point. Look at the various custom processors that have been developed over time (ARM, MIPs, various GPU’s from NVidia/ATI, etc). Over time, software based solutions get hardened into hardware. So if an idea does take off that is created using ESL, at some point, this will be hardcoded to improve area, power and performance; even if ‘silicon is free’.
As one of the panelist above stated: once you change a purchased IP, much of the value it lost. You have lost all the verification AND the certification that was achieved. If the intent is to lower risk and time to market, why do something contrary to these goals by modifying IP that was purchased. In addition, IP can be sold as a service or as a product. I believed in IP is a Product since it requires exhaustive testing to create a component that can be purchased by many customers. The only service I wanted to supply was bug fixing (and if we did our job correctly, we would become ‘Maytag’ repair people).
Others successfully use a Service based offering but these are custom contracts for each customer. Analog Bits is a great example of this. For each customer, they develop specific IP to meet a specific need. Either can work but you need to understand how the supplier views their IP: product or service. I bet AB will state they are an outstanding service provider that creates custom IP for specific product specifications and not an IP product company that sells the same IP to all their customers.
If you get a company that tries to straddle both sides of IP (product AND services), I would quickly walk away and find another vendor. In these companies, I would question whether the product is robust and high quality and the quality and repeatability of the services provided. It is very difficult to focus on both and be good at both.
In the end, whether you purchase an IP product or service, you really need to trust the vendor and make sure they will stand behind and support what was sold. These purchases are too critical not trust your suppliers. Once you develop a trusting relationship with an IP supplier, protect it like a golden egg.
