This question lingered in the background of the closing panel at DAC yesterday, and it prompted several very interesting observations from the panelists. There was some agreement that IP-XACT, with its concept of an XML-driven electronic databook, can in fact automate IP assembly some of the time. It was the definition of when the technique would and would not work that proved the most interesting.

John Goodenough, director of design technology at ARM, stated that “IP-XACT only works if everyone agrees on how to connect the blocks.” There are other things that have to happen, outside the datasheet, he maintained. “What you really need to do is to transfer the designer’s brain to the architects and designers who are integrating the blocks. What assumptions did the IP designer make about floor planning? What did he use for system models, and where are they?”

Further discussion refined this point in an important way. Serge Leef, general manager of system-level engineering at Mentor Graphics, made it specific: “What we need is a regular way to identify compatibility and incompatibility between IP and tools.” This was expanded again by Texas Instruments design methodology manager Loic Le-Toumelin: “We could use assertions also to check for legal use cases—to verify that the IP is being used in a way anticipated by the designer.”

This notion seems particularly valuable. Just as in systematically designed software a procedure or method would inspect the calling arguments for validity, an IP block could be coded with assertions that would inspect its surroundings for proper logical connection and proper state sequencing. The block could even flag other IP blocks with which it has never been verified. While such a technique would only be useful for blocks that were previously developed and had some use history, it could convey a great deal about the IP designers’ assumptions to the user team, saving a lot of unpleasant surprises and detecting some important misunderstandings early.

The idea very much parallels the effort to include more verification IP with the functional IP simply for verifying the IP itself. Laurent Lestringand, IC development manager at NXP, noted that despite all the attention paid in conferences and press releases to the subject, NXP still finds that IP often arrives without verification support. And when that support is there, others say, it is usually in the form of simple test benches. Tailored test generators and checkers are less common, and assertions are still painfully rare. “The first issue for us with a new piece of IP is quality,” Lestringand said.

Samsung has become sufficiently pessimistic about the willingness of IP vendors to move on this issue that it has taken matters into its own hands. “We have an internal verification team, and we can add our own assertions to a piece of IP if necessary,” said Sungjoo Yoo of Samsung.

Even with additions, though, many of the panelists did not think of data delivery mechanisms such as IP-XACT as standing alone. “Most of our success stories are based on close cooperation with the IP vendors,” observed Le-Toumelin. Goodenough agreed: I’m afraid the reality today is that often, the IP is being developed concurrently with the design that uses it. Or it is being adapted to that design. Communications between the IP and user teams is vital. That should not be true for mature IP, though.”

Others quickly jumped on the idea of mature IP. “You’re always changing something,” Le-Toumelin stated. Lestringand agreed. “You must always be prepared for issues to arise. You have to establish communications with the IP design team.”

Yoo added an interesting perspective from the viewpoint of one of the world’s most vertically integrated companies. “I think that person-to-person contact between the IP designers and the users is needed because there has been no agreement on basic definitions,” he said. “We have found that internal authoring of the IP can avoid this.”

Perhaps, based on the discussions at this panel, IP-XACT can make a major advance in IP reuse, not so much by automating the process as by establishing a common set of files, definitions, and understandings around which an intimate relationship between IP provider and IP user can mature. It is clear from the discussion that the next step in bringing IP-XACT to this point is in enriching the content of verification IP. Interestingly, the VSIA is working on precisely this point. Stay tuned.

ADVERTISEMENT