Complex Designs Require 
New Methodologies  

Ghosted for Innoveda (Viewlogic Systems), published in Electronic Update (Japan)

With the complexity of today’s electronic designs increasing at exponential rates, it is essential to get system architecture right before implementation begins.  In the digital systems context, an architecture is comprised of hardware (a collection of application-specific analog and digital hardware, processors, processor bus, memory, special purpose processors), and hardware-specific software (a kernel or real-time operating system, and device drivers).  This is the embedded system platform upon which the system’s functionality will be implemented as applications software (and perhaps additional dedicated hardware).

Mistakes or under-design at the system level may not become apparent until well into the hardware and software implementation phase, or worse yet, the system integration phase.  At that point, design teams must go through several physical prototyping iterations to correct mistakes.  When this happens, a product’s competitive advantage is lost because of schedule delays, budget overruns, and/or compromises in system performance.

Increasing complexity also makes it essential to reuse system designs whenever possible, since reinventing the wheel with every new version of a product is also costly and time-consuming.  In the past, an experienced system architect could specify an architecture that would work by intuitively using his or her accumulated knowledge to make the numerous trade-offs required.  But when essential architectural design information exists only in someone’s head or in a notebook stuffed in the bottom drawer of a desk, there is no way of capturing that information for reuse. 

Some overhauls of the way architectural design is approached are essential, as well as changes in the way system, hardware, and software designers work together – or more accurately, the way they don’t work together.  To understand what changes must occur at the system design level, it is necessary first to examine current design flow methodologies, as shown in Figure 1.

The electronic design flow process starts as a set of system requirements that defines both functional and architectural constraints for the product.  When design work based on these requirements begins, functionality and the architecture are developed.

In the architectural design process, the engineer experiments with a variety of architectural configurations and then analyzes their performance.  The primary goal is to develop an architecture that meets performance requirements without exceeding cost, power and size constraints. In contrast, the functional design process consists of defining in detail the functions the system needs to perform in response to specific stimuli.  

The two design processes are interdependent, but are ultimately integrated into a system specification that encompasses both architecture and functions of the system.  This system specification then is used to implement in detail the system with its specified hardware and software functions.  The final stage is the test and integration of the actual physical system. 

Challenges

The biggest challenge in eProduct (a product defined by its electronic content) design lies in the initial system design phase, because decisions made at this point determine the success of the product.  It is also where mistakes or sub-optimal choices have the greatest negative impact on the product’s success.

The system architect typically designs the system with very little input and feedback from the hardware and software groups.  Because of the lack of true architectural exploration tools in the marketplace, engineers are forced to rely on paper and pen at this stage of the design process.  Often, it is only after the system designer has developed the full specification of the system that it is handed off to the hardware and software teams.  Thus architectural design is often a process of trial and error involving haphazard selection of functional elements.   The designer lacks input from the hardware and software teams about the impact of these choices on system performance, and is forced to rely on paper and pen to aid in analysis of complex systems.  Herein lies the major flaw of today’s methodologies.

A New Methodology

To come up with the right architecture at the outset, three major changes need to be applied to the way a system architecture is designed: co-design, maximum design reuse, and iterative system design.

In co-design, the system designer and the hardware and software groups are involved in a collaborative effort from the very beginning.  The hardware and software teams know what performance requirements must be met; therefore, including their input to the system designer at the outset will prevent under-design and errors, and will save time, effort and resources later on. 

Equally important is the need to reuse designs whenever possible.  Quite often a product has several versions with only a small number of features changed to meet certain price points.  Dramatic reductions in time, and therefore cost, can be realized by redesigning only those parts of a product that have changed.  A way to capture and store designs efficiently is crucial.

The iterative system design process consists of mapping system behavior onto a possible architecture, evaluating it, and making changes to the architecture according to the results of the evaluation.  Various alternatives can be tried so that the optimal architecture can be selected.  This is how architectural exploration is accomplished early in the design cycle.

The first step is to clearly separate functions – or behavior – from architecture.  This separation enables the system designer to use abstract models of architectural components that can be simulated quickly.  This in turn enables efficient exploration of alternative architectures to find the most appropriate one.  The key is to start off by keeping the model as abstract as possible.  Paradoxically, by using less detail one gets a better feel and understanding for the system.

Once the behavior has been mapped into the architecture, performance can be analyzed.  A simulation run on a model of a system will provide a feel for the performance of a particular architecture, including how the system meets resource contention, throughput, utilization, reaction time, and latency requirements.  At this stage, changes can be made to the architecture and then re-evaluated and compared with the other models.

It is important to determine how sensitive the architecture is to changes and how much slack exists, and what conditions could cause the system to break.  Due to the speed of simulation, the system designer can sweep through the range of system parameters and thus stress the system.

Viewlogic’s eArchitect™

All of these solutions are implemented in Viewlogic’s eArchitect, an architectural prototyping tool that enables designers to concurrently analyze hardware and software architectures in the front end of their design.  eArchitect enables and facilitates design reuse, iterative system design, and co-design.  It provides a system model that hardware and software engineers, as well as system designers, can interact with because it is constructed at an abstract level. An engineer in any of the three disciplines can easily make changes to the architecture.  Using eArchitect, designers can quickly analyze the behavior of a system and develop an architectural specification for a design that works right the first time.

eArchitect enables maximum design reuse by capturing and archiving the architecture behind a design. When new designs are being considered, the old architecture can be called up and changes made to it in a speedy process to see if it is suitable for the new designs.  There is no longer any need to reinvent the wheel repeatedly.

Hardware models are constructed quickly in a block diagram format using elements from the eArchitect library. Functional elements are modeled only with respect to their throughput, response time, or latency, not their actual behavior.  This abstraction allows for a huge improvement in simulation speeds. Software is captured and organized as block diagrams representing tasks that can execute on any of the processors.  The details of the software are viewed as a textual description or flow chart showing basic software control structures, data flow, and cycle count budgets.  Since the hardware and software are captured at a very high level, time-consuming implementation details do not complicate issues at the architectural level.  This creates the necessary environment in which system designers can collaborate with hardware and software designers early in the design cycle.

For an iterative process to be effective it should have a very short cycle time between design alterations and system evaluation.  The abstract nature of the eArchitect architectural system model allows designers to quickly get performance results such as data throughput and latency, to visualize software and hardware utilization, to make modifications easily, and to simulate the effects of the changes orders of magnitude faster than full functional simulations.

The combination of easy system modification, fast simulation and data visualization helps to shorten the time required to complete each iteration in the architectural design phase, and allows multiple architectures to be explored efficiently and easily.  System, hardware, and software architects can, through a collaborative and iterative process, evaluate and agree on the best architecture to meet system requirements because the hardware and software aspects of the system are captured in the same model.  Any design can be captured and saved in a library for future modification and reuse.  This feature alone dramatically reduces product design cycles.

Because eArchitect enables and greatly facilitates design reuse, co-design, and iterative design early in the design cycle, the bottlenecks of prototyping and late-stage design corrections are eliminated, time to market is shortened, and costs are lowered.  These add up to competitive advantage and greater profits.

Back to top       Back to Toni McConnel's Resume.

Back to Word Sculptors home page.