Design Tools

Changing design methodologies can be a frightening experience. We found that out while designing a small but critical chip for the next generation of our ATM Lightring when we decided to adopt a methodology that is more suited to design reuse.

To make the design of the chip, called the Blink, reusable and technology-independent, we had to use an HDL. We had a short time-to-market window, and our review team was experienced only in schematic representations. We needed a tool that would perform design entry, checking, and verification in a format familiar to our engineers.

We chose Summit Design's Visual HDL to help us design the Blink. It provided us with the benefits of VHDL, such as technology-independent design entry and easy synthesis, and the design documents were in a familiar style. Most importantly, we can now migrate the design between vendors and develop new versions, such as multilink chips, using either a graphical representation of the design or VHDL code.

Background

Developed by the Broadnet division of Ascom, a Swiss-based telecommunications equipment company that employs about 12,000 people, ATM Lightring is a 1.25-Gbit/s dual optical-fiber ring that can carry a variety of ATM and non-ATM services and is aimed at private telecom and Internet service providers. The high bandwidth and flexible add-drop functionality match up with private telecom requirements and reduce leased-line charges. After initial success, it was decided that the ring would be enhanced by doubling its capacity to 2.5 Gbits/s and developing a medium-throughput ATM switch. The switch could be used for local switching at each node or as a common ATM switch in a hub arrangement fed by the ring.

We chose a throughput of 10 Gbits/s for the ATM switch. This throughput was suitable for the market, technically achievable, and reasonably cost-effective. In addition, high reliability was important, even for private-sector customers.

The switching functionality would fit on a pair of cards (making it reliable with a one-hot, one-standby arrangement) and each card could be given a 10-Gbit/s throughput if the architecture used 16 bidirectional 622-Mbit/s ports. We could place a few line interfaces in the same shelf, but because we didn't expect the full throughput to be used by those line interfaces alone, we needed to be able to add expansion shelves.

Industry-standard UTOPIA ports (defined by the ATM Forum for standardizing the interconnect between ATM components) would allow commercial components to be connected to the switch. This connection is easy to make for the interfaces held in the switch shelf, but difficult to make cost-effectively for the expansion shelves. The problem is that UTOPIA interfaces for 622-Mbit/s links need 42 TTL-level signals and are limited to a range of only about 1.5 meters. Multipair cable, the usual first choice, is unsuitable because of bulkiness, crosstalk, end-to-end ground differences, and noise emissions.

Using a serial link could have solved those problems, but it would have been expensive. A high-quality 622-Mbit/s link can be made using standard, commercial OC12 physical-layer (PHY) devices. Currently, however, these are suitable only for optical links using lasers and run about $2,000 per bidirectional link. They also demand additional resources for link monitoring and don't support flow control between the shelves. Using Fibre Channel components is cheaper but requires considerable glue logic, which is messy and nonstandard.

In our ATM switching system (see Figure 1), 16 expansion shelves are needed to provide enough space for 300 E3 interfaces, which equal 10 Gbits/s. Each shelf would gather 622 Mbits/s of traffic and pass it to the switching shelf over a protected bidirectional link. The "standard" OC12 links make a considerable contribution to the overall cost of the system (16 x 2 x $2,000 = $64,000). A cheaper alternative had to be found.

Our solution, the Blink chip, allows the UTOPIA ports of standard components to be passed across low-cost, readily available copper cable, retaining the 622-Mbit/s data rate and the flow control features and solving the problems of cost, bus width, noise emission, crosstalk, and ground potential difference. Long links are not needed--link lengths of up to 10 meters are sufficient for connecting two shelves at 622 Mbits/s. However, adding suitable, cost-effective link monitoring is crucial to building equipment with a sufficiently high availability figure (broken links need to be detected so that standby links and switch planes can be brought into service).

Figure 1	ATM switching system
To provide 10 Gbits/s, the ATM switching system needs 16 external shelves, each costing $4,000, to interconnect to the switching shelf.

Connecting two Blinks--one mounted in the expansion shelf, the other in the switching shelf--using two four-pair UTP-5 cables forms a 622-Mbit/s link. The cost is roughly $150 per bidirectional link. But the chip had to be defined, specified, prototyped, and proven within 18 months, using only one engineer.

Out with the old

In previous designs, we had based our requirements analysis phase on the structured analysis/structured design (SA/SD) methodology and used straightforward gate-level schematic entry for our design capture phase. This approach worked well for designing five ASICs that ranged from 30,000 to over 100,000 gates. It was cost-effective in terms of design time and design quality, and it integrated reasonably well with our documentation. However, this approach made it difficult to migrate the design to a new vendor, and did not provide support for core design or even design reuse.

Consequently, we decided to follow the rest of the industry and use an HDL for the Blink. Another department at Ascom had been using VHDL, so it seemed a logical choice. Soon, though, it became painfully apparent that there is a world of difference between gate-level design and HDL design. After initial frustrations, we gave up on the idea of direct code entry and started looking for an easier method.

To allow for design reusability, we had to modify the old design flow. The two main stages of the old design flow were the analysis and definition phase and the implementation, verification, and sign-off phase. The main stages in our new design flow are analysis, design, and building (implementation) (see Figure 2).

For the analysis phase, we used the SA/SD methodology and Teamwork from Cadre Technologies. There was no reason to stop using this methodology, since this phase was always technology-independent and reusable. The design phase, however--originally direct, gate-level design entry and verification using a schematic editor and simulator--depended on the process technology and was difficult to reuse. An HDL was the likely design methodology choice, because it solved the reusability problem; however, before we could make a final decision, we needed more information about the chip to predict potential design problems.

Our initial analysis showed that we could best meet the link with a continuous cell flow, adding additional bits to each cell to link overhead information for flow control and alarm reporting. But because we had only 18 months for the entire process, respins were strongly discouraged. Many questions arose: How could the review team review the chip design when those engineers were only experienced in schematic representations? Would using an HDL remove the crucial safety net provided by reviews? Could the planned flow control mechanism work despite the expected latency, and was the hardware-software interaction acceptable? How could the chip's FIFO design be proven? Could a sufficiently high-speed scheme be developed, or would an HDL prevent a sufficiently fast design?

However, it was unclear how much time we would need to learn the HDL and the associated synthesis requirements, and the review team needed to be up to speed quickly. Indeed, it takes a long time to learn VHDL well enough to understand other people's designs or to write worthwhile code. Also, merely working out the structures of designs presented problems. Furthermore, the style of the code had to be tailored for the synthesizer being used, which prevented the code from being technology-independent. Because of those drawbacks, we decided to use Visual HDL.

Visual HDL easily solved the first of the problems we had anticipated. We could use an HDL for design capture and still provide for meaningful reviews. The tool allowed us to perform design entry by capturing the structure in terms of hierarchical block diagrams and the functional operation in terms of lower-level schematics. The schematics weren't at the gate level but could be in any of a variety of representations--flow charts, state machines, truth tables, or VHDL code (see Figure 3).

As noted, in addition to the VHDL benefits of technology-independent design entry and synthesis--in fact, Visual HDL generates the VHDL code automatically to suit the synthesizer used--the tool provides readable design documents as well. Indeed, during the design, reviews were held regularly and everyone was happy to have documents in a familiar style. We also used Visual HDL's built-in simulator for verification. When the design was complete and verified, we performed synthesis using Synopsys Design Compiler.

Our second problem concerned the high-level operation of the flow control mechanism and the hardware/software split, which should be solved before detailed design work begins with a behavioral modeler. The one we evaluated, however, required a lot of design entry that could not be carried forward to the implementation phase. Since we would have had to enter the design twice, we relied on brain power to "prove" the worthiness of the mechanisms and decided to wait until the implementation phase for actual confirmation. Waiting until implementation was a reasonable choice for this design, since it is relatively straightforward in its operation. Something more structured would be useful in the future, however.

Proving the FIFOs was a challenge because data had to be passed from one clock domain to another. The chip performs cell rate adaptation at each end of the link, and FIFOs are needed to hold cells prior to transmission. The two sides of the FIFOs operate in different clock domains. Although design manuals emphasize the importance of synchronous design practices, such practices weren't applicable to our design.

The risk of metastability in the target domain can be accommodated using anti-metastability buffers (the usual method is a two-stage shift register, called a synchronizer), but the buffers have to be analyzed at both the gate level and the system level to prove that the mechanism works as required. The system has to be designed to cope with the eccentricities of the gate-level operation, which is nondeterministic because of the possibility of metastability.

Figure 2	Design flow
In the new design flow, the requirements for design tools change throughout the design cycle. The requirements analysis phase is unchanged from the previous design flow, but the capture, verification, and synthesis phases require a different methodology. (Iteration cycles aren't shown.)

The gate-level operation has three cases: (1) An input toggle is faithfully reproduced on the output with a short delay. (2) An input toggle is faithfully reproduced on the output with a long delay. (3) The chip malfunctions. Case 1 is the easiest to appreciate; it's as though the input signal just suffered a short delay. Case 2 is similar, but the delay is longer, because it takes longer for the target clock to occur. Case 3 occurs when the input signal is not stable long enough for the target clock to capture it correctly. This situation is dangerous and must be prevented.

Figure 3	Multiple entry modes
Visual HDL allows users to choose among HDL code entry or various graphical design entry modes. With the latter, the tool produces Verilog or VHDL for the target synthesizer.

Shaking hands

In general, the relationship between the clocks can vary with the application, and the circuitry that generates the input pulse must sense when the pulse has been correctly captured in the target clock domain. Usually, a handshake mechanism is used to sense the capture. The operation of the gate-level circuitry, therefore, has an impact on the design requirements of the higher-level circuitry. The use of handshaking mechanisms is one example, but the higher-level circuitry must also allow for the variable arrival time of the toggle in the target domain. Such circuitry can be designed easily, but how can it be verified? In the old design flow, any violation of the timing margins of flip-flops would cause the simulator to display its unknown value state, making it difficult to prove the operation of the higher-level circuitry. The new design flow used Visual HDL's built-in simulator, which doesn't check for timing violations. Although that may seem dangerous, in this case it allowed the setup of special test situations to show that the FIFO handshaking mechanisms were operating correctly.

Visual HDL solved all the problems related to the actual implementation of the chip. We also proved the operation of the end-to-end flow control mechanism using the tool, but we had to wait until a complete link could be put together in a test bench. For more complex designs or protocols, waiting until then to verify the flow control mechanism would be too far down the design path for comfort. Any necessary modifications would incur heavy time penalties. Visual HDL is not at fault; designers simply lack design tools suited to this type of problem.

Our final hurdle was making sure that the new design flow would allow a high-speed circuit for the physical layer. The nominal toggle frequency of a flip-flop in the target technology was 350 MHz, but we needed a small part of the receiver on the chip to operate at 400 MHz. We wondered if the combination of Visual HDL, VHDL, and Design Compiler could generate a circuit with the desired performance. Otherwise, we would need to prepare for some manual design, which may not work with another vendor's process. Initially, it was impossible to get Design Compiler to generate a fast enough circuit on its own. We were able to help it along by designing a dedicated circuit in gates and reconstructing it in Visual HDL, which then generated the VHDL code for Design Compiler to create a circuit with the desired performance. Further manual effort was required in the layout, but the VHDL description of the design requirements was sound.

By using Visual HDL, we saved a great deal of time. Running it on my laptop, I could even work on the train, thereby gaining another hour each day. Also, the various small teams involved in the switch development could easily understand the design using Visual HDL's graphical representations. The improved communication saved the group a lot of time in developing the switch. Graphical entry is certainly a lot more intuitive than code and is thus easier to learn and apply. Also, it makes for much better documentation. Of course, the more experienced VHDL writers in the other ASIC design group disagreed with the need for graphical representations, because they can enter code more quickly by hand. They declined to say, however, how their customers feel when presented with so many lines of code.

As an example of electronic-system-level (ESL) design tools, Visual HDL is not perfect. The PC version crashed fairly often, and there are several minor areas where it can be improved. Generally speaking, however, the tool performed better than we expected. Summit is responsive to problems, and it provides regular upgrades. In fact, Visual HDL has evolved considerably since we began our project and now offers many more useful features.

David Tonks is a project manager for ATM line interfaces at Ascom Broadnet in Bern, Switzerland. In this position, he has been responsible for the design and development of several line interfaces, using commercial components or, frequently, designing his own chips. Previously, he was a design engineer for seven years at GPT, England, where he worked on one of the first SDH add-drop multiplexers, among other projects.

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

integrated system design  March 1998