IP-XACT as a way to orchestrate your HW design flow. Maximize Reuse benefits with a proper method

Author: Vincent Thibaut, Chief Strategy Officer @ Magillem ● Email: thibaut@magillem.com ● LinkedIn: click here

Let’s see how leveraging standards help us in this process.

I am for clarity’s sake, referring in this paper to Semiconductor Front End Design, the lowest level of representation will therefore be the RTL. Other standards allow us to go further down into the process but cover very narrow domains and are not always IEEE.

First things first, the reason I am here focusing on IEEE standards is because the first key to reuse is interoperability. And this is the reason those standards exist. Some are completely unavoidable into the current design flow like Verilog or VHDL for example; some younger ones are still making their way but are mostly undisputed inside their respective application domains like IP-XACT or SystemC, for example. I will not go into their respective “good, bad, and ugly” review, they have the most important virtue, they are international standards and as such allow communication between stakeholders.

Our lowest level being the RTL, I will start there. Standards for RTL have been existing for quite some time. While their latest version may not all be supported, their core concepts and constructs are. Synthesizers and simulators are mature and a clear definition of their usable subset is available. Those languages are Verilog (IEEE-1364) and VHDL (IEEE-1076) as well as their AMS versions. Those standard act as a go between the Front-End design (our subject) and the Back-End activities.

What are the keys of a successful IP Reuse and how can we leverage IEEE standards to help us with this new strategy?

There are a few obvious requirements for a good reuse:

    1. The capability to exchange IPs. Between companies, but also between projects this is the first key to reuse.
    2. The capability for those IPs to be configurable to a quite extensive level. Reuse really works if IPs are capable to address a range of usage justifying it.
    3. The capability to easily understand those IPs. From their physical interfaces to their programming ones including configuration resolution, “If you do not understand it you cannot reuse it.”
    4. The capability to integrate them in multiple designs with various configurations and various combinations on IPs.
    5. Finally, the integration into an efficient design environment. Which means we need to be able to go from one representation to the other (HW and SW or Spec to Models to RTL for example) but still be capable of keeping them consistent.
RTL, however, does not require nor promote an IP Reuse strategy; some additional constructs are required. Without going into this yet, let me mark another important point. The RTL in an IP Reuse strategy is the placeholder of the IP behavior, the actual Intellectual Property if I may say.

Let me elaborate a bit on this because this is a very important point. There is a need for separation between descriptive and behavioral content for a successful IP Reuse strategy. Let’s skip the details and keep the main reason: the behavior needs to be secured for business reasons. This is why we see a lot of encrypted RTL and secure and watermarking IP standards.
This is the main reason why RTL, while requiring a proper coding style for proper reuse, is not the optimal language to address the descriptive need of a successful IP Reuse strategy.

To understand a little more this division between behavioral and descriptive aspects, I invite you to look at MBE, or even more relevant, MBSE concepts of analytical and descriptive models. I do think that in a semiconductor design process the descriptive part can be less ambiguous than what MBSE proposes but this is due to the relative maturity of the semiconductor industry in terms of standards. The more specialized the standard, the more accurate the description.

I need here before moving to this descriptive part to mention another behavioral model used in the semiconductor industry and which offers some interesting capabilities. One in particular comes to mind, its capability to interact with system software models allowing integration with the higher levels of the system design. The SystemC (IEEE-1666) indeed provides the capability to represent some high-level models, directly executable and as such part of the analytical models.

Great, we start to see things, those standards allow us to achieve requirements 1 and 2. We now have a way to exchange the actual Intellectual Properties and share a common transformation of those files into actual products. We also provide a range of derivation and configurability ensuring a good ROI on the IP development investment.

So, can we use those standards to achieve our other requirements? Well, sadly not really.

While the RTL does contain most of the information, when we are looking at exchange, it has quite a few limitations:

  • Descriptive information is often mixed with behavioral ones, especially the registers. This means encrypted IPs are often not usable for this.
  • Behavior is not a human readable description and can be implemented different ways.
  • Nothing captures interoperability of interfaces.
  • Structural description is possible but not enforced and hierarchies and configurations are complex to solve.

Those are a few examples and again for the sake of separating behavior and description, using RTL format is not a very efficient solution.

This leads me to another IEEE standard, IP-XACT (IEEE-1685), this relatively young standard, founded in 2003 (not so new), offers the best current option to address the need for an IP Reuse strategy regarding the descriptive capabilities. I will include in this descriptive umbrella the structural description: netlist, hierarchy, configurations, … It integrates much better at an IP-XACT level which promotes this coding style than at RTL.

Among other things it resolves a lot of issues about an IP Reuse flow, which is not a real surprise at this is part of its mission. A mission which has assembled a great team of engineers representing a group of major actors in all the ecosystem chain, from IP providers to SoC integrator and tool providers

Let’s review our checklist for this descriptive content

1 – Capability to exchange IPs

Again, this is part of the standard mission. I will not say much on this, there is quite a lot of literature and this is a fact in today design process in many companies.

Let me just address a few points related to my previous statements:

  • First of all, by not containing the actual behavioral content, IP-XACT is a perfect candidate to exchange IP information from the Intellectual Property protection point of view. No one can tape out a chip with an IP-XACT file 😊.

  • Secondly, IP-XACT can go further, because more specialized to a specific domain, than the MBSE definition of descriptive model. While still providing some freedom of interpretation on how things work, part of our Intellectual Property, it provides a non-ambiguous description of our IPs, IP integration and configuration and behavioral model pointers.

2 – Capability to be configurable

You may think, the true question is the capability to handle the IP configuration, and this is indeed a necessity. So yes IP-XACT got this covered through things like parameters, design configurations, …

But it also holds the entire SOC configuration through configurable assembly of IPs with mechanisms like views, hierarchies, … This by the way allows to extract exact configuration of a SoC which can optimize your various deliverables especially documentation.

3 – Capability to Easily Understand

Well, this is where IP-XACT is probably at its best. So yes, I know, if you open your ip-xact set of files, there is more than one of them, much more 😊, with a text editor you may not get what I mean.
However, if you use a proper information rendering solution it does provide you with a very clear description of your IPs, their physical and software interfaces, configurability and even the pointer to all necessary resources in other languages.

It also provides a non-ambiguous common description by the virtue of being an IEEE standard. Every user and tools share the same.

4 – Capability to Integrate IPs together

Reusing an IP is a great goal, but IPs never work alone. It is therefore critical to ensure a strong IP integration capability. On top of the configuration we discussed previously, this can mean explicit connection interfaces, provided with IP-XACT interface and abstraction definition. But also reuse of macro blocks, provided via hierarchy support, or the relationship between connectivity and register providing for the first time a true system map vision.

This subject is one of the most well-known by IP-XACT users so I will stop here, but this is definitely covered by this standard.

5 – Capability to integrate into the overall design flow

My preferred one, because all of this is nothing if you cannot actually produce something. I’ll leave out the capability of IP-XACT to integrate smoothly with the above levels of the design cycle like specification, requirements, … Those are really valuable but more recent and not representatively deployed in the industry.

Let’s focus on the downstream flow. The main reason IP-XACT is not human readable, to answer my previous statement, is that it is a computer readable xml schema, and for the benefit of efficient automation. And this is critical because not only must I be able to interact between IP-XACT and the behavioral models but also with all the tooling around them.

Interaction with the behavioral model is obvious: my description must be accurate to what it describes. IP-XACT allows the description of all those various behavioral models, and different abstraction levels, in a unified format. It also regroups connectivity and register information, instantiation and configuration in a comprehensive package.

An interesting point here is that automation from IP-XACT is so simple that it is often easier to generate the actual behavioral models’ descriptive part from it when possible.

Interaction with the tooling is also a strong point, by generating your design flow scripts from a unified source you facilitate integration of multiple tool providers as well as internally developed ones. Successful integration of a new IP or a new tool in a design flow is not always simple, IP-XACT also address this through a complete fileset mechanism.
I hope that the benefit of a proper method leveraging standards, a key element for an efficient Reuse strategy, is now obvious. Much more can be said, but this article is long enough as it is. If you are interested in more details or discussion, you can contact me through:
  • Vincent Thibaut, Chief Strategy Officer @ Magillem
  • Email: thibaut@magillem.com
  • LinkedIn: click here
  • Sources:
  • IP-XACT:
  • Magillem:
  • To get in contact with the IP-XACT experts’ community I would also recommend the forum:
  • http://forums.accellera.org/forum/31-ip-xact-discussion/
  • Contact us

    Page contact
    All the fields are required. Magillem will not respond to emails sent from non- business email accounts such as gmail or yahoomail , for example. Thank you for your understanding.
    This form collects your name, email address and company information so that our team can communicate with you. Please, chek our Privacy Policy to see how we protect and manage submitted data.