TI designs wireless processor core with Synopsys' Physical Compiler
EEdesign Exclusive
By Richard Goering
EEDesign
(05/12/00 13:07 p.m. EST)
One of the first major design wins for the Synopsys Physical Compiler product was Texas Instruments' ARM925T, a wireless processor core based on the ARM microprocessor. Physical Compiler is a "physical synthesis" tool that integrates synthesis with a complete placement capability. Here, Rakesh Patnaik, program manager for wireless communications at TI, and Mike Fazeli, world-wide EDA manager for DSP-based designs at TI, discuss some of the advantages of Physical Compiler. They also note several areas in which they'd like to see the product improved or enhanced.
Since the ARM925T is an MCU core, it is not a literal tapeout. This hard core has been completed and installed in TI's library for internal or external use. A TI wireless design that incorporates this core is expected to tape out within the next few months.
EEdesign: What can you tell us about the ARM925T core?
Patnaik: Basically all I can say is that it's a 32-bit RISC processor designed to run operating systems like Windows CE for embedded platforms. It's in the range of 250-K to 500-K gates and runs at 140 to 180 MHz. This is a cache-based core, and we have a proprietary address translation and interface bus.
EEdesign: When did you start using Physical Compiler during this project?
Fazeli: We were introduced to Physical Compiler in July 1999. Back in September of last year we decided to go into two parallel paths. We wanted to use our traditional flow in addition to the Physical Compiler flow and see which one was going to be more useful for us. Around November we decided there were so many good results with Physical Compiler that we decided to just concentrate on Physical Compiler flow. That investment has paid off.
EEdesign: What kind of design flow did you use with Physical Compiler?
Patnaik: We used it for the entire core. Our goal was to use one tool that could do timing closure in a single pass. On the back end, our internal flow includes Avanti's Planet and Apollo tools. Physical Compiler replaces timing-driven placement, so Planet is no longer used for that. However, we still go into Planet to generate data for our custom layout flow.
EEdesign: What problems were you having with the older Design Compiler-to-Avanti flow, without the use of Physical Compiler?
Fazeli: Timing closure was one of the biggest concerns that we had. Back in middle of 1999, we made a very conscious effort to try to resolve the cycle time delays we had due to timing closure, and as a result of that we started looking at all the different technology available to us. We even drove some of the new technology that was being developed by different vendors.
We started looking at what it will take to bring physical information up front into the synthesis domain, and to have much better synthesis results that are aware of physical constraints. Typically, we were averaging three to five total iterations on every design we had.
Patnaik: On this particular design, we had a megamodule on an ARM core, which is a black box, and we had a lot of memory, so we were core limited rather than area limited. Thus, floor planning and timing closure were very big challenges, and we had to run eight to 10 iterations to close on the timing using the old flow.
EEdesign: How many iterations did Physical Compiler take, and what kind of timing correlation did you get?
Patnaik: It took a little while to get the flow in place and get a good correlation. Once we got it we basically just had one pass, and then a second pass to fix some holes. We did see a very tight correlation between Physical Compiler timing and post-route timing. It was within 5 percent. Before, it varied quite a bit. Sometimes the correlation was good, sometimes it was totally off.
EEdesign: How much design time did Physical Compiler save, compared to the older flow?
Patnaik: In this particular design we were able to reach our commitment to the customer on time. We saved about three man-months of effort. Clearly this was from reducing iterations, and the second thing that's very important is that the flow was simple to execute. I come from a design background, and I could look at what Physical Compiler was doing. I didn't have to go to the layout shop to see what's going on.
EEdesign: Did you get a better chip in terms of area, performance or power as a result of using Physical Compiler?
Fazeli: It was not our focus to improve performance or power dissipation. What we focused on was cycle time improvement. However, due to the improved cycle time we were able to push our designers beyond the target we had originally set for ourselves. So you could say that indirectly we did improve the performance. For area, we did not see any improvement over the old flow we had with Design Compiler and Avanti, but we did not stress that point either.
EEdesign: What are the run times for Physical Compiler? What about the initial setup?
Patnaik: On this design we had overnight runs. It was very quick turnaround, and we could compare different results very fast. For setup, this was our first time using Physical Compiler so we had to set up a TI library. One of our objectives was not to replace the existing flow. Our challenge was to take the existing floor plan and read it into Physical Compiler. We had to write a couple of scripts and go through a couple of iterations.
Fazeli: Because this was a pilot project, Synopsys understood the value of a successful design completed with us. So they spent a lot of their resources to do the initial setup for us. With respect to some of the other [EDA] vendors, it took a little bit longer to set up the initial environment. But once we had environment set up, going through the flow and actually running the Physical Compiler program was not that difficult.
EEdesign: Who runs the Physical Compiler program? How hard is it for a logic designer to learn?
Patnaik: One of my team members worked with someone from Synopsys, so it was mixed. One of my lead designers took just three days to take an existing design and go through and complete the process. Obviously he was very literate in synthesis. You have to have some knowledge of the physical world.
Fazeli: It really doesn't take a lot more than just understanding some of the physical constraints on layout. That is something that can be comprehended by logic designers.
EEdesign: Does the Avanti Apollo tool keep Physical Compiler's placement?
Patnaik: Yes they do. Global routing is thrown away. But the Physical Compiler timing reports correlated very well with post-layout detailed routing.
EEdesign: Is not having detailed routing in Physical Compiler a drawback?
Fazeli: I believe so, and I'm hoping Synopsys also realizes that and is doing something about it. I think that different development engines and teams working on two different software tools can contribute to lack of correlation. Estimates are exactly that-estimates.
EEdesign: Does Physical Compiler do any clock tree synthesis?
Patnaik: Not today, and that's our first requirement for enhancements. In high-speed design we rely a lot on clock skew.
EEdesign: Does Physical Compiler help with test?
Patnaik: With this design, we were able to do scan chain reordering based on the placement, but we had to write some extra scripts to do that. That helped out quite a bit, because in the past we had a lot of problems with scan chains. But Physical Compiler has helped only with scan chain reordering. We would love to see more. Basically, the [test] capabilities they have in Design Compiler need to be extended into Physical Compiler, with the additional capability of placement and detailed routing. We would also like to see power optimization. It's not available at this point.
EEdesign: How do some of the other new physical design tools compare to Physical Compiler?
Fazeli: We've looked at the other available tools. I think you're basically trying to solve two different problems. I would not put Physical Compiler in the same boat as Monterey or Magma. I think there's room for both Physical Compiler, and the Monterey- or Magma-type tools, in any given design flow. Physical Compiler gives you an entry into physical design and back end tools that's a lot more optimized. But I do believe there's additional room to improve density and performance with back end tools.
[Cadence Design Systems'] PKS has a wonderful flow and a very streamlined methodology. The concern is that if you really take a look at large company like TI, Synopsys has already won the market as far as synthesis as concerned. It would be major reinvestment to consider switching the synthesis engine.
We've decided on Monterey within DSP-based product lines. It's for streamlined projects, when physical design resources are not available for us, and we want to take advantage of an automated and streamlined flow.
EEdesign: How will you deploy Physical Compiler and Design Compiler going forward?
Fazeli: I think it's going to be a combination of Physical Compiler and Design Compiler. It's very much resource driven and time-to-market driven. I don't think one solution will fit all project requirements.
eedesign.com |
