While the EDA Designline no longer exists, EDA and circuits in the form of intellectual property (IP) cores, and their verification and integration, continue to be a significant part of the agenda here in the SoC area of EE Times. In a previous blog, I looked at IP core integration and the standards that may be necessary. Today, with the help of five experts, I consider 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 customization performed on the standard IP block; more customization 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 organizations within that company, so they can be assured that the organizations 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 [electrostatic discharge] 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.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.