In recent weeks, executives from major IC houses and EDA companies have been talking about the design challenges facing hardware and software developers as System on Chip designs proceed from 65, to 45, to 32 nanometers.

For example, at the recent Future Electronics Horizons Forum in Budapest, Hungary, both Robert Ober, an executive in AMD’s office of strategy and technology, and Wally Rhines, chairman and CEO of Mentor Graphics, talked about the need to work at higher levels of abstraction to create design files that generate both the hardware and software needed.

Fortunately, they are not alone in the need for such tools and a number of system level design startups companies, with varying degrees of success, have been moving in this direction. And the good news is that we are already, as an industry, more than halfway there, yielding significant improvements in the form of compact architectures, better algorithm implementation, multi-processing speed, power-tradeoffs, memory access and integration of hardware and software design flows.

While getting to the ideal design environments that Ober and Rhines  talk about is not easy, it is achievable.

What it takes to get there
But getting to there dealing adequately with the information needed, cross pollination communication and a strong development methodology; depending on the nature of the anticipated system, subsystem, or element of a subsystem.

The structure, composition, scale, or focal point of a new/incremental system design incorporates the talents and gifts of the designer using either a top-down or bottom-up design style. Is a centralized or distributed approach to processing the best approach to achieve the best price/power/performance? Is a symmetrical or asymmetrical topology warranted?

How to answer to such questions? One starts with a conceptual block diagram, refines the design specification based on integrated simulation results, and is made available for everyone in the product hierarchy as early as possible.

There are many views for a “design” level specification and can contain one or more conceptual block diagrams. The differences between block diagrams might reflect the level of abstraction and detail represented, or conversely, the type of system. A statistical model of a motherboard might include an abstract model of the processor but a detailed model of the memory hierarchy. After creating a conceptual block diagram, what methodologies are available to evaluate the system performance in terms of system throughput, system power, system latency, resource utilization, as related to cost?

A design level specification captures a new or incremental approach to improving system throughput, power, latency, utilization, or cost; typically referred to as price-power-performance tradeoffs. At each step in the evolution of a design specification, well intentioned modifications, or improvements, may occur. What happens to the system design process if a well intentioned design specification change impacts the original conceptual block diagrams, such that design margin for system throughput drops from 20% to 5%? The time required to evaluate a design modification before, or after, the system design process has started, can vary dramatically, and a design level specification will reduce the redesign time.

Figure 1 Top-down design provides greater refinement of the design choices at smaller geometries.

Early on, spreadsheets were popular for estimating average throughput, power, latency, utilization, and cost at the system level when napkin-based designs hit the limits of scalability. As design became more parallel processing oriented, spreadsheets encountered problems with handling non-deterministic traffic, concurrent processing, estimating peak system performance, and resolving mistakes in a spreadsheet, that were not readily apparent. To resolve digital system modeling issues, C/C++ provided internal synchronization in the form of software generated clocks or events, common resource objects, user-defined classes, etc.

The problems encountered with C/C++ were related to the envisioned “modest” programming effort. Software bugs were more difficult to find in increasingly complex software that resolved some of the EXCEL spreadsheet issues. Nonetheless, better performance modeling results were obtained with substantial programming effort. It was difficult to exchange models from one company to another or one group to another group. Their golden reference models lacked a common frame of reference, or sometimes referred to as interoperability. In the early 1990s, the combination of low cost workstations, and modeling tools needing a common frame of reference started to appear in the marketplace.

Several system level tools, such as BONeS Designer (Block-Oriented Network System Designer), OPNET Modeler, SES Workbench, CACI COMNeT and Virtual Component Co-Design (VCC) appeared to provide the notion of time-ordered, concurrent system processes; embedded software; algorithms, and data types.

Many of these tools are graphically oriented, which reduces the need for extensive C/C++ coding efforts, replacing standard modeling functionality with graphical representations of common functions. If specific functionality was required, the user could create a custom-coded element, or use an existing library element, depending on the libraries supported by the tool. The afore-mentioned tools focused on improving modeling capabilities in terms of performance modeling, ease of use, model creation time, and post-processing of modeling results. Some of the issues with these early system level modeling tools is that they were suited to specific classes of systems, added their own syntax to graphical modeling, and sometimes lacked sufficient libraries to solve many modeling problems.

System Level Modeling
As SoC designs shift from 65, to 45, to 32 nm, the system level modeling space is much more complex due to 30% to 50% increase in devices. This consists of both methodology-specific and application-specific modeling domains that overlap to some extent.

Table 1: Application-specific modeling domains

Methodology-specific domains consist of discrete-event, cycle-based, synchronous data flow and continuous time. These models of computation provide a modeling methodology for general classes of modeling problems. The discrete-event model of computation is used for digital portions of a design that may have a strong control flow component.

A discrete-event model of computation is very efficient for higher levels of abstraction, as the current simulation time is based on both deterministic synchronous and asynchronous events. Discrete-event models provide a user with both time-ordered (asynchronous) and concurrent (synchronous) event modeling capabilities.

A cycle-based model of computation is similar to a discrete-event model of computation with the proviso that the model is clock-driven, executing the simulation engine for each clock cycle. Cycle-based simulators provide a user with more modeling fidelity, meaning that they usually are used for more detailed modeling of digital systems, including verification of the final design.

A synchronous data flow model of computation is more DSP algorithm oriented, meaning the mathematical processing of Baseband digital signals, whether vectors, arrays, or complex data types. Internal processing of synchronous data flow type models can be simpler than a discrete-event modeling engine, requiring the concurrence of tokens at each modeling block to start processing, and the generation of new tokens to subsequent modeling blocks.

New Thinking needed in shift to 65 nm and below
System level modeling is evolving to solve the original problem cited- how to determine quickly and efficiently the impact of design specification change on the performance of a proposed system. Is the throughput margin now 15% or 5% and the worst-case power maintained at 1.2 Watts?

The design specification itself typically is a Word or Frame Maker document with text, block diagrams and tables. Simulation models contain more detail but are difficult to share with executive staff, marketing, manufacturing, or field support, simply because non-modelers lack the handling expertise commercial tools require. If the system level, or golden level model, could be exchanged among design groups located around the globe, as the design specification, then a proposed change might be evaluated by the marketing organization directly.

A number of advanced tools are beginning to emerge that address these issues. At Mirabilis Design Inc., for example, we have developed a tool methodology based on the University of California's Ptolemy II to embed a system level model into a design specification as a Java Applet. Any internet browser can be used to view and simulate the embedded system level model within an HTML document. In other words, the design specification can now contain an “executable” system level model that other people within the organization can run with a net browser.

No additional software or license is required. The executable model is identical to the tool level model, containing all the parameters and block attributes of the original model. Users can modify parameters to create different operating scenarios and evaluate the functional impact on the specification. To maintain a rigorous qualification process, changes to model connectivity and block operation must still be performed by the original modeling team.

Figure 2: Vision of a Platform Definition for System Specification

Mathematica from Wolfram Research enables researchers to create interactive calculations on the Internet and enable users to compute and visualize results directly from a web browser. Mechanical CAD and Product Lifecycle Management solutions have been providing VRML (Virtual Reality Modeling Language) based approaches to render the simulation models on custom Web-like viewers. National Semiconductor provides WebBench, a set of online tools to create an optimized prototype using customer specification and National’s semiconductors.

As we move toward the goals outlined by Ober and Rhines, a number of technologies need to be evolved. As Rhines points out in the article, merging the specification process and implementation is an enabling technology. Current behavior synthesis is focused on DSP algorithm implementation using a narrow coding practice. For behavior synthesis to be truly valuable, the output must merge data-path and control-path. The implementation path for hardware and software are still disjointed. There must be better integration to ensure the system-level optimization is not lost during the synthesis process.

System specification occurs during the first 30% of the development cycle. Depending on the project schedule and the complexity of the new capabilities, this can vary from 3 months to several years. During this period, a number of architectures, sometimes, hundreds must be explored. System specification exploration tools must be measured based on new metrics that determine the adequacy of these new tools: modeling time, easy of construction, breath and depth of high-level modeling libraries, and open API to integrate legacy knowledge.

In a recent article in EE Times, Ralph von Vignau, director of infrastructure and standards at Philips Semiconductor, suggested a high-level library of functions is essential to accelerate system modeling. How do you select the high-level libraries? What are the important differentiating features of the high-level modeling libraries used in this new 45 nm environment: sheer numbers, degree of specificity, their quality, or their integration? Order of importance? All of the above?

Prior generations of graphical modeling tools might advertise 3,000 plus libraries as a sign of modeling tool maturity and robustness. However, if a new Ultra-Wideband model evolved, these 3000 libraries elements would have limited reuse for UWB, since many are prior generation application specific libraries, or bottom-up component libraries.

SoC libraries: quality rather than quantity
The design methodology used at Mirabilis focuses on the quality and integration of the system level libraries, such that they would have a high likelihood of reuse in a new technology, or another system level model. This approach allows integration of as many as thirty bottom-up component functions into a single, system level, easy to use, reusable module. Four queue blocks replace 24 prior generation queue blocks through polymorphic port support and block level menu attributes, while improving simulation performance.

The industry is rapidly addressing the gaps in merging the "concept to system specification" design space. The challenges that still need to be tackled are making "concept to system specification" a standard curriculum at Universities, increasing industry awareness, and most importantly, early adopters actually doing it.

One possibility is to form an IEEE forum for this emerging top-down design methodology, including the separation and mapping of behavior and architecture, and hierarchical design elements. A more tactical approach has been adopted by Mirabilis Design Inc.: partner with universities and enhance the system design experience in the classroom.

Deepak Shankar is chief executive officer at Mirabilis Design and has over 15 years experience in development, sales and marketing of system-level design tools. Prior to Mirabilis Design, Mr. Shankar was VP of Business Development at both MemCall, a fabless semiconductor company and SpinCircuit, a supply chain joint venture of HP, Cadence and Flextronics. Prior to that, Deepak spent many years in product marketing at Cadence Design Systems. Mr. Shankar has an MBA from UC Berkeley, MS from Clemson University and BS from Coimbatore Institute of Technology.