System Design

A Case Study in Interface Verification

Symbios Logic uses top-down timing design to ensure proper interfaces in a multi-time-domain ASIC.

by Kurt Kastein and Mike McClure

Because the vast majority of ASIC errors occur at the interfaces between hardware blocks, and most system errors occur at the interfaces between hardware and software, interface verification becomes critical as entire systems are put into a single chip. The problem is that it takes billions of cycles to fully verify this much functionality when using logic simulation. Therefore, alternative strategies such as modeling at higher levels of abstraction and virtual prototyping must be employed to get around the verification bottleneck. Any valid approach to an integrated systems methodology must bridge the gap between hardware and software simulation environments, and create a bi-directional information flow that benefits the design teams on both sides. ¹

The risk of early errors, especially interface errors that can ripple out to all areas of a system, is one chance we take when using system-level design methodologies. Interface verification at the earliest and highest levels of the process can prevent many such mistakes.

Using the information gathered during interface verification, it's possible to dynamically evaluate actual system performance and compare it with original system and interface specifications, making midcourse design changes when obstacles are encountered.

Furthermore, the standardized interface descriptions that result from verification produce other downstream benefits. They are an easy way for design team members to share information, they are referred to many times during various implementation stages, and they're a necessary part of the final functional specification. A rigorous specification becomes the kind of valuable intellectual property essential for later design reuse.

The disk-controller project At Symbios Logic Inc. (Fort Collins, CO), our design engineers used interface verification in the design of our proprietary high-speed disk-controller ASIC. The project posed numerous technical, communications, and business challenges for the design team. The ASIC had to communicate with a high-speed serial interface and high-speed synchronous dynamic random-access memory (SDRAM) while operating in two distinct time domains. Three design teams at separate locations were involved in designing the ASIC's seven modules, as well as the SDRAM interface.

At the project's onset, we knew that interface analysis and verification was the best way to go. Using it, we could describe the disk controller at a high level of abstraction, giving us a best- and worst-case theoretical benchmark against which to develop the system's architecture at the functional level. Our first step was to create the ASIC's high-level architectural definition, from which an interface specification would be derived (see Figure 1). Once this was completed, we began the design-implementation phase, which included detailed system-timing assessments. To capture the initial high-level waveform and timing information, we used TimingDesigner, an interactive timing-diagram editor with a dynamic timing spreadsheet from Chronology .com/quickbench/isdpromo.html&lf=isd-sendtolog"> Chronology Corp. (Redmond, WA).

The design team created a block diagram of the ASIC's modules that included all the important control and datapath signals. This allowed us to determine at a high level of abstraction how each module would communicate via the identified control and datapath signals. Here, we used TimingDesigner to graphically specify the waveforms and descriptions of how the signals would theoretically perform at the functional (behavioral) level between modules (see Figure 2).

Figure 1. Block diagram of the ASIC disk controller, SDRAM, and associated circuitry shows the different time domains.

At this stage, detailed timing information was not particularly relevant. Instead, we worked with high-level timing diagrams showing interface functions that we graphically pasted into the interface specification. Thus, the three teams all had access to a solid description of what the signals were, along with an associated waveform describing the signals' characteristics. An example of this is the way we defined how control signals should respond to each other and how data should pass from module to module.

Figure 2. Diagram window. Waveforms and signal descriptions at the functional-design level show the timing relative to the system clock.

When we reached the point where we began to determine what form the ASIC's interface to the external SDRAM should take, timing was critical, and our specification needed to be extremely detailed. To that end, we approached communication requirements between the ASIC and the SDRAM at the functional level and then added detailed timing information about the SDRAM's requirements after further analysis. Consequently, the design team ended up with a better idea of whether our intended architectural approach was viable.

The Symbios developers on this project could not imagine creating a design without assessing interface timing in a formal specification--one in which we could reference our thinking to what was happening at the module (top) level. We were concerned about this point because the design was not fully synchronous--not all the interface signals between modules were derived from registers (flip-flops) that would keep marching in lock step.

In our ASIC, signals originating in the real world were part of the mix and, therefore, complicated the timing issue. We couldn't guarantee that outside signals would flow in a fully synchronous way. This was where we made TimingDesigner work hardest, requiring it to analyze multiple permutations of signal timing to optimize communication efficiency and minimize confusion.

Deep timing issues explored Back at the functional level, a key technical challenge in the design centered around assessing timing behavior on bi-directional data signals flowing between the disk-controller ASIC and the SDRAM. The ASIC would operate at a clock speed of 50 MHz, while the SDRAM and its control circuitry would run at 83 MHz. Because multiple design iterations were required to optimize signal synchronization between these two timing domains, synchronization and control functions had to be well-documented and readily available for analysis.

At this point, we encountered a two-pronged challenge while gathering detailed timing information on the design. Not only did communication between the ASIC and SDRAM occur between the two time domains, but also involved were inherent delays in the signal path between the ASIC and SDRAM, induced by the physical circuit traces and interconnect pads for the physical devices. Because of this, a less than 100 percent synchronous signal path was part of the timing equation. We could not have fully understood the cumulative impacts of cross-domain timing and physical delays on optimal signal behavior without a detailed timing diagram for reference.

Figure 3. Detailed timing in the diagram window. A detailed view of system timing shows signal waveforms with associated minimum and maximum timing tolerances.

In our design, the SDRAM ran from an ASIC-generated clock. The ASIC also provided the SDRAM with address and data signals that had to be valid within a particular time slot before the next clock edge. Because variations in device performance are inevitable within any batch of silicon that comes from a foundry, we needed to evaluate and understand system-interface timing under best- and worst-case timing conditions, based on that batch of devices. With best-case devices, ASICs in our case, address and data could be sent to the SDRAM with time to spare. If another ASIC in the batch had operated at the other end of the timing-performance boundary, we might have encountered a problem.

There was also a hold-time specification that had to be met for address and data going to the SDRAM. The best-case ASIC met the setup-time requirement with plenty of margin, but the hold time became less certain. By using TimingDesigner, we determined that with a worst-case ASIC, the setup time might not have much margin, but hold time would be adequate.

In any event, our ASIC design would still perform properly under best- or worst-case conditions. The results of our analyses showed that we would have no yield loss for this one specification across the spread of device parameters. It would have been hard to visualize, let alone document, all the possible variations on interface timing and overall system performance stemming from varying setup and hold times. For design teams working with multiple ASICs and even larger systems, issues such as signal delays, setup, and hold further compound design complexity. Collecting detailed interface-timing information for those systems is imperative and impossible without a tool such as TimingDesigner.

To streamline the process of collecting and documenting this information, TimingDesigner allowed our design team to dynamically visualize how well signals were synchronized between the design's functional blocks and how control functions worked between them under best- and worst-case timing conditions. TimingDesigner also freed the design team from using a pencil-and-paper approach to waveform documentation (see Figure 3).

System operational characteristics In operation, the disk controller's high-speed data from the serializer/de-serializer, clocked at 50 MHz, had to pass into the Write FIFO (WFIFO) buffer, then synchronize to the SDRAM controller/arbiter running at 83 MHz. The opposite occurred as data was read back from SDRAM to the serializer/de-serializer through the Read FIFO (RFIFO). Because signals were crossing time domains at these points, timing accuracy was critical. On the SDRAM side running at 83 MHz, signal paths connected the controller to the SDRAM itself, all within the same time domain.

By describing the behavior of the inputs and outputs on the serializer/de-serializer and the SDRAM controller/arbiter, and knowing the signals had to be synchronized, we developed an interface specification showing the waveforms, and in particular, how deep the data pipeline (buffering) had to be between the modules. The pipeline's depth was defined by how long it took the controller/arbiter to synchronize signals from the serializer/de-serializer and pass them to the SDRAM through the buffers. Here, it was important to track how communications occurred during each clock cycle.

As we learned more about the behavioral subtleties of the disk controller, we had to jockey signal edges to reflect revised delay and transition times. Having a "what-if" capability simplified this process because team members could interactively drag waveforms around on screen and watch the tool dynamically update the timing display on all interdependent waveforms. The revised waveforms could then be used as references for revisions to the design's Verilog code. We also saved the time we would have spent revising documentation.

In contentious situations, the ability to show a fellow engineer the timing diagrams that prove you and your circuit need more time can be invaluable. A graphical representation helps present the case logically and convincingly.

Outcomes Our design team moved from the functional-specification stage to implementation in about half the time it would have taken using conventional specification approaches. By interactively performing due diligence on the design from the top down, we relieved several deadline pressures. With easy access to up-to-date timing and interface specifications, we avoided having to revamp an incomplete product specification far downstream in the design process, where corrections are more expensive and painful. Having useful documentation available quickly for test personnel and customers was a beneficial byproduct. And we could easily put timing diagrams that accurately represented system behavior into the functional-specification document.

Now that we've successfully completed this project, our design team has gained a wealth of information for reuse on subsequent projects. If a new high-speed disk-controller project comes along that uses faster clocks, we'll be able to quickly analyze its high-level and intermodule operating characteristics. We can load the new specifications into TimingDesigner and get a dynamic assessment of system operation for analysis almost immediately, without having to create a new functional specification from the ground up.

Reference

1. Rita Glover, "EDA Vendors Advance Toward System-Level Design," Electronic Design (78) July 8, 1996.

Kurt Kastein is a hardware-design engineer at Symbios Logic (Fort Collins, CO). Mike McClure is vice president of marketing at Chronology .com/quickbench/isdpromo.html&lf=isd-sendtolog"> Chronology Corp. (Redmond, WA).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

integrated system design  May 1997