Co-Design for SOCs -> Designers face chip-level squeeze
Designers face chip-level squeeze
By Bernard Cole, EE Times
June 15, 1999 (11:49 a.m. EST)
URL: http://www.eetimes.com/story/OEG19990615S0013
In the early 1990s, the challenges of transforming basic hardware building blocks-microprocessors, DRAM, SRAM, EPROM, timers and other peripherals-via software code into a board-level design targeted a specific application. While the challenge has not changed, the level of integration has, going from a board-level "anything machine" to a chip-level "anything chip" that contains all of the basic building blocks. Through the use of VHDL and Verilog files as well as software techniques a circuit is created that is designed for a specific application. For instance, when introducing a new architecture, semiconductor and microprocessor manufacturers are likely to describe the features and performance of the CPU as a "soft core," a description in a high-level language that can perform over a wide range of specifications, depending on the process technology chosen to convert it into silicon form. In fact, several major vendors were so confident of their simulations at last month's Embedded Microprocessor Forum in San Jose, Calif., that they chose to announce architectures that in many cases were not yet in silicon. The dilemma for many embedded designers, say experts, is that the shift from system on a board-or system on a module-to system on a chip (SOC) is how to retain many of the tried and true methodologies that have worked in the past in the development of reliable hardware and software, adapt them and add new tools to their repertoire of tools. Indeed, efforts are under way to develop both proprietary and industry-standard on-chip processor and peripheral buses that the embedded developer can mix and match with CPU cores and the necessary IP functionality in much the same way that a designer now uses a board-level bus. However, Bob Morasse, technical manager at Intrinsix Corp. (Westboro, Mass.) points out in this week's focus section on the challenges of embedding SOC that a new framework is needed to integrate and use both the new and old tools. But it will also take some additional evolution of the SOC and EDA tools that have become common in ASIC design, according to Binoy Yohannan, product marketing manager at Viewlogic Systems, Inc. (Marlboro, Mass.): For example, a shift from a purely codesign methodology, to an iterative codesign way of working that is more familiar to the embedded designer. Unfortunately, current EDA tools can only take a design after the main architecture choices have been frozen; that is, after hardware/software partitioning and processor allocation are done, notes Phillippe DiCrescenzo, director of applications engineering at Arexsys SA (Grenoble, France). And while the more familiar C is being used as often as VHDL and Verilog in embedded SOC designs, using C does not really raise the level of abstraction. James Hakewill, chief architect at ARC Cores Ltd. (Edgware, England), describes the challenge for IP suppliers and their embedded-system customers in building systems that provide t he ability to "open the box" of the component so that the user can configure, customize and understand. He points out that whatever solution is selected it must ensure that both the component and the larger system can be verified, debugged and manufactured. However, not everyone is convinced that the EDA-ASIC-SOC approach is the only way to go-they are betting their futures and those of their companies on other alternatives. George Alexy, president of TeraGen Inc. (Sunnyvale, Calif.), describes "a collection of VLIW-like thread engines" that employs an on-chip real-time operating system to manage the multiple independent processes that represent the function of the chip. Alexy believes that the semiconductor suppliers' current thinking and approach to configurable SOCs is to take various independent IP blocks, stitch them together on the same silicon die and then layer an operating system on top. That approach, he said, doesn't work because it is complex, offers little flexibility in producing varian ts, has almost no up or down scalability in performance and has minimal design reuse ability.
Related Articles
- Co-Design for SOCs -> Software debug shifts to forefront of design cycle
- Co-Design for SOCs -> 'Ramping-up' for complex multiprocessing applications
- Co-Design for SOCs -> Blend of tools needed for verification
- Co-Design for SOCs -> Embedded SOC takes new codesign tricks
- Co-Design for SOCs -> Iterated co-design right for system ICs
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)
E-mail This Article | Printer-Friendly Page |