Co-Design for SOCs -> Iterated co-design right for system ICs

Not many designers have mastered these newer methods and are still using approaches that are no longer adequate. One is to prototype, but the very act of prototyping means that major architectural decisions have already been made. When new information has been gathered from the prototype it is difficult to make major changes.

Another is to use coverification tools. Engineers can run actual software on virtual processor models along with hardware code running on a Verilog or a VHDL simulator. However, the problem with this technique is that it comes too late in the design cycle, aft er major chunks of hardware and software have already been put together. It's more appropriate to use coverification tools to verify hardware-software interfaces and to iron out last minute kinks in the functional implementation before actual physical hardware is built.

Then, some engineers write extensive models of their systems using Verilog, VHDL or a high-level language like C. This methodology encounters the same problems-it is a time-consuming, expensive and inefficient way to do architectural design. As more code is written more key architectural decisions are made. Later in the cycle it is difficult to make major changes.

Finally, some design teams "over-design" in order to leave plenty of margin in the system. Over-designing ensures that performance will be adequate and that the system should work during test. But it's not a cost-efficient tactic and it ends up cutting into profits. And the problem is further compounded by the practice of handing off the architecture to separate hardware and software teams that start implementing without proper communication.

What is really needed is co-design coupled with iterative system design. Co-design means simply that all the people who contribute to the development of a product are involved in the design process from the very beginning. System design should be a collaborative effort among the system designer and the hardware and software groups. The hardware and software teams know what performance requirements must be met, so including their input from the beginning will save time, effort and resources later on.

Iterative design means applying good problem-solving methodology at the system design stage to map the behavior or functionality of the product to an architectural platform.

The first step is to clearly separate behavior or functionality from architecture, which is composed of hardware and software enti ties. It is the means by which the behavior or functionality is implemented. Some behavior will be mapped to dedicated hardware; other behavior will be mapped to processors; some may be mapped to software. Tokens representing data and commands will flow through the system and will be operated on by the hardware and software entities.

In the iterative system-design process, behavior is mapped into a possible architecture and evaluated. The results of the evaluation are used as the basis for making changes to the architecture. Various alternatives can be tried so that the optimal architecture can be selected. But, for an iterative process to function efficiently, results of an architectural change must be evaluated quickly. The key is to start off by keeping the model as behavioral as possible. Paradoxically, by using less detail one gets a better feel and understanding for the system.

The initial entry of the architecture into the system is done manually, where the designer uses his or her e xperience to perform an initial partitioning. Once the behavior has been mapped into the architecture, then the performance can be analyzed. A behavior mapped to software will have two types of delays: those resulting from the clock cycles on the processor taken up by the software and those caused by the overhead of the operating system or kernel.

Similarly, hardware entities also have delays associated with them. For example, a digital filter implemented in an FPGA will have a delay as it processes a data packet. A bus system will have delays as data flows through it and it contends with various data sources.

A simulation run on a model of the system will provide a feel for the performance of a particular architecture. Problems such as how the system meets throughput, and utilization, reaction time and latency requirements can be evaluated. Alternative system architectures can be modeled and performance of the various models can be compared.

It is also important to understand arch itectural sensitivity to changes, how much slack there is and what conditions could cause the system to break. For example, if one is building an image-processing system that is being designed for 15 frames per second, what will happen if 30 frames per second are processed? The recommendation is to stress the system, sweeping through the parameters.

Using co-design and iterative system design reduces the risk of the system's not working the first time around. Design cycle time is reduced because changes do not have to be made to the architecture late in the design cycle. Also, the time spent in prototyping and building models in C and HDL is reduced and cooperation between hardware and software teams results in better designs. In addition, the most cost-effective product is developed and the product is neither over- nor under-designed.

The iterative co-design methodology is extensively used in Viewlogic's eArchitect. It is constructed at a behavioral level of detail, allowing changes to the system to be easily made and provides very fast simulation and clear data-visualization tools.

Both hardware and software architectures can be captured in one unified system model early in the design cycle, and functionality can be mapped into different architectural blocks. eArchitect can then look at performance of the model. A system model is generated that system designers, hardware engineers and software engineers all can relate to.

It also provides the ability to capture software at the architectural level, organizing software as block diagrams of tasks that may execute on any of the processors in a system design. The details of the software are captured either as a textual description or as a flow chart. This methodology also allows the designer to capture basic software control structures, data flow and cycle-count budgets.

The behavioral nature of this architectural system model makes it easy to make modifications and to simulate the effects of the changes very quickly and allows visualization of performance for such things as data throughput, latency, software utilization and hardware utilization.

Performance simulations are orders of magnitude faster than full functional simulations because eArchitect utilizes an efficient event-based performance simulation, allowing modifications of the effects of changes to be done quickly.