SoC Configurable Platforms -> Taking flexibility to the max in platforms

What happens when one block of the platform is swapped out for another? How long is it going to take your design team to develop the new hardware and software interfaces for the new processor, bus or peripheral?

For example, your design might work just fine with an ARM9 processor now, but add a few more features and that ARM9 is going to be stressed. Maybe it's time to move up to a PowerPC, but you know it's going to take months to rework your platform for a new processor.

Redesigning your platform for a new processor can be excruciatingly painful. Most often, you virtually have to start over because the interfaces between the processor and the rest of the chip all need to be redone.

The details of all of the necessary interfaces are often found in manuals that are hard to understand, poorly organized and sometimes missing crucial information. Yet every time a major system element is changed, most designers must go back to the manuals.

Designing a system-on-chip with the right methodology and tools can solve a lot of those interface problems. Key to this design process is a system-level specification that can be debugged and used throughout the design process as a golden functional model. Also key is a capability, called interface synthesis, that significantly speeds design by synthesizing all of the time-consuming creation of hardware and software interfaces.

Using this methodology and tools, STMicroelectronics Inc. (Carrollton, Texas) has been able to cut platform-based design from 24 months to six months and the time required for a derivative platform from 10 weeks to two to three weeks, dep ending on complexity.

The first step in designing an SoC is to decide what you want to design. By developing a formal specification in C/C++, you avoid a lot of the ambiguity found in specs written in English. Even more important, the specification is executable and can therefore be tested. The environment model serves as a system-level testbench that can be used to verify functionality throughout the implementation process.

While an executable specification ensures that the correct functionality is implemented, certain aspects of the specification, such as performance and power consumption, are highly implementation-dependent.

How do you make these decisions? You refine your model, putting in a processor and testing to see if that processor has the horsepower to deliver all of the functionality required. If that processor seems like overkill or doesn't del iver enough horsepower, you try another.

Sounds easy, doesn't it? However, without the right tools, it's just too time-consuming to test out a design with a particular processor and then swap that processor out for another-or make other critical design tradeoffs. Once the processor decision has been made, it is an important commitment-one that can't easily be reversed. The most critical commitments have to do with the interfaces to the other parts of the chip and the software running on the microprocessor core. And here's where the basic problem lies.

Currently, designing the hardware/software interfaces is an increasingly complex, lengthy manual task. The possible hardware/software information exchanges include software writing to hardware configuration registers, software reading status and counter registers, and the hardware notifying the software about events by means of interrupts. All of this must be done as a foundation to see whether the right processor is being employed.

With the right tools, the whole process is vastly simplified. To make design exploration a practical reality, CoWare's N2C slashes design iteration time by enabling designers to quickly model a new version of a system, simulate it and then analyze the results. Since the hardware can be designed at a high level of abstraction, simulation and modeling are orders of magnitude faster. If a design assumption requires further investigation, an incremental design flow enables the relevant portion of the design to be implemented in more detail and tested in the context of the complete system.

CoWare N2C employs interface synthesis, a design technology that automates the process of connecting the different system hardware modules and interfacing them to the software. Interface synthesis also enhances intellectual property (IP) reuse by enabling designers to quickly plug-and-play different IP components. To simplify analysis, CoWare N2C provides high-level views that enable designers to understand complex system b ehavior at a glance. That eliminates the need to painstakingly infer overall system behavior by studying registers or waveforms.

Interface synthesis automatically implements the appropriate interface logic or software between system functions. The synthesized components include address decoding, interrupt priority encoding, arbitration units, memory-mapped registers, program and data memory, interrupt service routines, boot code and methods to access memory- mapped registers.

Automating this tedious and error-prone process frees the designer to focus on more value-added design. The designer doesn't have to spend weeks pouring through 500-page manuals that describe in English all of the features of the interface. Automating also ensures quality in interface design. And it helps designers examine new SoC design variants created by choosing a different hardware/software partition or IP model.

Interface synthesis simplifies the process of assessing and selecting the optimal intellectual p roperty for an application. Designers can introduce new IP components without needing to handcraft the interface logic required to build a new simulation model of the entire system.

With interface synthesis, the interface between the IP block and the target processor or system bus can be designed without any detailed knowledge of the processor or bus specification, protocols, timing diagrams, memory map and interrupt vectors. Instead, the designer specifies how the IP block interfaces to a much more abstract virtual bus. Once the designer has selected a specific bus protocol, interface synthesis automatically generates the correct interface logic between the target processor/bus and the IP block.

CoWare Aware IP

Only one IP block needs to be designed and maintained to interface to many different processor and bus targets. This considerably simplifies design, documentation, delivery and support of IP blocks. IP designed to interface with the virtual bus is known as CoWare Aware IP. Pre-existing IP blocks can also be made "CoWare Aware" by capturing them for use in CoWare N2C with a simple wrapper.

A further advantage of the CoWare IP reuse methodology is that C or C++ representations are maintained for all IP blocks in addition to more hardware-specific representations. This facilitates moving specific functions across the hardware-software partition. Such functions typically move from hardware to software in subsequent product generations and from software to hardware in derivative products within a generation.

How do you make these important design trade-offs? You need tools that provide a rich graphical analysis environment with a point-and-click interface that lets you set probes at any point in a system's hardware or software modules and view analysis data. You need to be able to perform custom configuration or post-processing using a scripting language, such as Tcl/Tk.

Most of all, you need a tool that provides a variety of high-level analysis views . Gantt charts are useful to plot system response and temporal relationships between systems components. Bar charts and graphs help illustrate code hotspots, processor loading, and bus and memory performance issues, such as the number or frequency of bus contentions and retries, cache hits and misses, and paging behavior. And you need system-level simulation that covers all system component and bus activity, providing accurate statistics on switching activity to help estimate power consumption, since CMOS components consume the most power when switching states.

Once an initial partition between hardware and software is selected, a good system-level design tool like CoWare N2C can compile and link the software functions to execute on the instruction-set simulator for the chosen processor. Co-simulation is possible with any level of hardware abstraction, whether untimed C, cycle-accurate C, or register transfer-level hardware description language (HDL). As a result, a hardware virtual prototype is avai lable as soon as a partition is made.

The virtual prototype enables the software and hardware teams to work in tandem through the complete project cycle rather than having to wait for an actual hardware implementation. A further advantage is that the virtual prototype provides much more debugging visibility than the actual SoC itself. As a result, problems can be debugged much more quickly, further shortening development.

A successful co-design environment demands the integration of many disparate components. From a software perspective, it may be necessary to integrate the instruction-set simulator, the software development tools, and a real-time operating system. For hardware development, integration of the local and system bus models, memory architecture, IP cores, and the HDL simulator of choice may all be required.

The old way to design an SoC is broken. It takes too long, makes a design that's too difficult to change, and often makes companies miss important market windows. Movi ng up to C-based design has been widely promoted as a way to speed the design process. However, just moving up to C is not enough.

Designers must move up to employ tools that speed them through the design process. By employing system-level design tools that use capabilities such as graphical analysis, interface synthesis, and system-level simulation, designers can reduce overall platform-based design time as STMicroelectronics did-from 24 months to six months. And they can cut the time required for a derivative platform from 10 weeks to between two and three weeks.