design flow

Historically, we've done ASIC design at Symbol Technologies using VHDL RTL code created with Synopsys 's Design Compiler Expert. Although we're a leader in bar-code­based data management systems, including laser scanners, hand-held computers, and wireless communications networks, the nature of most of our products has required relatively small, low-complexity ASIC designs.

Previously, our ASIC designer simulated a system-level version of the design, partitioned it into block diagrams that best represented the specification, and then sat down to write the VHDL code by hand. After emulating small parts of the VHDL design in an FPGA, the designer would debug, edit, and reiterate the design until it met all functional and performance targets. In all, we employed a rather straightforward approach to ASIC design that adequately fulfilled our requirements.

That all changed the day we decided to design a 2-Mbit/s wireless LAN system. The specification for the design called for integrating into a single ASIC, named Cetus, the media access controller (MAC) and physical layer (PHY) convergence logic of an IEEE 802.11­compliant wireless LAN, along with a substantial amount of the DSP that processes the signal received from the radio (see Figure 1). The fact that a wireless LAN has to work in both the data and RF domains added to the design complexity, even though the final design used only 70, 000 gates and a 20-MHz main clock.

New flow needed

Because of that complexity, our limited resources, and a tight schedule, we saw immediately that we needed an entirely new design flow--one that automated the system-to-gates design to allow our team to complete the DSP and MAC-PHY chip on schedule. We needed to explore architectural trade-offs at the highest level of abstraction possible with the assurance that the resulting conversion into RTL code and then into gates would be accurate, functional the first time, and on schedule for delivery to our customer. With COSSAP and Behavioral Compiler, the DSP blocks worked correctly with our first silicon and we saved a lot of time. Furthermore, by designing at a higher level of abstraction, we were able to achieve accurate gate-level implementations.

We decided on a single-vendor solution from Synopsys to keep vendor support localized and to leverage existing in-house expertise with Design Compiler Expert and VHDL System Simulator. Additionally, since COSSAP and Behavioral Compiler worked seamlessly with each other, the decision seemed extremely appropriate.

More importantly, we wanted to be able to automatically convert from COSSAP code into Behavioral Compiler code and, subsequently, trade off gates versus performance in Behavioral Compiler. To our knowledge, this seamless flow from system-level behavior to gates couldn't be found anywhere else on the market.

Our existing signal processing design flow involved manually translating from system-level simulations into HDL code. We needed a new, more predictable system-to-gates flow that would automatically achieve highly efficient gate-level implementations.

Data com design challenge

The challenges our design team faced were compounded by the unique nature of wireless LAN systems design. Several major blocks within the COSSAP part of the design required special attention, either for partitioning or for resource sharing, to optimize the ASIC's area. We partitioned each block either to optimize the size of the block or to minimize the occurrence of multiple clock rates within a block. The first block in the design--the gain and bias correction circuits--optimizes the accuracy of A/D loading and the quantization size required further on in the signal chain. The output of the block feeds the clear channel assessment block, the clock recovery loop, and the adaptive equalizer block.

We partitioned the adaptive equalizer into three blocks to separate the subsampling blocks from any memory elements. The adaptive equalizer uses seven taps, each of which requires two multipliers: one to calculate the output and one to calculate the tap updates. Using COSSAP and Behavioral Compiler in tandem, we explored resource sharing opportunities that ultimately reduced the number of multipliers to three, saving a substantial amount of ASIC area. This task would have been extremely time-consuming to manage by hand.

The asynchronous nature of wireless data reception also posed a problem. Our team had to find a way to control Behavioral Compiler's input data sampling mechanism through an external control. In normal operation, Behavioral Compiler samples the input on every clock, and with some latency, creates an output. So that Behavioral Compiler would sample the input only once upon request and then stop, we had to apply an externally generated handshake signal.

We determined that the only way to accomplish that was to modify Behavioral Compiler's VHDL code (generated by COSSAP) to provide a handshake loop (see the listing). By modifying the code to add the handshake loop to the main algorithm loop, we limited sampling of the equalizer inputs to the appropriate clock cycle.

Figure 1

Cetus block diagram

Because a wireless LAN must work in both the data and RF domains, the design complexity of integrating the MAC and PHY convergence logic of an IEEE 802.11­compliant wireless LAN, along with a substantial amount of the DSP that processes the signal received from the radio, is much higher than with the normal LAN components. The block implemented with COSSAP and Behavioral Compiler accounts for 40 to 50 percent of the design.

Knowing how the data received from the RF logic operated made it possible for us to generate a handshake signal from a separate block written in RTL code. We had to experiment to get the handshake loop working correctly. After some trial and error, we placed the handshake loop in the correct position in the Behavioral Compiler code relative to the main loop, thus controlling the sampling of inputs to the equalizer block.

Our design flow was still fairly straightforward (see Figure 2), but the key to meeting our schedule was the process of converting the code from COSSAP to Behavioral Compiler and then into gates.

Design flow and verification

Designing the COSSAP portion of the system began with an architecture that had been defined from past experience to provide the desired performance with a minimal gate count and low cost in the radio. Based on previous simulations, we recognized that we would need an adaptive equalizer to meet our desired performance criteria. We set the design criteria for other functions as determined by the modulation and the characteristics of the analog circuitry that fed the A/D converter.

Because we had already performed system-level simulations of the basic architecture, the initial design in COSSAP went right to bit-true implementation using only Behavioral Compiler library components. The trickiest part of the design was getting the asynchronous clock recovery working within COSSAP and Behavioral Compiler. Synopsys 's application engineers helped us understand how to do that. Once we had the clock recovery loop working, each block was developed and tested before we integrated it into the system, then tested again after integration. We performed quantization size simulations on all the critical functions at both the block and system levels.

We ran several iterations of Behavioral Compiler's scheduling routine to keep the gate count within the budgeted limits and to meet the stringent system requirements based on variable bit rates. Scheduling trade-offs included latency, area, propagation delay between clocks, and vendor library. Although the latency for different blocks varied, it was fixed by system requirements for each block and was therefore considered a fixed constraint.

Figure 2	System-to-gates design flow
We decided on a single-vendor solution to simplify vendor support and to leverage in-house expertise with related tools. The new design flow allowed the use of high-level behavioral constructs to verify the gate-level implementation. The key was converting the code from COSSAP to Behavioral Compiler and then into gates.

Our design flow for the DSP blocks of the ASIC included an input in COSSAP. This input was then converted into Behavioral Compiler code by the COSSAP behavioral code generator. After multiple iterations for scheduling of the Behavioral Compiler code, we were able to define a script with the correct cycle timing versus gate count trade-off for each of the DSP blocks.

Iterative process

We also performed several iterations of scheduling to simply view and study the different architectures that Behavioral Compiler generated. Since this was the first project for which we used the tool, we found it very helpful to explore the different possibilities as various constraints were traded off.

The reports that Behavioral Compiler produced were extremely helpful in understanding how resource sharing operates. For example, it was relatively easy for us to look at the number of multipliers in different architectures of the equalizer block generated by Behavioral Compiler from the same COSSAP source. Once we narrowed down the selection to the two best architectures, we ran behavioral and RTL simulations of the entire ASIC and system-level simulations based on Behavioral Compiler and COSSAP and verified the response from the outputs.

This iterative process for simulation was important because the received signal was subject to a jitter of up to 25 percent, and we needed to verify that the final architecture we picked for each block could handle all our requirements. In this sense, the correlation between simulation from COSSAP and the final RT- or gate-level simulation was excellent and boosted our confidence that the Behavioral Compiler code generated by COSSAP would produce working silicon.

The analog receiver posed an entirely different problem. We needed to create a reasonable facsimile of the radio in simulation to test the receiver's performance. To do that, we instantiated two identical entities for our ASIC and verified the design by having one block pass data to the other at the digital level. To simulate the effect of the analog radio, the transmit data was fed back to COSSAP to generate the equivalent receive data as being the output of an 8-bit A/D converter, which allowed us to partially model the effects of the radio.

Final verification

Having completed the design of the system's basic blocks and their successful verification in the simulation, we targeted the system to two Altera Flex 10K FPGAs to test out the implementation to gates. The test provided feedback to fine-tune the design and thus ease the implementation.

Listing

Handshake loop

library IEEE; use IEEE.std_logic_1164.all; use work.COSSAP_PACKAGE_ Synopsys .all; entity equalizer is generic ( SCHEDULE_LENGTH : in INTEGER : =2); port (input_port_names, output_port_names); end equalizer; architecture behavior of equalizer is procedure ( ) is Variable definitions Signal definitions Begin Main : process Begin Reset_loop : loop wait until clock'event and clock = '1'; if (RESET = '1' then exit reset_loop; end if; main_loop : loop handshake_loop : while (handshake = '0') loop wait until clock'event and clock = '1'; exit reset_loop when RESET = '1'; end handshake_loop; (Equations and algorithm reside here) end main_loop; end reset_loop; end process main; end behavior;

We then ran extensive system-level performance simulations to verify all the functions and quantization sizes. Subsequently, we completed the design of the I/O for the non-COSSAP portion of the chip and the configuration registers. After freezing the functional design, we performed behavioral and gate-level simulations using test vectors generated through Behavioral Compiler and COSSAP. The simulations produced some minor adjustments in the final blocks before completion of the COSSAP portion of the design.

We determined the propagation delay of the combinationial logic between clock cycles by carefully choosing the vendors. First, the design was taped out to Chip Express to secure quick prototypes based on its CX2001 library. The constraint on area was less important for prototypes than it was for the final production parts that we secured from S-MOS Systems using Seiko Epson's libraries. We focused on building production parts with the smallest possible die size to keep costs at an absolute minimum.

Results

The streamlined COSSAP­Behavioral Compiler design flow was a major time saver that allowed us to successfully complete our ASIC. The DSP blocks designed using COSSAP and Behavioral Compiler--which generated 50 percent of the ASIC logic--worked correctly with our first silicon. Our success was particularly remarkable, since we were first-time users of the behavioral tools.

Using our old methodology, the project would have taken us at least twice as long to complete. A much smaller design in which we used a competitive tool for the DSP design in a previous project and then converted the design into RTL code by hand took four man-months to complete. If we had used that tool for the Cetus ASIC, it would have taken an additional eight or nine months, and we would never have been able to verify the final gates against the source.

The architectural exploration provided by designing at a higher level of abstraction paid off. Our team found that we were able to implement what we explored architecturally, and timing and area correlated with the actual result to within 10 percent of the predicted values.

We've already begun plans for the next iteration of the wireless LAN system--this time aiming at 10 Mbits/s. We expect that moving down from the 0.6-µm process we used to a 0.5-µm or a 0.35-µm process will pose no great problem. Moreover, the confidence and experience our team gained on this project bodes well for our future success in using COSSAP and Behavioral Compiler.

Sarosh Vesuna is a principal engineer at Symbol Technologies and an active voting member of the IEEE 802.11 committee. He has 15 years' experience in the design of communications and computation products, and in the development of MAC layer protocols for various LANs.

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

integrated system design  April 1998