Frequently, the customer netlists sent to ASIC vendors' design center engineers for physical implementation are riddled with problems. "If you have timing or congestion problems in implementations, it's likely that they started with the RTL and were made worse in synthesis," says Dan Deisz, director of LSI Logic North American Design Centers.
One might think that the company's leading-edge, 0.10-µm process geometries have brought RTL problems to the fore on physical design. But according to Deisz, RTL issues that cause timing-closure problems start even at 0.18-µm. "At 0.13-µm, it’s going to get crazy," says Deisz. In fact, for designs at 0.3-µm, LSI Logic deems RTL analysis mandatory.
Deisz maintains that many front-end designers simply fail to comprehend the impact of their RTL design decisions on physical implementation. For example, it’s not uncommon for RTL Designers to code a multiplexer with eight inputs totaling, say, 10 kbits, all feeding a single 1-kbit output. This causes an instant traffic jam. The eight outputs should have all been multiplexed locally. Deisz notes that RTL rule checking can esaily pick off problems like this one.
Deisz’s goal for LSI Logic’s design centers is a stable, predictable turnaround time for ASIC implementation. Although he regards RTL rule checking to be in its infancy, his group has settled on TeraForm as a first step toward a long-term solution.
For LSI Logic, rule checking comes into play in a number of ways. Not only do Deisz’s design centers receive handed netlists, but they sometimes become involved at the specification level. So in the former case, they’re interested in using TeraFrom to check the customer’s RTL against rule sets that LSI develops for specific foundry processes. In the latter, they’re checking themselves, as they’re knee-deep in the logical design.
Deisz summed up the need for RTL rule checking: "We asked a customer, who had already submitted a gate-level netlist, for his RTL. The customer demurred, saying he had to ‘clean up a few things’ first. He’d already given us the netlist that was synthesized from that same RTL!" Deisz hopes that as ASIC vendors make it a habit to ask for RTL from cusomters, those customers will begin to integrate RTL rule checking into their design flows, if only to prevent the embarrassment of having their ASIC vendor do it for them.
The days of ASIC vendors accepting netlists from customers at face value, only to run into a buzzsaw in the back-end flow, are ending. It’s different for both the vendor and its customers. "Customers look at us and ask, indignantly, what are you going to do with \[our RTL\]? Our reply is that initially, we’re going to do our best to analyze it. But we’re still learning to do that. We’re not experts in that realm yet. We’re growing that expertise at the same time as we’re bringing on a tool set that helps us," says Deisz.