Cover Story

Every complex chip design brings with it many questions, and a company's first project with a new communications standard only adds to the uncertainty. Building a real-time prototype allowed our design team at Nokia Mobile Phones to remove the uncertainty from the project and build a code-division multiple-access (CDMA) handset. With the prototype, we gained the ability to explore the subtleties of CDMA and refine the performance and features of our ASIC.

Because the CDMA standard (IS-95) was relatively new when the project started, none of us on the design team had experience with it. The San Diego R&D center was also relatively new. We therefore wanted every chance to evaluate the CDMA design and algorithm approaches. Many critical aspects of the design needed to come together in order to "speak the language" of CDMA.

A measurable example of this effort was the ability to acquire and process a base station signal. Testing the algorithms for those functions requires real-time operation. Specifically, the prototype had to run at full speed with its DSP and microcontroller executing actual handset software. In-circuit emulators were connected to both the DSP and the microcontroller for hardware/software coverification in a real-time environment.

Another requirement was to evaluate the design under changing field conditions. Respinning the ASIC every time the field tests necessitated small changes was out of the question. Therefore we had to verify as much of the design as possible using the prototype in the lab before moving into the field.

The prototype relied on FPGA-based emulation for much of the logic, along with bonded-out cores and off-the-shelf chips. The combination was key to testing the handset's complete functionality before ASIC fabrication. However, the design flow required careful planning to accommodate the differences between ASIC and FPGA implementations.

Top-level design flow

We began with a detailed system-level analysis based on the requirements of the CDMA standard specification. We partitioned most of the blocks and algorithms using the Signal Processing Workbench (SPW) tools from Cadence Design Systems' Alta Business Unit. Although this tool suite can extract VHDL syntax from the high-level representations, we decided to retain close control over the design by performing the majority of the VHDL coding manually at the RT level.

To ensure that the VHDL representation matched the SPW functional block representation, we compared the SPW simulation results with the results from Viewlogic's Vantage VHDL simulator. These simulations covered all of the blocks except the RF module and the D/A and A/D converters. By verifying as often as possible that the simulations gave identical results, we were confident that we were on track with translating the algorithms from the SPW environment into the hand-written VHDL code.

The handset's major functional blocks are a forward link (base station to mobile) and reverse link (mobile to base station). The major blocks that we created were the fingers, searcher, Viterbi decoder, combiner, automatic gain control circuit, de-interleaver, DSP and microcontroller interfaces, and transmission path (Figure 1). We developed specifications for each of those blocks and agreed on interface timing between the blocks.

When the VHDL implementations of the blocks were verified to be correct and functionally equivalent to the SPW versions, the design flow diverged in two parallel paths: We synthesized the handset ASIC using Synopsys 's Design Compiler in conjunction with the ASIC library for the chosen foundry, and we synthesized the FPGAs in the prototype using Synopsys 's FPGA Compiler.

Figure 1	CDMA handset blocks
The major blocks of the CDMA handset were specified and developed by the design team.

In the ASIC flow, we performed gate-level simulation using Mentor Graphics' Quicksim II (Figure 2). Additionally, we performed scan insertion, fault grading, and static timing analysis on the gate-level ASIC netlist. RTL simulation was sufficient for the FPGA version of the design, because the performance of the prototype provided the best way to verify that version. Figure 3 shows the overall HDL-to-emulation flow.

Full-speed prototype

We implemented the real-time prototype using the System Explorer MP3 rapid prototyping system from Aptix, along with three additional PCBs. The boards implemented the RF, DSP and microcontroller interface, and CDMA sections of the design (Figure 4). We used the MP3 to implement the portions of the design that were most likely to change--the counter-timer interface (CTI), user interface (UI), accessory interface (AI), RF control, and Advance Mobile Phone Service (AMPS) receiver-transmitter modem.

Aside from the RF section, which was easier to implement on its own board, the extra PCBs were needed to accommodate all the circuitry that would eventually go into the handset ASIC. The use of a PCB for the DSP-microcontroller interface section posed some limitations because of its inflexibility, even though two FPGAs were included for DSP and microcontroller arbitration. The flexibility of the FPGAs didn't simplify changes to the PCB's interconnect, so the board eventually had to be respun.

In contrast, the hallmark of the MP3 prototyping system is the flexibility of its interconnect. The system employs Field Programmable Interconnect Chips (FPICs) to connect any points on the prototyping system's circuit board. User-configurable areas on the board allow the addition of FPGAs. Thus the ASIC logic is mapped onto the FPGAs, and the interconnect is mapped onto the FPICs.

Although an FPIC is not physically configured as a switch matrix, it acts as one. The interconnect paths in the FPIC are made by programming SRAM-based pass gates, which create passive, bidirectional connections for signals of up to 5 V. Pin-to-pin propagation delays are as low as 4 ns.

The FPIC interconnect pattern can be modified in real time. Software provided by Aptix allows users to change the design mapped into the prototyping system by creating opens or pulling signals up or down in the FPIC. Because these modifications don't require a recompilation of the FPIC data, users get instant feedback on the design change. This capability became very valuable for isolating interfacing problems between the FPGAs.

In addition to their fast reprogrammability, the FPICs make it possible to probe all the nets connected through an FPIC. The nets can connect directly to a logic analyzer, and 64 of the FPIC's 1,024 pins can be observed simultaneously. Because we could change the observed set of pins while the system was running in real time, we were able to quickly and interactively select signals to monitor while debugging the design, thereby cutting hours of troubleshooting.

When a member of our team changed either the logic functionality or the interconnect to eliminate a design problem, a new pattern was downloaded to the FPGAs and FPICs. The revised prototype was ready to run in minutes. The programmability speeds prototype setup and allows designers to iterate through many debugging cycles quickly. Because the reprogramming process is quick, the time required to implement a new version of the prototype essentially depends on the synthesis and FPGA place-and-route run times.

Configuring the prototype

The MP3 system allows the use of virtually any type of FPGA. We chose Xilinx's XC4025E FPGAs when the project began because of component stability, the usefulness of the supporting software, and the fact that the engineering staff was familiar with the Xilinx architecture and tool set and its interface with our design flow.

Figure 2	Design verification flow
In Nokia's design verification flow, simulation is performed at the RT and gate levels and the results compared to ensure equivalence between the two design representations.

We used five XC4025Es on the MP3 board. The devices each contain 25,000 logic gates, or 1,024 Configurable Logic Blocks (CLBs). When targeting the FPGAs, we aimed for 50 to 60 percent utilization of the CLB resources as a rule of thumb. This guideline allowed enough room for routing any critical internal nets and for meeting the overall timing requirements.

To meet algorithm partitioning requirements, in some cases we exceeded the rule of thumb, moving up into the range of 85 to 95 percent utilization of CLBs. These cases required close attention to the internal timing results. Once timing was met, we had to weigh the possibility of the FPGA resources growing in size by future logic or algorithm changes. If such growth occurred, we decided that we would then either split the FPGA into two devices or upgrade to a larger available FPGA.

The FPGAs were installed on the MP3 in prepackaged modules offered by Aptix. The modules plugged directly into the user-configurable area of the MP3 board. Each section of the prototype could generate its own clock (master clock source) and supply the clock to the other sections (slave devices), reducing the skew between each section of the prototype as much as possible. This clocking arrangement was necessary because each section was capable of running at different clock rates.

In an effort to give the DSP the fastest connection possible to minimize the number of wait states and avoid routing the DSP address, data, and control lines via the FPIC, the DSP interface was fed into the MP3's built-in high-speed bus. This connection was made using thin coax from the processor board to a small PCB adapter board on the MP3 (needed to translate from coax to a high-density connector), which in turn plugged into the MP3's high-speed bus. To the MP3 environment, this setup looked like an additional FPGA position. The flex cable assembly contained the microcontroller interface (address, data, and read/write strobes), clock enables, chip selects, and such, and included the proper termination to minimize reflections on the DSP interface. The DSP interface was thus distributed on the Aptix MP3, and was then jumpered with a very short ribbon cable to the FPGA module that needed to connect to the DSP. Porting the processor board functionality onto the MP3 was impossible because of the additional hardware (RAM, ROM, connectors, and so on) required to support the DSP's and microcontroller's functions.

The MP3 also provides two built-in FPGA locations associated with its I/O interfacing connections. Those devices were used to interface with the PCB containing the user interface and RF portions of the design.

Despite our careful planning regarding high-speed paths and signal integrity, the skews on some signals became unacceptable. We added pipelining, buffering, and additional grounding to improve signal integrity and meet timing requirements and to enable the prototype to achieve real-time operation despite the use of multiple PCBs and numerous interconnects.

Mapping logic onto FPGAs

A major consideration with any FPGA-based prototype is the challenge of taking logic that is intended for implementation in an ASIC and mapping that logic onto FPGAs. ASICs provide a fine-grained, gate-level architecture, whereas FPGAs provide coarse-grained blocks of configurable logic. Further, because multiple FPGAs are required to accommodate the logic that will ultimately fit on one ASIC, the design must be partitioned for prototyping. We decided to partition and place the prototype manually for maximum speed and efficiency.

ASICs and FPGAs also differ in the clocking and memory resources they offer. ASICs are rich in clock resources. For a portable, battery-powered cellular phone, we used those resources liberally, applying careful power control management of the functional blocks, to reduce ASIC power consumption. There was little concern about power dissipation in the FPGA environment, but the ASIC clock tree structure did need to be reconfigured to fit the FPGA architecture.

Although the typical FPGA architecture has extensive clock-enable resources, it is limited to a certain extent in the number of clocks it can support. For example, the XC4025E supports four primary and four secondary clock trees. The clocking resources of the MP3 were also an issue. Passing clocks through the FPICs is not a good idea, because the delays can vary depending on the path through the FPIC. The MP3 supports only two low-skew clock paths, which are distributed independently of the FPICs.

To match the clock tree structure of the ASIC design with that of the FPGAs and MP3, we had to look very carefully at the required clocks for each of the functional blocks in the design. The need to convert the ASIC clock tree structure into an FPGA clock-enable structure became very apparent. At the same time, to achieve meaningful verification of the design, it was important to keep the ASIC and FPGA VHDL descriptions tightly coupled.

Figure 3	HDL-to-system emulation
The HDL-to-prototype flow splits into parallel paths for the logic mapped into Xilinx's XC4025E FPGAs and the board-level interconnect used to program the Field Programmable Interconnect Chips (FPICs) on Aptix's System Explorer MP3 emulation board.

One of the approaches we took in using the multiple clock-enable structure was to translate the ASIC VHDL code into an FPGA VHDL version. The ASIC VHDL was written with CLOCKnn = '1' AND CLOCKnn' EVENT... notation for all clocked processes. For the FPGA VHDL, we had to insert IF CLOCKnnEnable = '1' THEN... statements as a condition of the clocked process. The clocked process would now receive a fundamental clock (CLOCKMaster) , plus CLOCKnnEnable . With this approach, we kept the ASIC VHDL code intact and maintained strict control over any deviations from the ASIC VHDL representation.

Another approach to supporting the clock enable scheme was a script that reduced the multiple clocks to a fundamental clock (two maximum for the MP3 low-skew clock distribution) and inserted the clock-enable signals. The script was run against the output file from FPGA Compiler (design.sxnf), which connected the fundamental clock and its associated clock enable signals to all VHDL clocked processes. In the modified design.sxnf file, all the FD flip-flop clock input references (CLOCKnn) were converted into FDCE flip-flop clock input references (CLOCKMaster and CLOCKnnEnable) on the clock enable pin. The modified design.sxnf file was then processed through Xilinx's XACT tool suite.

We used a similar strategy to deal with other differences between the ASICs and FPGAs. Memory blocks were handled slightly differently in the FPGA version, for example, because FPGAs don't provide an efficient way to implement large blocks of RAM. We addressed the RAM differences between the ASIC and the FPGA by creating an entity for the RAM with separate architectures for the ASIC and FPGA RAMs. In the prototype, we used off-the-shelf RAMs to support the larger RAM requirements that weren't practicable in the FPGA. Smaller memory blocks (a 34 X 8-bit buffer, for example) did fit into the FPGAs and were a viable way of implementing the RAM needs of the design.

Another difference between ASICs and FPGAs is that synthesizing a latch in the XC4025E is an inefficient use of the device's resources. We wrote VHDL that did not infer latch statements, thereby avoiding the excessive use of CLB resources.

Real time

The main benefit of building a prototype is that we could verify the design in real time. The prototype allowed us to run test-case scenarios much faster than software simulation. With the CDMA handset prototype, it was important to achieve real-time speed to verify that algorithms worked the way we expected them to. This real-time environment allowed us to ensure that the reception and sound quality were high enough to meet Nokia standards.

The initial tests on the prototype were performed using a data loop-back sequence to and from a Tektronix CMD80 tester. Specifically, the CMD80 sent CDMA-format data to the RF section, which down-converted the signal through the baseband section for demodulation. The baseband data was formatted, remodulated, up-converted, sent back to the CMD80, and examined for frame errors. The frame error rate turned out to be zero, indicating a good data integrity path.

Those initial tests gave us confidence at the datapath level, which meant that it was time to try a voice call. We connected a basic telephone handset to the codec, which was located on the RF assembly. We digitized the voice and sent the signal to the reverse-link transmit logic. From there, we formatted, remodulated, up-converted, and sent the voice data to the CMD80. We then transmitted this voice data back to the prototype, where it was down-converted, demodulated, and processed by the DSP and sent to the handset's ear piece.

Figure 4	CDMA prototyping setup
The complete design was prototyped using three boards. The reconfigurable MP3 board was used for the portion of the design most likely to change; the other boards were used for the processor and CDMA engine, implemented with FPGAs, bonded-out DSP and microcontroller cores, and standard components.

The DSP software and the audio codec contributed to a noisy audio signal in the first test. We had to refine the codec design slightly, and the software needed to pick up two missing interrupts.

We performed many other tests, including refinements to improve the CDMA algorithms. We experimented with different methods for minimizing the base station acquisition time, for example. The prototyping system provided excellent signal visibility at the baseband, RF, and software levels, allowing us to monitor signals that would normally be inaccessible in an ASIC.

Stelios Podimatis is a member of the technical staff in ASIC engineering at Nokia Mobile Phones in San Diego, where his current responsibilities include design of the next generation of ASICs to be used in mobile handsets. His interest and work experience lie in ASIC development and ASIC emulation using FPGA technology.

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