English
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."
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
Related Articles
- System-on-chip (SoC) design is all about IP management
- Integrating VESA DSC and MIPI DSI in a System-on-Chip (SoC): Addressing Design Challenges and Leveraging Arasan IP Portfolio
- SOC Virtual Prototyping: An Approach towards fast System-On-Chip Solution
- Developing a Reusable IP Platform within a System-on-Chip Design Framework targeted towards an Academic R&D Environment
- IP Exchange Through Handoff for Easy System-On-Chip Design
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)