China on the air

Data models and language transcendence

Read other articles from this issue: Table of contents, June 2005 FEATURES China on the air Keep your eye on the metal bumps USB reaches mainstream status Video goes mobile Distributed data

FREMONT, CA.

Those algorithms are defined in an evolving broadcast DTV standard—developed at Legend Silicon and its partner Tshinghua University in Beijing—dubbed DMB-T, for Digital Multimedia Broadcast Technology. The goals for Chinese DTV are similar to those for ATSC in North America; DVB-T in Western Europe, Singapore, and Australia (see "Video goes mobile"); and ISDB-T in Japan: for consumers, clear audio and sharp video free of ghosts and snow, and for broadcasters, more programming capacity in the bandwidth once occupied by a single analog channel.

According to Dinesh Venkatachalam, Legend Silicon's engineering VP, the Chinese government is promulgating its own DTV standard for both business and technological reasons. On the business side, the adoption of a homegrown standard will provide a competitive boost for Chinese manufacturers, as it will help them avoid the disadvantages they faced when the country adopted the GSM cell-phone standard. Dinesh said that China still imports 80% of the GSM handsets sold there, and the government doesn't want to adopt a DTV standard that gives foreign manufacturers the head start enjoyed by foreign GSM suppliers.

The technological advantages of DMB-T include its ability to work indoors and outdoors for fixed and mobile receivers as well as its support for data broadcasting, instant messaging, and Internet access. "In a nutshell," said Dinesh, "we have taken the best of ISDB-T and DVB-T and expanded on them."

Dinesh Venkatachalam, Legend Silicon's engineering VP, and Edward Yu, manager of transmitter products, evaluate DMB-T performance in Legend Silicon's RF laboratory.

Legend Silicon's role in DMB-T, said Dinesh, is to employ the company's knowledge of the standard to "provide end-to-end solutions for the DTV broadcast market. We provide solutions based on FPGAs for the exciters that generate RF broadcast signals, and we develop ASICs for digital receivers and set-top boxes. We also provide ASIC and FPGA-based test solutions to measure parameters such as MER [modulation error ratio] and BER in DTV head-end installations."

He added, "Our FPGA system solutions are market enablers." The primary FPGA customers, he said, are exciter makers in China, Japan, and Europe, adding that the volumes, and profits, will come from the demodulator ASICs that will populate receivers and set-top boxes purchased by Chinese consumers. "We sell our FPGAs to broadcast equipment makers like Rohde & Schwarz, because the more boxes they sell, the more set-top boxes our customers will sell."

Figure 1.  Legend Silicon’s ASIC, designated the LGS-8222-A1 in the current generation, takes a tuner input and generates an MPEG-2 transport stream. It requires only an external DRAM and crystal. An I2C bus (not shown) provides for communication with an MPEG decoder.

Figure 2.  Engineers at Legend Silicon take a design from high-level specification through some floor planning before handing it off to a silicon foundry. Although not shown in this diagram, simulations or other checks at each stage provide feedback to improve the design.

Though floating-point solutions are convenient for exploring various architectures, Tangirala explained, they would be impractical in a low-cost IC destined for high-volume consumer applications. When floating-point simulations in the presence of real-world data appear to be performing well, the engineers convert their floating-point code into a fixed-point C-language representation.

Ravikanth Tangirala, senior ASIC engineer, outlines how the design process proceeds when the Silicon Valley team receives a DMB-T spec from China.

Using fixed-point C simulations, the engineers can determine the effects of bit truncation and other fixed-point restrictions as they work to achieve sufficient performance. The fixed-point C is then thoroughly tested to make sure it meets performance criteria and is translated into fixed-point RTL code. To demonstrate the functionality of their fixed-point RTL design, the engineers employ a Verilog-based simulator.

Were Legend Silicon implementing a well-defined, mature standard, the completion of a fixed-point RTL design could represent the point at which ASIC design begins in earnest. But because the engineers are implementing a new, evolving standard, they want to evaluate their design in real-world situations before committing to an ASIC. Consequently, they implement their design in an Altera StratixII FPGA or an IPFLEX DAPDNA-2 reconfigurable processor and exercise it thoroughly in their Silicon Valley RF lab and in real-world RF environments in live broadcast field trials in China.

"When we do the emulation, we keep in mind that our ultimate target is an ASIC. So we try to partition our emulation system to mimic our ASIC's partitioning in order to minimize the changes needed for the FPGA-to-ASIC transition," said Tangirala. "That's important, because for the ASIC, the only sources of verification are our simulations and formal equivalence checks; we can't do an actual performance evaluation until ASIC samples come back from the foundry. But if we keep the emulation and ASIC code very close, we can have a high confidence level that our ASIC will work. And we use a top-down flow to simplify the synthesis process. Since we have started using the Magma flow, it's gotten much easier. The interface is much cleaner now."

"In the past," Tangirala said, "the emulation flow was completely different from the ASIC flow, and we had to deal with issues involving, for example, differences in how to implement state machines. Now, all the vendor tools can handle the same kind of code, so the code we use for our FPGAs can go right to the Magma tools we use for ASIC synthesis. This ability to use the same code increases our level of confidence in the project."

Dinesh added, "We are also coming up to speed on emulation based on the IPFLEX DAPDNA-2. This is a dynamically reconfigurable processor capable of mapping from fixed-point C code directly to a hardware emulation platform, eliminating the transition from fixed-point C code to RTL and then to gates. This new class of devices eliminates the performance barrier we experience with FPGAs."

Exhaustive test of the FPGA implementation must precede the FPGA-to-ASIC transition. Edward Yu, manager of transmitter products, described a typical test setup (Figure 3). A transmitter generates a signal based on PN23, PN15, and PN9 pseudorandom bit sequences in a test mode. An Agilent Technologies BERT analyzes the pseudorandom sequences at the output. A channel model represents real-world interference, using a ghost generator that simulates reflections off buildings or vehicles.

Figure 3.  Using real-world RF signals recorded in China, Legend Silicon engineers evaluate the performance of their ASIC (whose functions are highlighted here) in their Silicon Valley RF lab.

"The ultimate question we want to answer," said Dinesh, "is how well we can recover data from a real-world environment full of reflections and noise. That's the measure of our chips' performance. And all of our testing helps us achieve optimum tradeoff between data rate and error correction."

When lab results are satisfactory, Dinesh said, "an FPGA-based receiver system goes into the field. It gets driven around, in a special van with datalogging capabilities, through cities and along highways—every possible situation to make sure the thing works. We investigate all kinds of effects, including weather impact as well as reflections from cars, buses, and planes flying overhead. In addition, we evaluate Doppler effects, which require more stringent tests than were employed 10 years ago for systems like ATSC in the US. In mobile systems, the environment is changing millisecond by millisecond, and we have to employ stratagems in our product to take that into account. We have demonstrated operation to 150 kilometers per hour, with the goal of providing over-the-air standard-definition TV reception in buses and on 420-kilometer-per-hour high-speed trains."

The extensive testing results in lots of data the engineers have to analyze. "We record any place where a problem occurs and see if it's a real problem that we need to solve. Often, it's not—the truck may have driven too far from the transmitter, for example, and we have to ensure the coverage exceeds the theoretical coverage area that would be used in deployment.

"We've done a lot of work correlating our lab noise generators with real-world data acquired over the last four years to ensure that our laboratory setup represents the worst-case scenario. We are not licensed to broadcast over the air in the US, but here in the lab we can duplicate any worst-case real-world scenarios—Doppler effects and reflections—to represent worst-case field-testing. We then take our systems back to the field to make sure that, yes, we have simulated the worst-case situations in our lab."

That's not to say that meeting the letter of the specification pleases everyone: "Somebody always wants to keep extending the reach of a transmitter without putting in additional stations, and eventually someone will want to put high-definition TV on a high-speed train. Those are situations that future generations of the algorithms can address."

Of course, some problems do require fixes. "We generally go back to our fixed-point simulations. If there's a bug in our design, we'll fix it and generate the new FPGA code that can be downloaded in China, where we take our test receiver to the spot where we had problems to prove that our fix works."

With FPGA tests complete, ASIC design begins in earnest. Although some vendor-specific functions common to the FPGA and ASIC are taken into account in the Verilog RTL simulation, the designers inject additional vendor-specific details such as I/O cells, analog IP cores, scan cells, and scan paths plus foundry-specific BIST-enabled RAM blocks.

"Now our flow uses Magma software from RTL to netlist," said Tangirala. Although not shown in the Figure 2 flow chart, the team does extensive simulations at each stage of the development process. For example, he said, "We'll run an ASIC simulation once we insert vendor-specific RAM blocks, and we will do another after DFT scan insertion to make sure all the scan chains work. We also use Magma Quartz to do RTL-to-gate formal verification, and we do lots of gate-level simulations to make sure the synthesized logic does what the RTL is asking it to do. We'll simulate the first gate-level netlist the synthesizer generates without timing information and then again with full timing information."

Some companies will skip the intermediate simulations, said Dinesh, settling for RTL and gate-level simulations with full timing (which can have much longer run times than simulations without timing), but he explained that "if something breaks in between" those two stages "it can take a long time to find the problem."

Particularly valuable, Dinesh and Tangirala agreed, is the ability to do some floor planning. Traditionally, said Dinesh, "We'd throw our design over the wall, and the foundry would come back and tell us, 'OK, here is your die size.'" His response to that, he said, feigning incredulity, was often, "What are you talking about?" Now, added Tangirala, "We can use Magma Blast Create and Blast Fusion to place macro blocks, and we can define the data paths efficiently because we know where the data is coming from and going to. An overnight simulation lets us know whether the die size we have chosen will work, and that's very important to us because every millimeter or even half millimeter increase in size represents a substantially higher cost."

When asked about using an integrated flow like Magma's vs. point tools for functions like scan insertion, Dinesh said, "Point tools give better performance in certain cases, but just going in and out of the [point-tool and synthesis-flow vendor] databases, you tend to make a lot more mistakes. If you want to squeeze out the most compact set of test vectors or if you feel your fault coverage has to be 99.9 percent, then run a point tool, but if 98 percent is good enough, then it's better to go with the more integrated flow because of the mistakes you can avoid and the time you can save. One reason we went with Magma was to eliminate the many scripts that we had to write to convert between different vendors' formats. A simple typo could cost you a month. We wanted the same database throughout the whole flow to avoid mistakes like that."

David DiSalvo, senior RF test engineer, describes the test sequence for demodulator prototypes. Identical interfaces for ASIC and FPGA implementations, he says, allow easy test-data injection and extraction from any DUT, enabling comparison of prototype performance with simulation results.

He said the company doesn't build in an IEEE 1149.1 interface, which represents too much overhead for a low-cost consumer chip, but the chip does include a NAND-tree structure, which he runs tests on as a "quick and dirty way" to make sure all the device pins make contact with the board. The team also does some subjective thermal tests, he said, heating up and cooling down the chip to look for anomalies. "Thermal performance is guaranteed by the factory, but we want to make sure nothing unusual is going on."

With preliminary tests complete, said DiSalvo, "we take the board and run RF tests to make sure the ASIC's performance is better than the FPGA's, which we would expect because clock jitter should be much less on the ASIC." At that point, the foundry will have completed its back-end test strategy, he said, and the parts should be ready for production.

Even as one ASIC generation gets to market, the team is working on another, and in fact, each ASIC design takes into account the needs of the next-generation development effort. Said Haiyun Yang, Legend Silicon ASIC architect, "We design the chip so we can switch out various functions." For example, he said, discussions are taking place in China regarding the FEC algorithm. To evaluate a potential upgrade, he said, "We can switch out our ASIC FEC implementation and replace it with a new one implemented in an FPGA."

The next generation will embody new FEC capabilities, and it will be fabricated in a submicron process. "We don't need to push the technology to get gigahertz speeds," said Dinesh, "and so far, 180 nanometers has been the sweet spot as far as price goes. But that's changing, and the new ones will be 130 or 90 nanometers. Our basic next-generation goals are better performance and lower costs."