Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Power/Alternative Energy
Power/Alternative Energy??

ASIC generation revamped for IP reuse

Posted: 01 Jun 2001 ?? ?Print Version ?Bookmark and Share

Keywords:vliw? ip core? soc? asic? csu?

True IP reuse for SoC is only possible when the system designer and chipmaker move away from the fixed-point ASIC approach and adopt IP cores for reusability.

Deploying a programmable VLIW processor IP core with the required application-specific accelerators allows the designer to make the most from previous design efforts. This design approach is becoming more important as greater SoC functionality is being translated from hardware into software. The linchpin for complete IP reusability in this instance is the anchor block or programmable VLIW processor core, along with programmable buses and interface ports.

But this design methodology is slightly different than conventional IC design. Instead of a singular IC model, the design engineer uses a modular design approach. Interfaces to these modules, which are OEM-dependent, are especially critical in SoC designs. Many OEMs rely on their own bus models, since they have extensive design experience with those buses and have a good handle on their performance.

However, in most designs today, low power is in great demand. Die size is an important consideration from a design cost point of view; flexibility is playing an even more critical role due to evolving standards and user demands for more features and functions. In some SoC designs, special technologies are required. As for IP reuse, the designer should determine the importance level of having wide reuse of these IP cores.

Portability the rule

With the increased usage of the Internet in virtually every aspect of life, portability is becoming the rule rather than the exception. This portability demands low power consumption. Reducing power consumption in a SoC design is paramount for IP reuse since a great majority of applications now demand increasingly lower power.

Lowering the voltage in a SoC design is the best method to cut power consumption. The designer can lower the voltage on SoC designs that are not latency sensitive. To maintain bandwidth, the designer can place added pipeline stages in the design to cut back the amount of logic between each stage. Consequently, the engineer gets the same bandwidth and clock frequency, but a much lower-power SoC design.

As for active clocking techniques to reduce power, the designer has two options. One uses clock enables; the other is clock frequency control. Power consumed in a SoC design is proportional to clock frequency. With clock frequency control, the designer slows down the original clock frequency of selected clocks.

OEMs using SoC designs may already have an established framework for logic verification. The essence of supporting co-simulation is to provide clear functional interfaces to the co-simulation units. The result is a simulation system that supports a SoC model of simulation in which different cores can be plugged in and standalone simulators or SoC simulators using different co-simulation frameworks, can readily be built.

This simulator architecture is a modified discrete-event simulation based on all-in-C implementations of co-simulatable units (CSUs), which, when wrapped to interface to a particular co-simulation framework, form atomic co-simulation units. These CSUs have clear functional interfaces, meaning function calls and callbacks, not ports and signals, which allow co-simulation shells to be easily created for any co-simulation framework.

Aside from co-simulation, the clear interfaces between CSUs allow easy evolution and adaptation of a system in a standalone simulation.

To efficiently support SoC customization and at the same time, avoid seriously compromising speed in standalone simulation, the designer needs to wisely choose the boundaries between CSUs. Too many interfaces can introduce unnecessary performance overhead. Conforming to the goals of this architecture, a system is usually divided into CSUs representing the processor core itself, system bus interfaces and devices on the system buses.

Co-simulation shell

TSS is Philips' proprietary hardware/software modeling system that supports clock cycle-based, signal-level interfaces between modules. To support TSS co-simulation, each CSU is wrapped in a co-simulation shell. Each shell is a regular TSS module that implements module ports in the TSS netlist.

Non-trivial protocol implementation is performed via state machines clocked by the appropriate TSS clock. Non-trivial protocols respond to function calls from the CSU's functional interface and make callbacks of the CSU's interface. A clock process triggered by the proper TSS clock calls the CSU's clock function.

CoWare, used for hardware and software partitioning, supports functional or clock cycle-based signal-level interfaces between software modules and clock signal- level interfaces between hardware. CoWare provides the designer the framework for plugging in all modules required in a given SoC design.

Leaves GUI behind

SystemC is an open-source answer to CoWare without the GUI. It is a general hardware/software modeling system that supports functional- or clock-cycle-based, signal-level interfaces between software modules and clock cycle-based, signal-level interfaces between hardware modules. SystemC is built with C++ classes, which provide extensibility without extending the language.

To support SystemC co-simulation, each CSU is wrapped in a co-simulation shell. Each shell is a module implemented at the bus cycle accurate abstraction level using bus ports.

? Mohammad Ayub Khan

TriMedia Technologies Inc.

Article Comments - ASIC generation revamped for IP reus...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top