Using SystemC to build a system-on-chip platform
How Texas Instruments' designers used the SystemC hardware design language to do performance modeling when creating both the company's OMAP-2 platform and the devices based on it.
As an embedded systems designer, you may find you're working more with hardware design languages and the system-on-chip (SoC). Perhaps you're building boards or systems using components, both of which often now deal with SoCs either in ASIC or FPGA form. How SoCs are modeled and simulated may feel like a prequel to your design, but it's valuable story.
This article discusses the role of performance modeling in creating both the OMAP-2 platform and the devices based on it. The OMAP-2 is a platform from Texas Instruments for creating SoCs. The platform is underpinned by a basic set of rules and guidelines covering programming models, bus interfaces, and RTL (register transfer level) design.
The platform is highly generic. It's capable of supporting a wide range of functional and performance requirements, some of which may be unknown when the platform is created.
Surprisingly, the same can be true for the specific devices, which are frequently openly programmable and expected to have a life extending beyond that of the products that drive their development. It is, however, generally true that device requirements are more precise than platform requirements.
Because the SoCs built from OMAP-2 are highly complex, it's not possible to analyze performance satisfactorily using static calculations such as in spreadsheets. Therefore, simulation is used.
The requirements on the simulation technology are first and foremost ease in creating test cases and models and credibility of results. The emphasis on test-case creation is a consequence of the complexity of the devices and of the way in which an SoC platform such as OMAP-2 is used: because the whole motivation is to be able to move from marketing requirements to RTL freeze and tape-out in a very short time; and because in many cases large parts of the software will be written by the end customer and not by the SoC provider (Texas Instruments, in this article), the performance-area-power tradeoff of a proposed new SoC must be achieved without the aid of "the software."
Secondary requirements are simulation speed, visibility of results and behavior, modularity and reusability, and the ability to integrate legacy and third-party models. We created a modeling technology based on:
- Standard cycle-based modeling technology for bus interfaces taken from the Open Core Protocol International Partnership (OCP-IP).
- Privately-developed technology for test-case specification, module configuration, run-time control, and results extraction.
We used cycle-based interfaces throughout, because cycle accuracy is required in some areas and use of a single interface technology throughout the platform was essential. Cycle-accurate interfaces do not necessarily imply cycle-accurate functionality, and in general the OMAP-2 simulations can be described as timing-approximate.
The aim is to move to public domain technology in all areas as soon as appropriate solutions become available. We never use this modeling technology for software development but independently create virtual SoC platforms for software development.
The challenges for the future lie in making this technology usable outside the core OMAP-2 architecture team and in being able to import models from third-party suppliers. Achievement of these goals is currently hampered by the lack of public standards for specifying test cases and configuring and controlling modules.