The Value of High Quality IP-XACT XML

As the semiconductor industry increases take-up of IP-XACT standards to describe Intellectual Property (IP) this paper shares the experiences of NXP Semiconductors and Mentor Graphics, who have been using and developing this technology together for over five years. This paper describes the benefits of adopting IP-XACT and highlights the importance of producing high quality component XML as the foundation of a successful IP-XACT reuse strategy. Experience shows that applying the concepts presented in this paper as part of a design reuse and verification strategy will ease adoption and increase the success rate of major System-on-Chip (SoC) projects

I. INTRODUCTION

What is IP-XACT? Essentially IP-XACT is an electronic data book; a description of components and designs written in a standard data exchange format (XML), which is both human readable and machine processable. It describes electronic system designs and the interconnection of IP interfaces in a standard specification to provide IP suppliers, design integrators and Electronic Design Automation (EDA) vendors, with a common representation. In this way, IP-XACT provides a mechanism by which design reuse can be made a practical reality.

The IP-XACT standard is managed by The SPIRIT Consortium, an industry association of leading companies including ARM, Cadence, LSI, Mentor Graphics, NXP, ST, Synopsys and Texas Instruments plus nine other contributing companies and over 50 other reviewing member companies. The IP-XACT standard was initially contributed by Mentor Graphics and has continued to develop by contribution of an ever increasing list of member companies.

IP-XACT is an industry-wide standard for providing not only hardware information, but also software views, file lists, protocol standardization; plus extensibility to add additional design and flow information.

IP-XACT describes the interface to an IP, but not the functionality. It is not a replacement for hardware description languages (HDL) such as VHDL and Verilog or Systems languages such as System-C, register description languages, embedded software or documentation; it is complementary and coexisting, providing a central repository of key information. This is an important point when verifying the quality of an IP-XACT component as will be described in detail later in this paper.

II. THE VALUE OF IP-XACT

Why is IP-XACT required? IP-XACT provides ease of system integration, verification, automation, and therefore a Time-To-Market (TTM) advantage. Few people dispute the need for increased design reuse when faced with increased complexity and challenging Time-To-Market pressures. However, design reuse has been slow to provide the anticipated SoC design flow advances, primarily due to the lack of standardization of interfaces, processes, flows, automation, and verification quality. IP-XACT has been designed to address all these issues by providing a standardized data exchange format which has both the flexibility to represent multiple companies’ requirements and the rigor to allow information to be automatically extracted and used in flow automation and advanced verification.

It is unlikely that the architect of a modern SoC device would begin a project with the statement “I need to control the intercommunication on my device using software; I will start by designing a good microprocessor”. Reuse of existing microprocessors is standard practice on large SoC devices, indeed many large reprogrammable (FPGA) devices have processors embedded on the silicon for this purpose. However, reuse of other standard components is not so common. Increasingly companies are realizing that the competitive advantage of their System-on-Chip devices is not provided by bus infrastructure, interrupt controllers, timers, UARTs and bridges, so why spend disproportionate amounts of time developing these commodity components when they can be sourced externally? The reason has been a lack of standardization of interfaces and concerns about configurability and quality. IP-XACT is designed to address these concerns and - by standardizing information - to enable development of automated tooling by EDA vendors.

IP-XACT is extremely flexible, it works alongside NXP’s huge legacy systems for IP core reuse and yet can be applied to green-field projects that have no legacy IP and simply want a mechanism to allow different design teams to work on sub-systems which may then be easily integrated into target SoC devices.


Figure 1: How IP-XACT fits into the SOC Design Flow.

III. HOW IP-XACT FITS INTO THE SOC DESIGN FLOW

IP-XACT standardizes a number of different meta-data specifications and a tight generator interface (TGI) to provide programmability, but central to the standard - and focus point of this paper - is the component specification. It is this description that specifies the interface (boundary) of each IP block as component XML. This includes the physical signals, their mapping to logical bus interfaces, bridging information, address blocks, register descriptions, filesets, documentation information, and more.

As mentioned above, IP-XACT does not replace modelling languages; it catalogues all the required information about an IP block and describes it in a format that can be processed by system integration tools such as Platform Express that form part of the integration and verification flow (see figure 1).

The whole SoC construction and verification flow can be integrated using tools such as embedded software compilers, HDL simulators, synthesis tools, DFT tools, Formal verification tools, and any other selected EDA tooling. Nx-Builder, the NXP system integration tool,

proves the concept by successfully pulling together such EDA tools from Mentor Graphics, Cadence Design Systems, Synopsys, Novas and NXP’s own products into a single integrated design and verification environment.

The information provided in the component XML description is used throughout the SoC design flow. This means the quality of that XML ripples through all the way the SoC design process and is used and cross referenced by multiple tools in the automated flow (see figure 2). This is the reason why it is essential that the XML is correct and complete.

Flow automation is very powerful in performing well defined, potentially mundane tasks which were previously prone to human error, for example configuration of inter-dependent parameters, generation of top level wiring, insertion of test logic, generation of documentation, and creation of test software to perform register read/ write tests.

However, as is common in highly automated systems, when things go wrong it is increasingly difficult to identify the cause of the failure amongst a complex and inter-related set of parameters; some mistakes only show up as problems in the flow long after the point of failure.


Figure 2: The Impact of IP-XACT on the SOC Design Flow

Automated systems - as has long been known in the software world - suffer from a characteristic known as Garbage In Garbage Out (GIGO), meaning that if you start with bad inputs the results will also be bad. This is why it is essential to start an IP-XACT reuse strategy with high quality component descriptions and to verify the design throughout the integration process.

IP-XACT provides the ability to integrate IP from multiple suppliers and verify that IP in-situ with a variety of leading edge verification tools, such as protocol checkers, design rule checkers, clock domain crossing analysis, static timing and formal verification tools, embedded software testing, advanced testbench mechanisms and more. However, this whole flow relies on the input data – the IP-XACT description being correct, complete and consistent with the IP.

IV. APPROACHES TO ENSURE HIGH QUALITY XML

A. Packaging (automate XML creation)

IP-XACT descriptions of components often contain a lot of data. Some data is dependent on other parts of the IP-XACT description and therefore needs to be kept consistent. Large amounts of interdependent data makes production of accurate XML and maintenance of that XML problematic. In NXP’s experience, the library of reusable IP currently consists of more than 150 components each having between 500 and 10000 lines of IP-XACT XML. The complexity of each XML description is highly dependent on the complexity of the IP. The IP-XACT description consists of signal lists, bus interface descriptions, register descriptions, embedded software and hardware filesets, synthesis timing files etc. Therefore a complex IP can result in a very large XML description.

Generation of large amounts of information is not practical by hand and would be very error prone. The first step in a high quality reuse methodology is therefore to largely automate this phase of the process. The automatic creation of IP-XACT descriptions is the role of the packager. The packager gathers pertinent data from a variety of sources and generates an accurate and consistent component description.

Packaging tools are available from a variety of companies and range from quite simple RTL parsing intelligent editors to advanced tools with user extendibility, built-in schema validation and solutions for updating IP as described later.

NXP uses advanced packaging technology, because of the need to package large quantities of legacy IP, whilst IP providers often have limited knowledge of IP-XACT. Their goal is to create correct, complete and consistent IP-XACT XML with the minimum amount of manual effort.

The packaging technology as used within NXP is currently capable of generating - depending on the type and complexity of the IP - around 80% of the IP-XACT XML automatically from their IP database. This percentage is rapidly increasing as packager technology matures. The remaining 20% relates to completing and updating the generated XML, thereby decreasing the human effort and increasing the quality of the XML.

B. Validation (syntax/ schema checks)

In order to provide a high degree of assurance that the XML is correct, complete and consistent with the IP, XML validation is performed. The first level of validation after packaging is to make sure that the XML conforms to the IP-XACT schema. A schema is a standard XML mechanism for specifying the allowed contents and structure of the XML description. A schema specifies which parts of the XML description are mandatory and which parts are optional. The SPIRIT Consortium provides schema files for validation of IP-XACT XML. Note that the IP-XACT schema is an extendable specification, so within NXP validation of the XML is not only performed against the IP-XACT schema but also against both the Mentor Graphics Platform Express™ namespace vendor extensions, and NXP’s own vendor extension schema (vendor extensions are an IP-XACT flexibility mechanism to allow extra information to be added to the component description).

For this first level of XML validation, correctness and completeness refer to whether 1) the XML description is syntactically correct 2) the XML description contains all the mandatory properties as specified by the used schema’s and 3) the content and structure of the XML description complies to the used schema’s.

Schema validation is a standard approach for validating XML descriptions, and it is therefore possible to purchase commercial tools such as Altova® XMLSpy® for this purpose. As mentioned above, some advanced packagers also offer this capability.

Schema validation is only the very first level of IP-XACT validation, and currently too many IP providers are relying on this mechanism alone, leading to quality problems when IP is integrated into the SoC flow. Schema validation is lacking in several key aspects. First, a lot of the XML content specified in the IP-XACT schema is optional. This means that one cannot give a meaningful completeness metric based on schema validation alone. Secondly, the mechanism for defining vendor extensions in IP-XACT is very generic. For this reason, it is not straightforward to check whether the vendor extended sections in the IP-XACT XML description are correct, complete and defined at the correct location. Finally, a schema specification does not include semantic rules related to the schema. NXP has resolved all these issues in their validation flow.

C. Screening (completeness and semantics checks)

As mentioned in the previous section, the first level of validation checks for the XML syntax, content and structure according to the schema, but with a very few exceptions does not check the completeness and semantics of the XML. An IP-XACT component description can be syntactically correct but still inaccurate. The validation process within NXP is therefore extended by applying additional completeness and semantic rules to check that the contents of the XML descriptions are complete and consistent with the IP’s. This process is referred to as ‘screening’.

One cannot give a completeness metric based on the IP-XACT schema as the content of the XML description as specified in this schema is mostly optional. NXP has specified additional mandatory sections. These sections are checked by the screener, which raises an error when they are not defined. An example of an NXP completeness check is whether the XML description contains default values for input pins. An example of checking for best-practices is having appropriate timing constraints on pins. Again, these are not mandatory according to the IP-XACT schema, but the screener will raise a warning when best-practices are not followed.

Figure 3: Screening Output

For checking the vendor extensions, the validation tool (in combination with the schema files for the vendor extensions ) is set up in such way, that it is possible to check whether the vendor extensions are placed in the correct sections and whether the content and structure follows the vendor’s schema. As the IP-XACT vendor extension mechanism allows for anything to be placed in the vendor extension sections of the XML, it is not trivial to validate the intersection of IP-XACT and vendor extension schemas.

In addition to the completeness checks the screener also contains a large set of semantic rules that are checked. Screening will detect - for example - the presence of a file reference in the component description to a non-existing file or a bus interface of an unknown bus type. This is outside the scope of the schema, but is an error and will be trapped by the screener. Another example is the correctness of the register definition in the XML, e.g. is there an overlap of registers and do the registers fit in the size of the address block. The screener used within NXP contains a set of rules - both IP-XACT and NXP specific - that are used to check the correctness and completeness of the XML when to be used in Nx-Builder (see figure 3). By studying the use model of XML sections the number of these rules can be increased, leading to rigorous checking of the component description early in the design cycle.

D. Reporting (completeness and impact analysis)

Having passed schema validation and screening, reporting gives a completeness metric to the component description. It assesses information that is present in the description and which (optional) information is missing and explains the impact that this will have on the design flow (see figure 4). For example – “No synthesis constraints are present so synthesis, STA, and many back-end flows will not be possible with this IP”.


Figure 4: Reporting Output

E. System verification (Correctness and Interoperability)

All of the above tests check the component description stand-alone. It should be remembered, however, that component XML only describes the interface of the IP not its function. It is therefore vital to also check the correct function of the IP in a system context, to verify that the IP correctly connects and communicates with other components in the system. Failure to perform adequate testing of the IP in a system context is to provide a very detailed description of an IP that may totally fail to perform its required function when integrated into an SOC design.

Simple system checks include ensuring that bus interfaces are compatible with the IP, which are intended to connect to this component. Flow testing is necessary to ensure that information is correctly extracted from the IP description. Infrastructure IP such as bus matrix, interrupt controllers, and bridges may require design context information to correctly configure themselves. More advanced systems checks can include protocol monitors on buses, traffic generators, formal tools and (as described below) ESL components for advanced verification techniques.

The key challenges in system testing an IP block are to ensure that all contributing parts of the IP description (e.g. hardware and software views) are verified together and that each IP description integrates and operates correctly in a system context.

Ideally, system verification needs to be an automated regression system to allow IP providers to repeatedly verify that IP meets system requirements while making any necessary modifications. This leads us on to remaining challenges.

V. REMAINING CHALLENGES (FORMAL DESCRIPTIONS IN A CHANGING WORLD)

IP-XACT is an excellent standardised mechanism for documenting existing IP. One of the open challenges for IP providers is the ability to keep that IP documentation updated as the IP evolves. Here again IP packaging is vital, hand generated XML is difficult to keep reliably updated as the component is modified. An intelligent packager tool needs to understand that a component has been modified and allow incremental updates to an existing XML description. Equally, an optimal verification strategy should understand that a previously verified component has had minor updates applied and should focus special effort on verification of those aspects that have changed.

Updating bus definitions is a particularly difficult aspect of the existing IP-XACT standard, because a revision which is documented by incrementing the version number of a bus (version part of the Vendor, Library, Name, Version (VLNV) identifier), will cause that new bus definition to be incompatible with all existing IP, because IP-XACT currently requires an exact VLNV match for bus interfaces.

VI. PITFALLS WHEN USING IP-XACT (AND PACKAGER/ SCREENER TOOLING)

While the value of using IP-XACT is proven, there are some pitfalls a user needs to be aware of. One is that - for standardization to be successful - there should be correct, non-ambiguous and completely specified schema and semantic rules available to remove any form of miss-interpretation between IP providers, integrators and EDA vendors. Any misinterpretation will potentially lead to undesired functional behaviour and consequently quality issues.

A clear specification of the schema and its use model is the basis for any tooling for automated XML creation and any methodology for validating the quality of the XML. Without such methodology it is very difficult, if not impossible, to guarantee a certain quality level of the XML, because without a clear specification it is not possible to quantify the coverage of a validation methodology. Without coverage quantification it is not possible to provide documented evidence that the intended quality level is accomplished.

It is also dangerous to solely rely on the outcome of a packager or a screener to assess whether the XML is ready for delivery. It is very important to realize that a validation methodology can determine the correctness of an XML description, but it cannot say much about the completeness of the XML without any user interaction. The same is true for the automatic creation of XML; a packager is able to create correct and consistent XML, but it cannot create the complete XML solely based on the IP database. Some trade-off is needed in the amount of data that is required as input for the packager and the amount of post-processing required on the XML. It is important to ensure that the input of the packager does not become a specification language on its own, or the user might just as well write the XML. Typical input data for the packager are the IP database location (e.g. the simulation snapshot or the RTL of the IP), register descriptions (e.g. in CSV format), location of the IP-XACT bus definitions and mapping files guiding the mapping between bus logical ports and component physical ports (see figure 5).


Figure 5: Packager required input

It should be understood that IP-XACT - while based on simple XML concepts - contains complexities which mean that writing high quality XML requires a good understanding and interpretation of the complete specification. Many IP providers don’t - yet - have this competence and it is therefore tempting for them to rely on packaging and screening functionality to create and validate the XML. Although this tooling will reduce the necessity for in-depth IP-XACT knowledge for simple IP (it is sufficient to know what to look for when correcting/ completing the created XML), this is not possible when packaging more complex IP (e.g. CPU or IP with hard/ firm cores).

VII. FUTURE OPPORTUNITIES HIGHLY CONFIGURABLE IP

IP-XACT provides a variety of mechanisms for configuration of IP descriptions. Each configurability option increases the reusability of the IP, but also complicates the verification of that IP. NXP has several highly configurable IP blocks especially in infrastructure IP such as bus matrixes and Network-on-Chip. These components greatly add to the value of the Nx-Builder tool, but require some very advanced processing which is beyond the current scope of IP-XACT and NXP therefore find themselves ‘trail-blazing’ advanced concepts, which is not always a comfortable position to be in.

VIII. FUTURE OPPORTUNITIES ESL FOR ADVANCED VERIFICATION

The new IP-XACT 1.4 standard opens up some very exciting new possibilities for mixing RTL components with ESL functions. In addition to mixed abstraction design, IP-XACT 1.4 adds the ability to use high level testbench models to stimulate, monitor, and validate IP components in an advanced (OVM) verification methodology.

IX. CONCLUSIONS

With increasing SoC complexity and escalating market pressures design reuse and automation are proving essential in increasing quality while simultaneously reducing Time-to-Market. Standardization is essential to successful automation of a design reuse strategy. The SPIRIT Consortium provides the IP-XACT standard on which powerful design reuse methodologies are being developed.

For success in adopting and deploying IP-XACT it is important to have the foundations correct. As an IP-XACT description contains information that is used throughout the SoC design flow, the quality of the (component) description is of great importance. The metadata description of the IP must be both correct and complete. IP-XACT specifies which properties are required and which are optional, this means that it is possible to generate a valid minimal XML description but that limits the capabilities that are possible with a complete XML description such as a full HW/ SW and synthesis flows.

Packager and screener technology are of great value for the delivery of correct and complete XML descriptions. By automating the IP encapsulation using a packager one guarantees the syntactical correctness of the XML whilst reducing the amount of effort it would take when creating the component description manually. When the packager extracts the data from an IP database this ensures the consistency between the IP and the metadata and the extraction already gives a level of completeness to the XML . Screening ensures the semantic correctness and reporting adds a completeness metric to the component description.

In this paper we have highlighted not only the advantages to be gained from IP-XACT, but also warned of some of the pitfalls. Firstly, both packager and screener technology are not capable of ensuring that the component description is 100% complete. There will be design information required that cannot be automatically extracted from the IP database. For this reason, the IP provider will need to make manual updates. Therefore automated packaging and screening technology does not remove the need for a detailed knowledge in the IP-XACT specifications.

Secondly, any component creation and validation strategy should include system integration verification to ensure that specified functional requirements are fulfilled. A correct and complete IP-XACT description does not guarantee correct functionality of the IP and therefore IP-XACT descriptions should be verified in a system context.

Experience at NXP Semiconductors shows that within the above limits of an automated IP-XACT XML creation and validation methodology, the generation of high quality XML can be made a practical reality and leads to a high quality design reuse and flow automation strategy.

ACKNOWLEDGMENT

The authors would like to acknowledge the teams in Mentor Graphics and NXP Semiconductors who have contributed to this paper, to Platform Express and to Nx-Builder methodology and development.