system design

Integrated System Design Environment Lowers Development Risk Today's complex systems need more, and earlier, attention to system-level design to reduce risk and verification time and to promote IP reuse. by Bob Schultz

The increased complexity of systems implemented in silicon is rapidly shifting the focus of product development activities from traditional design engineering environments to system engineering environments. A prime example of such a shift is in the development of complex ASICs used in modern telecommunication systems. Here, the pressure to increase bandwidth, improve performance, and lower the cost of modern systems presents new challenges and risks to both designers and managers responsible for component development. One of the biggest risks lies in creating a design environment that focuses so much on the efficient transfer of intellectual property into silicon that it fails to preserve IP from silicon for future reuse. The remedy: an integrated system design environment that represents all aspects of ASIC design in a single view.

Figure 1	A TDMA ASIC core
The design of a modem communications subsystem, such as the simplified TDMA circuit shown here, requires the engineers to model many complex interactions and functions, implemented as cores and custom blocks.

In the early 1990s, ASIC designers moved from CAE tools based on schematic capture to EDA tools based on HDLs. The direct response to improvements in process technology made fabrication of complex digital systems on a chip cost-effective. Modeling digital systems in Verilog or VHDL provided the bridge between simulation and synthesis that component designers needed to implement a design. Though the tools have facilitated the translation of high-level design ideas into silicon, they haven't worked as effectively in the other direction. Specifically, HDL-based simulation environments that output 1s and 0s can't adequately support the behavioral modeling complexity of system integration required by modern communication systems. HDL-based simulation environments lack the basic analytical tools necessary to verify system-level performance. Therefore most system engineers responsible for the architectural development of those systems don't use traditional EDA tools and design engineering environments. The use of different development environments by system engineers and design engineers, though, represents a significant element of risk in the product development process.

The risks are emerging just at a time when advances in process technology are again forcing basic changes in the development process of complex systems implemented in silicon. The changes occur not in the physical design process, but in the system design process. Design reuse and the focus on developing and integrating core functions mandate more sophisticated modeling environments that combine the system-level model and the physical and verification models into an integrated system design environment.

Over the past six years, we at Silicon Arts have learned that the primary challenge is often not the development of device code in Verilog or VHDL. It's more important for us to integrate the system-level architecture with the physical model to ensure that the device code we develop in our EDA environment meets the system requirements of the project. The first step in such a process is to identify the form of the architecture in terms of a system model. The final step is to develop a test and verification environment to guarantee that the HDL-based device code meets the requirements specified in the system model. Obviously, a prerequisite for both--and all work in between--is to develop a sufficiently robust system model in an environment comprehensive enough to create it and then analyze its behavior. Ultimately, the development of system models in an integrated system design environment is often the approach best suited to easing the generation of a physical model of the target architecture, reducing the risk and cost of the final design engineering process, and creating reusable IP.

Environmental ideals

The ideal system design environment includes all the analytical tools required to visualize and validate the architecture of the target system. The architectural development of a complex communication system requires an integrated development environment with both time and frequency domain analysis tools, as well as a wide range of signal sources and channel models. The system model developed in the system engineering environment should directly correspond or link to the HDL model developed in the design engineering environment. A highly desirable hierarchical graphical interface would allow tight integration between design engineering and system engineering activities, taking into account the fact that the analytical domain of the system engineer differs significantly from that of the design engineer. The design engineer is constrained by the laws of physics and available process technology, the system engineer by frequently abstract project requirements and his own imagination.

Table 2	Verilog test bench
Use of the system-level design as a test bench drives the verification of a an HDL implementation (in this case, Verilog). Using a high-level language (C) allows a single system model to generate test benches for many layers in the hierarchy.

The choice of a system modeling process often establishes the effort needed to generate a physical model of the target architecture. It's also a major factor in determining the risk and cost of the total design engineering process. Most system engineering occurs at three levels: full-custom design of the system model in a standard programming language, such as C; algorithmic design, which employs point tools; and design in an integrated system environment.

Development of a full-custom model of the target system architecture in a standard programming language offers the distinct advantage of fast execution time; speed significantly benefits the performance analysis of communication systems required to process millions of symbols. One of the most painful experiences we had was processing 260 million vectors through a 1/2-rate k=9 Viterbi core modeled only in VHDL. Generating full performance curves for the design took over a month of CPU time. The primary disadvantage of a full-custom model is the need to design custom analytical tools or links to other analytical tools. Only very experienced system engineers with good software skills should attempt that level of modeling.

Table 3	A Simulink model
In a typical top-level architecture of a system model under test, Simulink provides models of the simple interface that permits convenient tuning and testing of design parameters in the target system.

Choosing to create a system model in C also demands that the design team pay attention to the development of a test and verification process. Verification of that type of model is often limited to the use of stimulus and response vectors exchanged among the various models. Adding complexity, the system model needs to include file generation processes to capture the test vectors, and the HDL test bench often requires PLI development for Verilog-based designs or text I/O processes for VHDL-based designs. As a result, systematic evaluation and optimization of design parameters in custom C models of complex systems is time-consuming and cumbersome and should apply only to systems based on very stable system parameters.

At the second level, algorithmic modeling environments often include a rich set of analytical tools and standardized macrofunctions that simplify model development and analysis. When it comes to demonstrating the system-level performance of a communication channel, a picture is worth a thousand baud. Unfortunately, systems designed in a purely analytical modeling environment are often the ones most difficult to integrate smoothly into the HDL test and verification process. Algorithmic models are by nature floating-point models. The discrete-time behavior and fixed-point math used by most DSP-based processors and custom ASICs often require tedious analysis of simulation results and extensive postprocessing of vectors to determine if the physical model meets the performance requirements established by the algorithmic model.

The third level of system engineering, design in an integrated system design environment, is intended to give the system engineer the same level of automation the design engineer has with HDL-based simulators. Engineers working on communication systems currently use three major system design environments. Of those, we most often use Simulink from Mathworks, but other tools offer valuable features (see "System Tools").

Simulink is a comparatively inexpensive interactive system environment for modeling, analyzing, and simulating a wide range of dynamic systems--including digital, analog, mixed-signal, and event-driven components. Tightly coupled to Mathworks' Matlab, the tool also provides an extensive set of analytical tools for system-level design and implementation of DSP-based architectures. Users can also target system-level architectures developed in Simulink to a C compiler to generate assembly code, cosimulate them with software, or translate them and simulate them with HDL simulators.

Identifying the details

A typical component developed for modern communication systems reveals a highly complex architecture that might contain both embedded controllers and DSPs as well as 100,000-plus gates that implement custom DSP and high-performance analog functions (see Figure 1; the analog functions aren't shown). Clearly, such system architectures aren't specified enough that engineers can or should start developing device code. Critical performance parameters demand analysis to identify low-level details of the architecture. System engineers must work out thousands of details, ranging from the required spurious free dynamic range of the receiver's A/D converter, to the acceptable level of intermodulation distortion in the FIR filter, to the range of soft decision symbols required by the unique word correlator.

A common mistake made in ASIC development is to begin the low-level development of device code too early. Schedule generation often depends on such tangible design engineering milestones as the completion of specific modules within the device architecture. The pressure to dive in and produce usually results in the slipping of schedules and the scrapping of much of the initial device code because completion of the system engineering process requires architectural modification.

Get an early start

But don't get the impression that the design engineering process shouldn't begin as early as possible. In fact, once the system engineer first establishes the architecture, the design engineer should begin the development of the test and verification environment. This process usually starts with a tool infrastructure plan (TIP). The plan identifies interface issues between the system and HDL design environments--a critical step in avoiding unnecessary levels of abstraction in the verification process. The next step is to identify all interfaces and secondary design elements within the architecture, developing formal interface control documents (ICDs) based on the hierarchy of the design. The ICD's role is to control the movement of data between the system and physical design environments, as it would between a Simulink model and a VHDL representation. Such control is necessary given the fact that the two environments may run on different machines, operate at different speeds, and contain implemented data and control paths at any particular moment in the development cycle.

To facilitate the development of the test environment, it's critical to carefully identify all interfaces and secondary elements. If the system model development and analysis don't happen in a formal system design environment like Simulink, however, the development of the TIP and ICDs can consume a great deal of time. Generally, the less sophisticated the system design environment, the more complex the device design environment--and the more likely that the engineers will miss analyzing one or more critical system parameters. If the team employs a system design environment, the design engineers can usually immediately begin to develop the test and verification process used to validate the physical design within the same environment used to create the system model. Such a parallel design strategy not only accelerates the development of the test environment, but also streamlines iterations when design changes occur.

Another common mistake design engineers make is to develop device code before developing the test code used to validate it. In a typical project, the design engineers spend only about 25 percent of their time writing device code. Verifying that the device code actually works takes up the remaining time. Since the test environment is designed from the top down, whereas module verification of device code is conducted from the bottom up, the physical implementation of the system will very likely change during the normal life of a product. It's much less likely that the process that verifies a specific implementation of the device will change. Therefore the test code (derived from the system model) often contains more IP and a greater investment in time, money, and labor than does the device code. Designers can both save time and produce better code if they wait until after the more stable system-level elements are in place before plunging ahead with the device code.

The verification test code used to validate the example TDMA architecture had to address the full complexity of the system (see Figure 2). Because Simulink is a very open environment, we can design a socketed Verilog test environment to allow a single test bench for complete system simulation. Similarly, because Simulink is a hierarchically based analytical environment that allows both the system block and Verilog modules to employ an identical structure, it can simulate specific low-level modules as far down as three levels within the hierarchy of the device. We also benefit from additional Simulink-based tools: Stateflow converts analytical models into discrete-time control logic models, and the Fixed-Point Blockset converts floating-point analytical models into properly truncated and rounded fixed-point vectors for physical verification.

As a design progresses and models change, we also face the risk of including the wrong changes in the final product. One of the key advantages of an integrated system design environment lies in its ability to regression-test the physical implementation. Figure 2 shows a link between the Simulink model and the Verilog test bench's test result processing module used to generate the outputs. The linkage allows the system-level analysis of multiple variations of the physical implementation before the design engineer decides on the final implementation, reducing the risk of including unwanted variations.

Finally, an integrated system engineering environment reduces risk by simplifying the creation of parameterized system models. Parameterized models allow the engineers to feed the physical parameters and constraints identified during implementation back into the system model for system-level verification. For example, most communication systems rely on demodulators and tracking loops to recover data from complex input waveforms. The dynamic response of a tracking loop is a key performance parameter that's highly sensitive to physical implementation. Loop delays in a purely algorithmic model may not properly reflect the discrete-time nature of the target digital architecture. System models of carrier and symbol tracking loops are thus often parameterized to allow regression testing of the physical implementation in the system environment. Most of the channel models in a system engineering environment can also facilitate testing (see Figure 3).

Shortages of design talent and the mobility of design teams, within companies and between companies, put both design cycle times and IP reuse at risk. One way organizations respond is by using off-the-shelf cores provided by IP suppliers, EDA companies, ASIC vendors, or foundries. Off-the-shelf IP can reduce development time, but system-level models can further reduce development risk and do a better job of preserving the organization's true intellectual property.

Home-cooked cores

IP vendors are proliferating, and some suppliers of EDA tools are rapidly building catalogs of core functions. Usually, they provide a black-box function (that is, a hard core) along with a simulation model in encrypted Verilog or VHDL--thus complicating the process of test and verification in the design environment. In these cases, the customer is typically tied to a specific foundry or implementation process. (Soft cores, which are white-box functions, can be targeted to different foundries and processes.) In addition, the customer often must pay royalties, relicensing fees, or both to continue to use a core. On the other hand, IP vendors may offer integration support.

Cores supplied by ASIC vendors or foundries offer a basic trade-off. On the plus side, they assume the responsibility of the design and ensure that it meets all requirements of its physical implementation. On the minus side, they in effect holds the customer captive, though, by supplying hard cores tuned to its process. Likewise, they usually provide an encrypted simulation model.

System-level models offer most of the advantages--and suffer few of the disadvantages--of obtaining outside IP. They capture the essential parameters of a proprietary design, which is where the primary intellectual property investment occurs. Design teams can rapidly develop, evaluate, and verify specific, custom core implementations based on those parameters. Such an approach offers three distinct advantages:

• The core function can be heavily optimized to satisfy specific project requirements: Optimization normally results in a more efficient silicon implementation and operation. For example, implementation of a 1/2-rate Viterbi core used in a forward error correction network running at 60 Msymbols/s requires 18,000 gates; the same core running at 208 ksymbols/s needs only 2,000 gates. Developing a custom core also allows a customer to personalize the function of a device to differentiate its products from those of its competitors. After all, anyone can purchase the black-box cores provided by foundries and EDA suppliers.

• The IP contained in a custom core belongs to the customer: As products based on the initial design continue through a normal life cycle, the customer can continue to use and modify the system-level design, producing new variants of the IP to meet changing performance requirements.

• System models as well as design models generally exist only to support test and verification: Ownership of IP depends not so much on the device code developed in the design environment as on the system model developed in the system design environment and also on the process used to validate the physical implementation of the device. An expanded system design environment cements IP ownership by locating it earlier in the design flow.

Clearly, IP and its reuse are of critical concern in all projects. As EDA tool suppliers expand the scope of system design environments and further automate the design engineering activities, those environments will play an increasingly dominant role in the development and protection of IP.

Bob Schutz is the president of Silicon Arts, Inc., a San Diego-based consulting organization that specializes in the development of intellectual property. He has more than 20 years' experience in the design and management of digital systems implemented in FPGAs, gate arrays, and standard cells.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  March 1999