Wring Out Better, Faster Results Through System-Level Design

March 17, 2003
Starting with block-level design tools, iteratively refine whole systems down to their low-level implementation details.

Full article begins on Page 2

Daunting time-to-market pressures coupled with design complexity caused by converging voice, data, and multimedia technologies leave companies facing a host of serious challenges. Unfortunately, because the current design-verification process occurs late in the design cycle, there's a high risk of design failure and the resultant time-to-market delays. Testing the whole system's behavior rarely happens before investing in costly hardware or embedded software design.

An effective way to deal with this problem is to perform high-level design and testing early in the development process using system-level design techniques. After building a prototype, engineers can use advanced test-and-measurement tools to verify that the product meets the intended design specifications. This article outlines some of the more significant benefits of a system-level design approach, in the context of an ADSL modem design. By starting with block-level design tools, whole systems can be iteratively refined down to their low-level implementation details.

System-Level Design At this level, systematic testing of an entire system's behavior is performed early in the design process. It involves architectural design and behavioral simulation.
System-Level Design Tools Languages, such as C/C++ and HDLs, and block diagrams are among the proposed tools for system-level design.
Block-Diagram Tools These tools make it possible to construct a diagram of predefined blocks that represent the system architecture. They usually come with libraries of prebuilt and verified system components.
ADSL Example In this article, an asymmetric-digital-subscriber-line (ADSL) modem design example helps illustrate using a block-diagram tool to model a system.
Testing & Measuring ADSL2 Design reuse is a critical consideration when it comes to evolving standards, such as with ADSL2.

Full article begins on Page 2

Starting with block-level design tools, iteratively refine whole systems down to their low-level implementation details. * Companies developing systems, semiconductors, and test-and-measurement equipment for next-generation communications applications—such as digital subscriber lines (DSLs), cable modems, voice over networks, and LANs/WANs—face a number of challenges. With daunting time-to-market pressures, victory will go to the swift. To make matters worse, designs also are becoming more complex, particularly due to the convergence of voice, data, and multimedia technologies, as well as the need to operate at higher speeds.

Unfortunately, the current design-verification process is hampering attempts to address these challenges. Because design verification occurs late in the design process, there's a high risk of design failure and the resulting time-to-market delays. Testing the whole system's behavior rarely happens before investment in costly hardware or embedded-software design.

An effective way to deal with this problem is to perform high-level design and testing early in the development process using system-level design techniques. After building a prototype, engineers can use advanced test-and-measurement tools to verify that the product meets the intended design specifications.

DESIGN PROCESS PROBLEMS Missed product delivery deadlines, design failures, and long verification time often lead to disappointing financial results or even business failure. A number of factors can cause these delays.

First, while designs can only be validated with adequate testing, verification starts at the Spice level for analog components, the hardware-description-language (HDL) level for digital hardware, and the C or assembly-code level for embedded software. Often, there's no systematic testing of the behavior of the whole system or subsystems prior to such work. Therefore, engineering resources must be committed to designing the components of a system not yet validated. This lack of testing is analogous to starting construction on a bridge before a civil engineer proves that it will stand up! It has a high risk of falling down and expensive repercussions.

From a logical standpoint, there's no point in designing the structure of a subsystem or component if its behavior is incorrect, or if it causes failures in another part of the system. Typically, high-level design of the algorithms is carried out in C. But this only covers data-processing characteristics, usually without timing analysis or architecture testing.

Second, frequently there's no clear system specification and architectural description that all team members can refer to and share. The system architecture might be drawn on a white board or captured as part of a written document. Sometimes it's just a concept in the heads of the team members. When employees leave the organization, they may take this vital information with them. When new staff arrives, a steep learning curve is encountered and misunderstandings often occur. Also, the lack of a clear architectural description can mean poor communication between groups and members.

SYSTEM-LEVEL DESIGN By systematically testing the behavior of the whole system early in the design process, system-level design addresses design-process problems. High-level testing enables engineers to find design flaws earlier and less expensively. Such flaws wouldn't have surfaced until later, during more costly circuit, register transfer level (RTL), or embedded-software design. In addition, system-level design involves creating a clear architectural description of the system, which greatly improves interteam communication and training.

System-level design involves both architectural design and behavioral simulation. The process starts with an initial concept and iteratively refines in a top-down manner, testing at each stage. This includes simulating algorithmic data-processing and timing characteristics of the system and subsystems. Refinement stops when engineers need to specify implementation details that are more appropriately modeled at a lower level with a different tool. For digital hardware design, the system-level model can extend down to the fixed-point integer, or register level. Further refinement requires structural RTL descriptions of the arithmetic, which are better modeled with HDL tools. For analog design, when circuit-level characteristics need to be added, behavioral analog design stops and Spice-level design begins.

At this stage of development, the system design now becomes a reference for comparison against lower-level, higher-fidelity designs. It also generates test vectors and stimuli for test benches. Unfortunately, no standard exists for the scope of system-level design. In this article, it's defined as encompassing the design of the hardware and software of a whole communications link (like a cable modem) or semiconductor (such as an Ethernet PHY ASIC or even a data converter).

By simulating the behavior along with the implementation details, engineers will understand what the system does and how it does it. This allows for much faster initial abstract design. Compared to traditional hardware and embedded-software design, system-level design is an order of magnitude faster and less expensive. With system-level design, making a revision and testing an entire new system architecture takes only minutes, compared to days at RTL or Spice levels, or even weeks and months for a board or ASIC revision. Investing a few thousand dollars in system-level design can save hundreds of thousands—or even millions—of dollars in later design stages. Notwithstanding, bringing a product to market earlier increases revenue.

SYSTEM-LEVEL DESIGN TOOLS A number of tools have been proposed for system-level design, including languages like C/C++, HDLs, and block diagrams. These design and simulation tools use different methods of design capture and execution. Therefore, each one is good at modeling different characteristics. To evaluate the best tool for system-level design, designers should look at the requirements of the tasks involved.

During system-level design, engineers must understand the whole system's performance at a high level to see if it meets the required specifications. To do this, they need to specify and evaluate different candidate architectures made up from collections of interconnected components or subsystems. With system complexity on the rise, engineers must also be able to design in a hierarchical fashion. This will enable the system to be modularized into multiple levels of abstraction.

A real subsystem's components can be analog or digital hardware, DSP software or control logic, and protocol software. Therefore, engineers must be able to model the continuous-time, discrete-time, and event-driven signals processed by these subsystems. Additionally, they need to model the high-level behavior of the subsystems and components, without giving undue consideration to their implementation.

A typical system will include digital-signal-processing (DSP) and communication algorithms, such as filters, correlators, modulators, analog-to-digital converters (ADCs), phase-locked loops (PLLs), and amplifiers. Using a design tool that provides easy access to libraries of such components greatly reduces development time. The implementation will include analog-valued, plus fixed-point and binary-valued digital signals. Floating-point arithmetic is necessary to model the analog signals and is very useful for modeling the ideal behavior of an operation that will ultimately be fixed-point.

Finally, to test the performance of a complex system, designers require the ability to evaluate many possible scenarios and to send many data points through the system. This takes fast simulation capabilities.

LANGUAGES C is sometimes used for limited system-level design, but it has a number of deficiencies. For example, it only models a sequential instruction flow. Therefore, system architecture is obscured and can't be visualized. This prevents reliable communication of the design specification between team members. Moreover, there's no system timing information, so it's very difficult to model multirate and analog/mixed-signal systems.

The low-level nature of C, which focuses on sample-level rather than block-level operations, gives a high degree of control. However, this comes at the expense of slow development time, error-prone code (many studies have analyzed the average number of bugs per line of C code), and difficulty in maintaining large systems.

HDLs differ from C by providing syntax to specify structure or concurrency, which is essential in hardware design. Yet by focusing on bit-level operations, HDLs are at an even lower level than C. As a result, they can't easily describe whole-system characteristics.

While it's possible to model systems with low-level languages, these tools aren't intended for this purpose. Tools for system-level design should provide an easy way to capture the system's architecture, enable rapid design development, and supply the right level of abstraction at the start of the design process—while allowing for the later inclusion of detailed designs as they're developed.

BLOCK-DIAGRAM TOOLS By definition, block-diagram tools make it possible to construct a diagram consisting of predefined blocks, which represents the system architecture. The block states and signals are propagated through time, and the simulation engine implicitly manages them. Some can also model continuous-time, DSP, and event-driven processing. These tools match the way that engineers use block diagrams to describe systems. Nearly all telecommunications-standard documents employ block diagrams to describe the system architecture. Block-diagram tools usually come with libraries of prebuilt and verified system components. Some tools are hierarchical, permitting a top-down design methodology. Starting at a high-level concept, design is iteratively refined down to low-level implementation details.

Visualization of the architecture helps with interteam communications and reduces ambiguous specifications. That makes it easy to partition a system and allocate it to different teams. This visual model, containing additional architectural information, supplies a perfect executable specification for these design teams.

Design refinement stops, as mentioned before, at a level of detail where a lower-level tool would be more appropriate. Engineers can then use the system model as a validated design, generating test vectors for software and hardware design verification.

By having a finite set of predefined blocks, block-diagram tools can suffer from limited control of processing operations. Using C to create custom blocks containing proprietary intellectual property (IP) remedies this problem. Here, C is an appropriate tool. It allows the defining of sample-level processing operations inside a block.

ADSL EXAMPLE An asymmetric-digital-subscriber-line (ADSL) modem design example helps illustrate how to use a block-diagram tool to model a system. ADSL is a popular method of supplying high-speed Internet access to residences via the copper wires in the existing telephone local loop. Figure 1 shows the description of the ADSL transceiver unit in the central office (ATU-C), taken from the International Telecommunications Union (ITU) specification G.992.1. It illustrates how block diagrams are typically used to describe and specify all systems at a high level.

By using a block-diagram tool that provides libraries of prebuilt blocks for all common DSP or communications components, it's easy to quickly replicate the behavior of the standard. Simply connecting the required blocks together into the correct architecture and setting their parameter values to those specified accomplishes this. Figure 2 shows one such example that uses Simulink. Note the possibility of adding a data source, channel model, and bit-error-rate (BER) meters.

As with most communication-system specifications, the ADSL specification clearly defines the transmitter components. This ensures interoperability between equipment produced by different manufacturers. The block diagram from the ADSL specification of Figure 1 is mirrored in the transmitter portion of the system-level design shown in Figure 2. The receiver design is left open, providing an opportunity for individual equipment manufacturers to introduce their own IP in an effort to gain a competitive advantage.

Using a hierarchical block diagram tool, each block can itself be a subsystem, comprising many other subsystems or blocks. Figure 3 depicts the subsystem inside the DMT block. The behavior of other parts of the system not shown here can also be modeled. These include echo cancellation, equalization, initialization, and synchronization, which can be very difficult to model in C because the language provides no explicit timing information. Even link-layer protocols can be modeled with graphical finite-state machines.

Once the model is constructed, it can be simulated either interactively (looking at signal values or constellations as the simulation runs) or in batches using a script to perform tests, including BER measurements. Such tests can sweep a parameter through a range of values, running a new simulation each time.

Such simulation tests demonstrate whether or not the design will meet the required system specification. If the design doesn't meet the required specification, a new architecture of different parameter values can be quickly selected and reevaluated. Once the design meets its specification, engineers can further optimize it in the same way, trying many different implementations and reevaluating them in minutes.

Design continues in a top-down manner, refining each subsystem with more fidelity and testing the design after each iteration. Starting with floating-point arithmetic allows fast design, because no consideration is given to word length. Once the floating-point design is validated, fixed-point arithmetic can be employed for digital operations.

The complete design flow, starting with system-level design, is shown in Figure 4. This method reduces the risk involved in system and semiconductor design by testing the behavior before moving forward with costly low-level hardware and embedded software design tasks.

TESTING AND MEASURING ADSL2 As communication techniques and standards evolve, it's important that designs keep pace. Therefore, design reuse becomes a critical consideration. ADSL2, the next-generation ADSL standard, was recently completed and approved by the ITU. The new standard is expected to supersede existing ADSL standards. The standard, named G.992.3 (with a light version called G.992.4), adds new features and is functionality targeted at improving performance and interoperability. Some of the noticeable advantages include significant power savings at the central-office (CO) side modem, improved rate and reach performance, advanced diagnostics capabilities, and standby modes.

To achieve interoperability among the different vendors using the current ADSL standard (G.992.1), the industry went through a long and painful process. Today, equipment for testing, measuring, and developing is commonly used by the entire industry (i.e., service providers, system integrators, and chip-set vendors.) These tools are used for numerous tasks, such as performance analysis and troubleshooting. The vast experience gained during the past few years could be used to develop ADSL2 test and performance-analysis equipment to support critical issues associated with interoperability. In turn, this would reduce costs and speed the deployment of high-quality ADSL services.

To develop performance-analysis and testing tools that will assist ADSL2 modem and chip-set developers (as well as service providers), an end-to-end simulation is necessary. This type of simulation would substitute the transceivers of next-generation ADSL products currently in development. End-to-end simulation of the downstream path includes the ADSL transmitter, loop, and receiver.

The basic ADSL system simulation of Figure 2 can be quickly expanded to provide the following capabilities for ADSL2 development:

  1. Analog front-end (AFE) design
  2. Simulated samples generator
  3. ATU receiver design
  4. Timing-recovery mechanism

First, add an AFE model to the receiver. The AFE model includes the analog filters, amplifier, and ADC. A mixed-signal environment, such as Simulink, allows the addition of these analog components without the extra effort of converting the models to digital equivalents. Adding the AFE model facilitates the generation of simulated samples. These samples are crucial for receiver development and testing. Using simulated samples eliminates the need for a reference ADSL2 modem, loop emulator, and AFE—which may not exist commercially in the early stages of development. In this environment, different scenarios can be simulated (e.g., loop characteristics, noise, and initialization sequences).

ADSL2 adds new initialization signals to provide an increased data rate. An example of a new signal is C-COMB, a wideband multitone symbol containing 16 subcarriers. The subcarrier spacing has been selected to minimize audible interference into the plain-old-telephone-service (POTS) band prior to applying cutbacks that may be required in the presence of an off-hook POTS terminal. The spectrum of the C-COMB signal is plotted in Figure 5.

Using simulation, the new initialization sequences can be added to the transmitter without building a whole new model. Different test loops and crosstalk disturbers can be added according to the standard loop model. A time equalizer and adaptive frequency equalizer can also be added to the receiver block. As components of the system evolve, the design work can evolve in parallel, requiring the update of only the appropriate subsystem and not the entire design.

By starting from an existing design that's easy to understand, development of a new design proceeds in a timely manner. Designers can spend time looking at effects, such as the impact of the initialization sequences on the equalizer coefficients, the effect of the AFE on the receiver filter requirements, or the tuning of the timing-recovery algorithms. Then the simulation can be used as a specification for software and hardware implementation.

The advantages of a system-level design approach are numerous. This article briefly outlined some of the more significant benefits in the context of an ADSL modem design. Low-level design approaches based on C or other low-level design tools will stick around for years, but system-level design is sure to become more prevalent as its benefits are more widely understood.


To join the conversation, and become an exclusive member of Electronic Design, create an account today!