Using SystemC to build a system-on-chip platform
James Aldis, Texas Instruments
EETimes (2/2/2011 1:11 AM EST)
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."
To read the full article, click here
Related Semiconductor IP
- TSMC 7nm 0V75 / 0V9 ESD Local Clamp – Low Cap
- TSMC 65nm 3V3 ESD Local Clamp – Rad Hard
- TSMC 5nm 1V8, 1.2V and 0.9V ESD Local Protection – Low Cap
- TSMC 3nm 3V3 ESD Local Clamp
- TSMC 3nm 1V2 ESD Local Clamp – Low Capacitance
Related Articles
- Understanding and Extending SystemC UserThread Package to IA64 Platform
- A RISC-V Multicore and GPU SoC Platform with a Qualifiable Software Stack for Safety Critical Systems
- Pondering the SoC platform
- Reconfiguring Design -> SystemC fills HDL/ C++ gap
Latest Articles
- LACE: Large Language Model Aided Multi-Agent Framework for Agile RISC-V Instruction Extension
- A Process-Aware Hybrid Si/IGO Monolithic-3D 6T SRAM with BEOL Pass-Gates for the 2nm Node
- Automated Estimation of MBIST Area and Test Time in Heterogeneous Memory IPs via Stacked Ensemble Framework
- VIPER: Architecture-Aware Performance Modeling for Processing-in-Memory Design-Space Exploration
- CTTE: An Open Dual-Protocol RISC-V Trace Encoder for N-Trace and E-Trace