IP-XACT as a way to orchestrate your HW design flow. Maximize Reuse benefits with a proper method
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.
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 IPsAgain, 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 configurableYou 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 UnderstandWell, 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 togetherReusing 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 flowMy 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.