Reconfiguring Design -> SystemC fills HDL/ C++ gap

SystemC fills HDL/ C++ gap
By Ken Hines, Vice President, Chief Scientist, and Ross OrtegaVice President and Chief Technology Officer, Consystant DesignTechnologies Inc., Kirkland, Wash., EE Times
February 8, 2002 (1:08 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020208S0062

With its broad industry backing, SystemC enjoys a preeminent position among proposed system design languages. But larger issues remain that go beyond language selection. Rather than focus on the design language, designers need to find a system design methodology that deals with system component interactions but is not tied to a particular design language.

A new approach called coordination-centric methodology supports both software development, through C and Java, and hardware development, through SystemC.

Traditional methods fragment system development teams into separate groups, each focused on a particular processor, ASIC, software or system piece of the overall system puzzle. When the team reforms at final system integration and test, the pieces inevitably fit poorly, resulting in suboptimal implementations, delayed delivery and lost market opportunities.

Emerging system design methods based on SystemC promise to provide a consistent m odeling approach and unified foundation for software and hardware development.

SystemC fills a gap between traditional hardware-description languages (HDLs) and software-development methods based on C/C++. Developed and managed by leading EDA and electronics companies, SystemC comprises C++ class libraries and a simulation kernel used for creating behavioral- and register-transfer-level designs. Combined with commercial synthesis tools, SystemC can provide the common development environment needed to support software engineers working in C/C++ and hardware engineers working in HDLs such as Verilog or VHDL.

But while SystemC addresses the gap between C/C++ and HDLs, it is primarily a tool for specification of hardware and hardware/software interfaces. That leaves designers to cope with the same difficulties in high-level coordination of system software (and hardware) that plague system design today. System designers are left with the traditional problems of system design: reusability, retargetabilit y, error-prone tasks related to distributed computing, and difficulties debugging interactions among diverse components.

The problems stem from traditional development methods, which lead developers to create programs that interweave code for application-functional behavior with that for coordination of other system hardware or software components. By intertwining code for function and coordination, developers severely limit their ability to debug the system across multiple software modules, accommodate changes in the target hardware complement, retarget an existing design to new hardware or reuse the code in other designs.

The solution to this common problem lies in separating the target-independent behavior of an application from its target-dependent implementation details. Designed to address system-level design issues independently of target architecture, newer approaches such as the coordination-centric methodology achieve the isolation of function from interaction — the key to developmen t of complex systems.

The coordination-centric approach offers system architects significant advantages when designing systems implemented on heterogeneous distributed architectures that include special-purpose hardware. System designers can target heterogeneous multiprocessor and FGPA- or ASIC-based architectures, reuse system components and manage complex distributed debugging across multiple system components.

Indeed, the new methodology provides a high level of abstraction for building complex distributable systems that are independent of low-level implementation architectures. After developers design, debug and partition their system across processors or ASICs and FPGAs, design teams can continue with detailed implementation using the most appropriate detailed design language — Java or C for software functions and SystemC for hardware-software interfaces as well as all parts of the system that are meant for implementation in special-purpose hardware.

The coordination-centric methodology and its supporting tools let designers more effectively tackle last-minute hardware changes, heterogeneous distributed architectures, nonreusable components and debugging difficulties with distributed processing systems. Companies gain improved resource utilization and productivity as designers reuse software and retarget designs for different hardware bases. The upshot is improved time-to-market despite increasing product complexity, rapidly changing user demands and emerging hardware architectures.

Target-independent design

The methodology separates target-independent design from target-dependent implementation. Designers address target-independent design first, creating abstract models of an embedded system's behavior from reusable functional elements, called components, and separate interaction elements, called coordinators, that capture the interaction details among components (including conn ections, states and transactions).

Components contain coordination interfaces that handle interaction with the coordinators and, via the coordinators, with other components. Coordination interfaces reveal only those parts of a component related to interaction, so behavior and coordination remain isolated.

Components and coordinators abstract system behavior and interaction. Coordinators provide a level of abstraction above SystemC's communications channels, describing the complete interactions among components, including message flow, shared state and the protocols by which interactions occur. Classes of coordinators can be used to abstract SystemC's models of computation. For example, a coordination class can provide a general representation for fixed-message-rate interactions among components, abstractly representing SystemC's synchronous data-flow computation model.

Coordination-centric synthesis tools can generate optimized code that exploits SystemC 2.0 features such as channels, ports, e vents and models of computation as appropriate.

Through its separation of behavior and interaction, the coordination-centric methodology lets developers focus on defining, designing and debugging the components needed in an application, without the distraction and complexity of hardware-specific implementation issues. The approach provides advantages for debugging complex systems through its ability to track problems across multiple software modules and hardware components.

The separation of behavior and interaction also greatly facilitates design reuse, because it avoids the hardware dependencies that have traditionally complicated engineers' ability to reuse existing designs.

Hardware-dependent phase

After designers have assured themselves of the design's correct system-level function at the behavioral level, they move to the hardware-dependent phase of the coordination-centric methodology. Here, engineers explicitly map each component and coordinator to actual system resources, includin g general-purpose microprocessors, special-purpose processors and FGPAs or ASICs.

Based on that mapping, synthesis tools generate Java or C for software components and behavioral-level SystemC code for hardware/software interfaces and other special-purpose logic. The generated software is specific to the target hardware without the need for an intermediate software abstraction layer.

The coordination-centric mapping approach means that engineers can easily target a design to different hardware. It thereby facilitates the development of derivative products and reduces the impact of late hardware changes.