Gabe Moretti, Senior Editor
Given their complexity, the vast majority of today’s SoC designs contain a high number of third party IP components. These can be developed outside the company or by another division of the same company. In general they present the same type of obstacle to easy integration and require a model or multiple types of models in order to minimize the integration cost in the final design.
Generally one thinks of models when talking about verification, but in fact as Frank Schirrmeister, Product Marketing Group Director at Cadence reminded me, there are three major purposes for modeling IP cores. Each purpose requires different models. In fact, Bernard Murphy, Chief Technology Officer at Atrenta identified even more uses of models during our interview.
Frank Schirrmeister listed performance analysis, functional verification, and software development support as the three major uses of IP models.
Frank points out that one of the activities performed during this type of analysis is the analysis of the interconnect between the IP and the rest of the system. This activity does not require a complete model of the IP. Cadence’s Interconnect Workbench creates the model of the component interconnect by running different scenarios against the RT level model of the IP. Clearly a tool like Palladium is used given the size of the required simulation of an RTL model. So to analyze, for example, an ARM AMBA 8 interconnect, engineers will use simulations representing what the traffic of a peripheral may be and what the typical processor load may be and apply the resulting behavior models to the details of the interconnect to analyze the performance of the system.
Drew Wingard, CTO at Sonics remarked that “From the perspective of modeling on-chip network IP, Sonics separates functional verification versus performance verification. The model of on-chip network IP is much more useful in a performance verification environment because in functional verification the network is typically abstracted to its address map. Sonics’ verification engineers develop cycle accurate SystemC models for all of our IP to enable rapid performance analysis and validation.
For purposes of SoC performance verification, the on-chip network IP model cannot be a true black box because it is highly configurable. In the performance verification loop, it is very useful to have access to some of the network’s internal observation points. Sonics IP models include published observation points to enable customers to look at, for example, arbitration behaviors and queuing behaviors so they can effectively debug their SoC design. Sonics also supports the capability to ‘freeze’ the on-chip network IP model which turns it into a configured black box as part of a larger simulation model. This is useful in the case where a semiconductor company wants to distribute a performance model of its chip to a system company for evaluation.”
Bernard Murphy, Chief Technology Officer, Atrenta noted that: ” Hierarchical timing modeling is widely used on large designs, but cannot comprehensively cover timing exceptions which may extend beyond the IP. So you have to go back to the implementation model.” Standards, of course, make engineers’ job easier. He continued: “SDC for constraints and ILM for timing abstraction are probably largely fine as-is (apart from continuing refinements to deal with shrinking geometries).”
Tom De Schutter, Senior Product Marketing Manager, Virtualizer – VDK, Synopsys
said that “the creation of a transaction-level model (TLM) representing commercial IP has become a well-accepted practice. In many cases these transaction-level models are being used as the golden reference for the IP along with a verification test suite based on the model. The test suite and the model are then used to verify the correct functionality of the IP. SystemC TLM-2.0 has become the standard way of creating such models. Most commonly a SystemC TLM-2.0 LT (Loosely Timed) model is created as reference model for the IP, to help pull in software development and to speed up verification in the context of a system.”
Frank Schirrmeister noted that verification requires the definition of the IP at an IP XACT level to drive the different verification scenarios. Cadence’s Interconnect Workbench generates the appropriate RTL models from a description of the architecture of the interconnects.”
IEEE 1685, “Standard for IP-XACT, Standard Structure for Packaging, Integrating and Re-Using IP Within Tool-Flows,” describes an XML Schema for meta-data documenting Intellectual Property (IP) used in the development, implementation and verification of electronic systems and an Application Programming Interface (API) to provide tool access to the meta-data. This schema provides a standard method to document IP that is compatible with automated integration techniques. The API provides a standard method for linking tools into a System Development framework, enabling a more flexible, optimized development environment. Tools compliant with this standard will be able to interpret, configure, integrate and manipulate IP blocks that comply with the proposed IP meta-data description.
David Kelf, Vice President of Marketing at OneSpin Solutions said: “A key trend for both design and verification IP is the increased configurability required by designers. Many IP vendors have responded to this need through the application of abstraction in their IP models and synthesis to generate the required end code. This, in turn, has increased the use of languages such as SystemC and High Level Synthesis – AdaptIP is an example of a company doing this – that enables a broad range of configuration options as well as tailoring for specific end-devices. As this level of configuration increases, together with synthesis, the verification requirements of these models also changes. It is vital that the final model to be used matches the original pre-configured source that will have been thoroughly verified by the IP vendor. This in turn drives the use of a range of verification methods, and Equivalency Checking (EC) is a critical technology in this regard. A new breed of EC tools is necessary for this purpose that can process multiple languages at higher levels of abstractions, and deal with various synthesis optimizations applied to the block. As such, advanced IP configuration requirements have an affect across many tools and design flows.”
Bernard Murphy pointed out that “Assertions are in a very real sense an abstracted model of an IP. These are quite important in formal analyses also in quality/coverage analysis at full chip level. There is the SVA standard for assertions; but beyond that there is a wide range of expressions from very complex assertions to quite simple assertions with no real bounds on complexity, scope etc. It may be too early to suggest any additional standards.”
Tom De Schutter pointed out that “As SystemC TLM-2.0 LT has been accepted by IP providers as the standard, it has become a lot easier to assemble systems using models from different sources. The resulting model is called a virtual prototype and enables early software development alongside the hardware design task. Virtual prototypes gave have also become a way to speed up verification, either of a specific custom IP under test or of an entire system setup. In both scenarios the virtual prototype is used to speed up software execution as part of a so-called software-driven verification effort.
A model is typically provided as a configurable executable, thus avoiding the risk of creating an illegal copy of the IP functionality. The IP vendor can decide the internal visibility and typically limits visibility to whatever is required to enable software development, which typically means insight into certain registers and memories are provided.”
Frank Schirrmeister pointed out that these models are hard to create or if they exist they may be hard to get. Pure virtual models like ARM Fast Models connected to TLM models can be used to obtain a fast simulation of a system boot. Hybrid use models can be used by developers of lower level software, like drivers. To build a software development environment engineers will use for example a ARM Fast Model and plug in the actual RTL connected to a transactor to enable driver development. ARM Fast Models connected with say a graphics system running in emulation on a Palladium system is an example of such environment.
ARM Fast Models are virtual platforms used mostly by software developers without the need for expensive development boards. They also comply with the TLM-2.0 interface specification for integration with other components in the system simulation.
Other Modeling Requirements
Although there are three main modeling requirements, complex IP components require further analysis in order to be used in designs implemented in advanced processes. A discussion with Steve Brown, Product Marketing Director, IP Group at Cadence covered power analysis requirements. Steve’s observations can be summed up thus: “For power analysis designers need power consumption information during the IP selection process. How does the IP match the design criteria and how does the IP differentiate itself from other IP with respect to power use. Here engineers even need SPICE models to understand how I/O signals work. Signal integrity is crucial in integrating the IP into the whole system.”
Bernard Murphy added: “Power intent (UPF) is one component, but what about power estimation? Right now we can only run slow emulations for full chip implementation, then roll up into a power calculation. Although we have UPF as a standard estimation is in early stages. IEEE 1801 (UPF) is working on extensions. Also there are two emerging activities – P2415 and 2416 –working respectively on energy proportionality modeling at the system level and modeling at the chip/IP level.”
IP Marketplace, a recently introduced web portal from eSilicon, makes power estimation of a particular IP over a range of processes very easy and quick. “The IP MarketPlace environment helps users avoid complicated paperwork; find which memories will best help meet their chip’s power, performance or area (PPA) targets; and easily isolate key data without navigating convoluted data sheets” said Lisa Minwell, eSilicon’s senior director of IP product marketing.
Brad Griffin, Product marketing Director, Sigrity Technology at Cadence, talked about the physical problems that can arise during integration, especially when it concerns memories. “PHY and controllers can be from either the same vendor or from different ones. The problem is to get the correct signal integrity and power integrity required from a particular PHY. So for example a cell phone using a LP DDR4 interface on a 64 bit bus means a lot of simultaneous switching. So IP vendors, including Cadence of course, provide IBIS models,. But Cadence goes beyond that. We have created virtual reference designs and using the Sigrity technology we can simulate and show that we can match the actual reference design. And then the designer can also evaluate types of chip package and choose the correct one. It is important to be able to simulate the chip, the package, and the board together, and Cadence can do that.”
Another problem facing SoC designers is Clock Domain Crossing (CDC). Bernard Murphy noted that :”Full-chip flat CDC has been the standard approach but is very painful on large designs. There is a trend toward hierarchical analysis (just as happened in STA), which requires hierarchical models There are no standards for CDC. Individual companies have individual approaches, e.g. Atrenta has its own abstraction models. Some SDC standardization around CDC-specific constraints would be welcome, but this area is still evolving rapidly.”
Although on the surface the problem of providing models for an IP component may appear straightforward and well defined, in practice it is neither well defined nor standardized. Each IP vendor has its own set of deliverable models and often its own formats. The task of comanies like Cadence and Synopsys that sell their own IP and also
provide EDA tools to support other IP vendors is quite complex. Clearly, although some standard development work is ongoing, accommodating present offerings and future requirements under one standard is challenging and will certainly require compromises.