SPC-Plato flow wins converts at Banderacom

The First Encounter-Strategy-Nanoroute flow has been put to the test at Banderacom, an Austin, Texas startup that designs Infiniband switched communications fabric chips. Terry Hulett, vice president of engineering and a longtime physical IC designer, put together a customer-owned tooling (COT) team that uses this unconventional flow. In this interview, Hulett describes the advantages as well as several limitations. The current flow requires Strategy for detailed floorplanning and signal routing, although SPC and Plato say they'll close those gaps.

EEdesign: What kind of chip design are you doing at Banderacom, and what are the challenges?

Hulett: Infiniband chips are high-speed serial protocol, switched packet, communications type devices geared for data-center applications. There's very high-speed networking between the servers and the filers, servers and each other, servers and the outside world. There are very high data rates, with each channel at 2 ½ Gbits per second, and you band channels together for a higher data width pipe. There are three types of devices -- host devices that go in the server, switches between the servers, and target devices. We focus on the target and switch space.

Internally the devices can look a lot like a crossbar switch, so routing congestion is a major problem. You can make the frequency less challenging, but then you end up making the paths wider. You may go from a 32 bit to 64 bit datapath, which makes routing congestion even worse.

EEdesign: Which chip did you design using the SPC-Plato flow?

Hulett: It has roughly 2 ½ million gates, 2 ½ Mbit RAM, plus analog custom macros. It's an SoC [system on chip] from the implementation side. Internal bandwidth is 100 Gbytes per second, but I don't think we've specified the internal frequency. Process technology is 0.18 microns.

EEdesign: Have you taped out the chip?

Hulett: It's not in Banderacom's interest to talk about the exact status. The chip is not in production.

EEdesign: What was your design flow for the chip?

Hulett: It's pretty standard. We write Verilog RTL, debug, and synthesize with Synopsys Design Compiler. We don't use any of the industry's newer verification tools. The system environment and the verification suite was all internally developed, and we have our own pseudo-random pattern generator.

After synthesizing with Design Compiler, we use SPC for global floorplanning, to make sure which macros are going where. Then we do detailed floorplanning with Strategy from Mike Stabenfeldt at Stabie-Soft. SPC is really good for partitioning things and getting you through the detailed placement, but it has no hooks whatsoever for getting all the detailed power in, hooking up to different macros, or working around pad rings and PLLs and analog blocks. You really can't do that kind of detailed floorplan with SPC.

We take information out of Strategy and synthesis and feed it to SPC. When we get a placement back, we put information back into Strategy. Then we pull it out of Strategy and feed it to Nanoroute, and then out of Nanoroute back into Strategy. So it [Strategy] really is the glue.

EEdesign: Are you using Nanoroute for both block-level routing and chip-level assembly? Any other routing tools needed?

Hulett: We routed this chip flat. Nanoroute's speed and capacity allowed us to do that. The only other routing was done inside Strategy, which does the power and ground routing and hookups for macros. There is no power routing at all in Nanoroute.

EEdesign: What other tools are in your physical design flow?

Hulett: It's a pretty standard complement of tools. We use [Avanti] Star-RCXT for wire extraction, Mentor Calibre for DRC and LVS, and [Avanti] HSpice to check paths.

SPC will do a good estimate. In fact, they do a track assignment, but it's still an estimate. When you get into the router, a very small percentage of wires, perhaps one percent, will be routed differently from what SPC says. 99 percent of the time it's a real good estimate, but one percent is just different, and that happens mainly on extremely high-fanout nets. So we need to do a post-routing extraction and come back in and do additional resizing.

EEdesign: What was your previous place and route flow?

Hulett: Banderacom is a startup, and this is our first tapeout. Basically, I joined the team nine months ago, and we were headed down the path of using an ASIC vendor. That wasn't going well, so I built a COT team starting about January. My personal experience is that I was one of the first ArcSys [Avanti] users at AMD. My team has all used [Avanti] Apollo.

EEdesign: In the SPC-Plato press release, you are quoted as saying that the SPC-Plato flow required only 2 Gbytes of main memory on a 32-bit workstation, compared to 6.8 Gbytes of memory on a 64-bit workstation for a "competing" solution. You say run times for place and route were 3 times faster than a "traditional" solution with a single CPU, and 5 times faster for two CPUs. To what were you comparing the SPC-Plato flow?

Hulett: It's Apollo and it's strictly a comparison of the routers. But it's old stuff, not [Avanti] Astro. I don't want to make disparaging remarks about current Avanti tools.

SPC and Plato have both developed tools that are very unique in that they really focused on memory image and run time. That makes a huge difference in the number of iterations.

EEdesign: What's the quality of the route with Plato?

Hulett: I did not take a completed placement to two different routers and do an extraction and comparison. But the quality of the [Plato] route looked very good. It looked clean and very solid. I've seen a lot of chips and I was pleased with the results.

Clearly it was a new tool, and we found a couple of routing bugs, and they had to fix those bugs very late in our cycle. They weren't logical bugs, they were DRC bugs. One that caused us quite a few violations had to do with a corner-case TSMC process they hadn't built in. It was a very understandable corner case.

EEdesign: Does Nanoroute help with crosstalk avoidance?

Hulett: Every CAD vendor tells you they avoid crosstalk, but I have not been able to prove that anybody really does. We follow a practice of using purely CMOS digital logic, so crosstalk is a frequency issue. Nanoroute does have an ability to keep wires further apart and to treat some wires as special compared to other wires.

EEdesign: What about antenna avoidance?

Hulett: Nanoroute did a very good job relative to what it was told. It cleaned up all the antennas it knew about. Some of the libraries weren't properly annotated, so we did have antenna issues, but it was nothing Nanoroute could have seen.

EEdesign: How does the SPC-Plato flow handle power issues such as IR drop? What about clock tree synthesis?

Hulett: Nanoroute is a signal router -- it does nothing for power. SPC does have a gate-level power distribution and IR drop analysis. These gate-level tools give you a relative measure. But if you really have a bunch of detail you want to analyze, there are other tools in the industry that will do a better job at the transistor level, and be more accurate around large macros.

SPC handles clock trees and does a fine job -- no complaints there. We did have one issue with balancing separate trees to end up at the same time point. There was a feature missing, but they've since added that. It did a fine job of balancing clock trees from common start points.

EEdesign: How do you handle test?

Hulett: You have the ability in SPC to reorder scan chains and spit the order back out. But fundamentally, it's all done with our external test tools. SPC provides information to feed back into the test tool.

EEdesign: What improvements would you like to see with Nanoroute, Strategy, or SPC's First Encounter?

Hulett: Nanoroute performed as advertised. It's a point solution that just does routing. They do have some neat things for controlling signals for crosstalk avoidance, but I'd like to see some different controls. They also clearly need to do something about the power situation. We're getting things done just fine with Stabie-Soft, but I can imagine that most customers won't like dealing with a one-man company.

I'm happy with the SPC tool, but they need to add low-level logic optimization to handle timing better. They don't do pin swapping. If you've got a four-input NAND gate, and your slowest path is through the B pin, you can't reorder it through the A pin and make the path faster. And you can't do the detailed floorplanning. Whenever I've done a chip, I don't just have a nice grid. There are always questions like, how do you hook up the PLL to this pad, and how do you get the power ring to jog around the PLL? Those are the kinds of things SPC doesn't do, so we do all that in Strategy.

I'm pretty excited about Strategy, but part of it is that I've known Mike Stabenfeldt for years. It's pretty amazing what one guy can do. He lets you read in LEF and DEF, overwrite it with the GDSII of your cell libraries, and have a fully connectivity-driven top-level route with real polygons down below. Then he streams it out faster than any tool I've ever seen. He's got a basic polygon editor called Slam. I think Mike needs to continue progressing with interactive capabilities. He's got automated stuff, but it's still a little cumbersome in and around difficult areas like custom routes, PLLs, and power.

EEdesign: Are these tools production-ready today?

Hulett: They weren't when we started. But I would say they're all production ready now.

EEdesign: You have a physical design flow based on three different vendors. Is integration a problem?

Hulett: The tools all write LEF and DEF. Fundamentally, you take something out of Strategy and put it into SPC through DEF files. We've written a couple of our own little scripts to put stuff directly into the floorplan.

With synthesis, there are a lot of iterations. It's possible we could decide in the future that [Synopsys] Physical Compiler would be interesting for the macro level. It would merge into this flow pretty easily and would reduce some of the iterations. But mostly I think design until the last two weeks is a learning cycle, so you want iterations, because the more iterations the more you learn.

EEdesign: Does the three-vendor flow bring up any support issues?

Hulett: We have not had support issues because we were on board very early with SPC, Plato, and Stabie-Soft. When we call, they answer the phone. I don't think any of these three companies are mature enough so you can get a feel as to how they're going to treat all their customers.

EEdesign: Will SPC, Stabie-Soft, and Plato provide your complete place and route environment going forward?

Hulett: Yes, with the possible entry of something like Physical Compiler at the macro level. For the near term this is the flow; longer term, I don't know. There are always new guys coming on the horizon, and I've never been afraid of using new tools.

I think these guys [SPC, Stabie-Soft, Plato] have done some interesting work. They've shown you can do something without Cadence or Avanti. Nobody in the world thought you could tape out a chip without one of those two for a long time.