标签: licence

At the end of the previous instalment of this experts' roundtable, we were discussing the number of IP companies being bought by EDA companies. We continue to explore the relationship between IP developers and EDA companies here. Taking part in today's discussion are 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. EE Times : How easy is it for IP companies to get EDA licences both for compatibility testing and for their development needs? Warren Savage : What you can do with the tools is usually written into the licence agreements. We have relationships with all the EDA companies and licence specifically for the purpose of testing and compatibility. We have built that support into our Xena systems so that customer IP is agnostic. John Koeter : There's a big difference between using a tool for interoperability testing and using the tool to get value from it. That is the intrinsic value of the tool. We have other EDA vendors' tools , and we get great discounts on them. EE Times : Does it give you a competitive advantage because you have a set of in-house development tools? Does Synopsys give you the EDA tools for free to develop your IP, or do you have to factor tool costs into the cost of developing the IP? Koeter : Tools are free for internal use. EE Times : So, I presume that gives you an advantage over the external companies because they have to pay for the tools. Koeter : Yes, certainly. Chris Rowen : It's also an example of the economies of scale. The marginal cost of another simulator or synthesis seat is really just the cost of the hardware to run it on. I think it is a small factor in consolidation. Savage : I would say that, for emerging IP-only companies, EDA is the No. 1 impediment for those companies to compete, especially in mixed-signal. It's gigantically expensive. Rowen : Warren and I have bought a lot of EDA tools. Savage : How much of our budget, our VC money, has gone to the EDA companies? Rowen : How much money? It's huge. The biggest outlays that Tensilica made were to Synopsys and Cadence. I think we got great discounts, and we were treated very well by both companies. There are no complaints. It's just expensive stuff. EE Times : I have heard some IP developers saying that they need scaled-back tools because they don't have to deal with such large capacity or performance . But, as well as reduced capacity and performance, they want reduced cost. Savage : I'm not sure about that. Rowen : I'd say we want whatever the next grade is above whatever they're selling now. I mean, I think our demands in terms of the tools are extreme. Savage : I think I completely agree. There may be some basic cases, but... Rowen : There's a lot of value in those tools, and we'd like more—more capability, faster run times, higher levels of optimisation. There is an infinite appetite in these high-end products for more optimised tools and more optimised flows. They're expensive, but what they do is so essential. I wouldn't put what we do in the category of "Can you give me a cheaper, dumber tool?" I don't need the OrCad of synthesis and place and route to do this. Koeter : If you just look at hardening a processor. You could run dozens of experiments with different floor plans and different constraint files. You know, you have to do that design exploration in order to get the best results. * * * I would love to have other IP developers weigh in on this issue. How crippling are EDA tool costs for IP developers? Do the EDA companies have too big an advantage in developing IP? Brian Bailey EE Times

In the latter part of the previous instalment of this series, we were talking about the number of IP companies being bought by EDA companies. We continue to explore the relationship between IP developers and EDA companies here. Taking part in today's discussion are 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. EE Times : How easy is it for IP companies to get EDA licences both for compatibility testing and for their development needs? Warren Savage : What you can do with the tools is usually written into the licence agreements. We have relationships with all the EDA companies and licence specifically for the purpose of testing and compatibility. We have built that support into our Xena systems so that customer IP is agnostic. John Koeter : There's a big difference between using a tool for interoperability testing and using the tool to get value from it. That is the intrinsic value of the tool. We have other EDA vendors' tools , and we get great discounts on them. EE Times : Does it give you a competitive advantage because you have a set of in-house development tools? Does Synopsys give you the EDA tools for free to develop your IP, or do you have to factor tool costs into the cost of developing the IP? Koeter : Tools are free for internal use. EE Times : So, I presume that gives you an advantage over the external companies because they have to pay for the tools. Koeter : Yes, certainly. Chris Rowen : It's also an example of the economies of scale. The marginal cost of another simulator or synthesis seat is really just the cost of the hardware to run it on. I think it is a small factor in consolidation. Savage : I would say that, for emerging IP-only companies, EDA is the No. 1 impediment for those companies to compete, especially in mixed-signal. It's gigantically expensive. Rowen : Warren and I have bought a lot of EDA tools. Savage : How much of our budget, our VC money, has gone to the EDA companies? Rowen : How much money? It's huge. The biggest outlays that Tensilica made were to Synopsys and Cadence. I think we got great discounts, and we were treated very well by both companies. There are no complaints. It's just expensive stuff. EE Times : I have heard some IP developers saying that they need scaled-back tools because they don't have to deal with such large capacity or performance . But, as well as reduced capacity and performance, they want reduced cost. Savage : I'm not sure about that. Rowen : I'd say we want whatever the next grade is above whatever they're selling now. I mean, I think our demands in terms of the tools are extreme. Savage : I think I completely agree. There may be some basic cases, but... Rowen : There's a lot of value in those tools, and we'd like more—more capability, faster run times, higher levels of optimisation. There is an infinite appetite in these high-end products for more optimised tools and more optimised flows. They're expensive, but what they do is so essential. I wouldn't put what we do in the category of "Can you give me a cheaper, dumber tool?" I don't need the OrCad of synthesis and place and route to do this. Koeter : If you just look at hardening a processor. You could run dozens of experiments with different floor plans and different constraint files. You know, you have to do that design exploration in order to get the best results. * * * I would love to have other IP developers weigh in on this issue. How crippling are EDA tool costs for IP developers? Do the EDA companies have too big an advantage in developing IP?   Brian Bailey EE Times

With the help of five experts, I considered some questions around verification of the IP. How much verification of the IP blocks should the licensor and the licensee companies have to do? Will this change in the future? What verification IP should be shipped with the design IP? Should the same companies supply the design IP and verification IP, or does that present a significant risk to the licensee of insufficient coverage and in-the-field failure? I went to several experts on the subject and here's what they had to say: Michael Munsey, Director of Product Management, Semiconductor Solutions at Dassault Systèmes: Companies will still need to verify all IP. There are numerous stories of customers receiving IP that still has bugs in it. Even with verification IP shipped with the design IP, there really needs to be a level of checking to insure the quality of both. If VIP and DIP come from different sources, it will still need to be validated in-house. It is also necessary, but may become even more difficult, to tie verification back to the original requirements. The key with IP assembly is to ensure that the assembled system still meets all of the requirements. Neill Mullinger, Verification IP Product Marketing Manager, Synopsys: Developers of the IP blocks need to extensively verify the IP in all configurations and variants that may be used, to verify compliance to the relevant specifications or protocols. Consumers of the IP blocks should not have to be concerned with compliance of proven cores from a trusted source. That should have been completed as part of the core's progress to certification or signoff. Re-running compliance testing is massively time consuming and redundant. The blocks do, however, need integration testing. While integration test is simpler, it is certainly not trivial; verification teams still need to run through steps to configure, enumerate, train the core and send sufficient real-life traffic, common error cases, and relevant application-specific traffic to verify integration is successful and performance goals are being met with the core's configuration. Susan Peterson, Product Marketing Group Director and Tom Hackett, Senior Product Marketing Manager, Cadence: The amount of IP verification that a company has to perform depends on a variety of factors, including: * The maturity of the IP. * The availability of use cases documenting other customers' experiences with the IP (the more use cases that have been tested, the less verification needed). * The verification methodology used by the IP vendor (and whether they are willing to share this). * The level of customisation performed on the standard IP block; more customisation calls for more verification by the chip designer. Ideally, verification IP should ship with the design IP, to give designers a starting point and a sanity check that they have, indeed, hooked up the IP correctly. Chip designers should seek detailed verification data from their IP providers, so they can gather a quantifiable measure of how well the IP meets their required specs right out of the box. And, if a single company provides both the verification and the design IP, the designer should ensure that the development was completed by different organisations within that company, so they can be assured that the organisations have cross-checked each other's work, not just their own. Bernard Murphy, CTO of Atrenta: In addition to verification IP, we should be thinking more about IP shipped with more assertions, especially low-level assertions. In-situ verification is still a big challenge. If something misbehaves, is that an IP problem, a usage problem, or a misunderstanding problem? This can be really difficult to track down without access to the whole system unless the IP is "salted" with a decent number of low-level assertions which can provide a quick diagnosis. Arvind Shanmugavel, Director of Applications Engineering, Apache Design: Soft IP verification standards are well known in the SoC design community. However, electrical verification for reliable operation of any hard IP is still evolving. IP providers need to provide proper guidelines for verification at the SoC-level. For example, verifying ESD integrity for hard IP can only be done at the SoC-level. Proper guidance needs to be given by the IP provider regarding the ESD scheme used and the placement of protection devices.   Brian Bailey EE Times  

I thought about some questions around verification of the IP: How much verification of the IP blocks should the licensor and the licensee companies have to do? Will this change in the future? What verification IP should be shipped with the design IP? Should the same companies supply the design IP and verification IP, or does that present a significant risk to the licensee of insufficient coverage and in-the-field failure? I went to several experts on the subject and here's what they had to say. Michael Munsey, Director of Product Management, Semiconductor Solutions at Dassault Systèmes: Companies will still need to verify all IP. There are numerous stories of customers receiving IP that still has bugs in it. Even with verification IP shipped with the design IP, there really needs to be a level of checking to insure the quality of both. If VIP and DIP come from different sources, it will still need to be validated in-house. It is also necessary, but may become even more difficult, to tie verification back to the original requirements. The key with IP assembly is to ensure that the assembled system still meets all of the requirements. Neill Mullinger, Verification IP Product Marketing Manager, Synopsys: Developers of the IP blocks need to extensively verify the IP in all configurations and variants that may be used, to verify compliance to the relevant specifications or protocols. Consumers of the IP blocks should not have to be concerned with compliance of proven cores from a trusted source. That should have been completed as part of the core's progress to certification or signoff. Re-running compliance testing is massively time consuming and redundant. The blocks do, however, need integration testing. While integration test is simpler, it is certainly not trivial; verification teams still need to run through steps to configure, enumerate, train the core and send sufficient real-life traffic, common error cases, and relevant application-specific traffic to verify integration is successful and performance goals are being met with the core's configuration. Susan Peterson, Product Marketing Group Director and Tom Hackett, Senior Product Marketing Manager, Cadence: The amount of IP verification that a company has to perform depends on a variety of factors, including: * The maturity of the IP. * The availability of use cases documenting other customers' experiences with the IP (the more use cases that have been tested, the less verification needed). * The verification methodology used by the IP vendor (and whether they are willing to share this). * The level of customisation performed on the standard IP block; more customisation calls for more verification by the chip designer. Ideally, verification IP should ship with the design IP, to give designers a starting point and a sanity check that they have, indeed, hooked up the IP correctly. Chip designers should seek detailed verification data from their IP providers, so they can gather a quantifiable measure of how well the IP meets their required specs right out of the box. And, if a single company provides both the verification and the design IP, the designer should ensure that the development was completed by different organisations within that company, so they can be assured that the organisations have cross-checked each other's work, not just their own. Bernard Murphy, CTO of Atrenta: In addition to verification IP, we should be thinking more about IP shipped with more assertions, especially low-level assertions. In-situ verification is still a big challenge. If something misbehaves, is that an IP problem, a usage problem, or a misunderstanding problem? This can be really difficult to track down without access to the whole system unless the IP is "salted" with a decent number of low-level assertions which can provide a quick diagnosis. Arvind Shanmugavel, Director of Applications Engineering, Apache Design: Soft IP verification standards are well known in the SoC design community. However, electrical verification for reliable operation of any hard IP is still evolving. IP providers need to provide proper guidelines for verification at the SoC-level. For example, verifying ESD integrity for hard IP can only be done at the SoC-level. Proper guidance needs to be given by the IP provider regarding the ESD scheme used and the placement of protection devices.   Brian Bailey EE Times