RedSwitch Seeks Stability and Support in its Design ToolsBy Ann Steffora, Managing Editor, EDAVision.comEDAVision recently had the pleasure to sit down with Frank Chen, vice president of engineering for RedSwitch, Inc. to discuss in general how they create their design flows and some of the issues associated with it. Milpitas, Calif.-based RedSwitch is a fabless semiconductor company, focused mainly on standards-based switch fabric components. Its main products include switches and brides for Infiniband, RapidIO and 3GIO protocols. Chen is in charge of approximately 50 design engineers.EDAVision: Mr. Chen, thank you for your time today. Could you begin by giving an example of a particular product and talk about the design flow and which particular tools RedSwitch uses? REDSWITCH: Actually all of the products are very similar in terms of flow and we are actually a very vertical company, so we are making specifications at RTL with Verilog and we do a test bench, which is currently Verisity-based. We are using Synopsys at the front end for synthesis for most of the things that we are working on, and our back-end is basically Avant!-based. EDAVISION: How did you decide which tools to use? REDSWITCH: Basically, we had a history and because of that were familiar with the tools. We have used them for many years and we have enhanced them. Our philosophy is very simple: we use all the tools regardless of where they come from, they are more or less similar and it really is up to us to maximize the tools' potential. But we pick other tools based on the quality, the feature set, and most importantly, actually we look at the support level we can receive. EDAVISION: Do all of the tool vendors provide the level of support that you need? REDSWITCH: To answer this question, I will give you an example: we are the first group users of Avant! tools. We were very small when we started and we were getting down to very strategic issues. They are very adequate and very good at support and that is basically our history. Our problems are very simple and all of the tools are more or less the same. EDAVISION: That's interesting. I'm sure that EDA vendors would not be very happy with that statement, because they think that their tool is the best, correct? REDSWITCH: I wouldn't say that – the problem is having the best people. Some people can take a very complicated design and get it completed and some people can't even get a moderate design completed. I think that the tool set is very, very similar as it has been and has penetrated every corner of the world. Look at what each person can produce with the tools. I think that is the key difference. EDAVISION: When you are putting a flow together, how much work is involved to make sure that the tools interact with each other? REDSWITCH: Oh, this is very significant. I think that we normally spend part of a year's effort to make things flow. This is because our chip, number one, is very big (big in relative terms) and number two, we only have a small group—we don't really have a big company infrastructure. We have an expert in each area and we have a very small core group to build the flow. Ultimately, the processes are limiting and there are many, many issues that could arise when you have so many people in touch with the CAD tools. So, that is really the key for us. [Also,] if you look at the basic stuff and especially on the back-end side, literally, it is the clock, power and timing closure. If you can figure out the clock and the power then you are halfway there. And if you can take care of the timing, then you are 100 percent there. So, for us, it is very, very simple. We spend a very, very significant amount of time to make sure that our clock is adequately done, our power is adequately done and our timing closure is done properly. EDAVISION: Going forward what kinds of changes do you see happening in your design flow? REDSWITCH: Looking forward, one of the key areas we are seeing significant activity is the signal integrity area. I think that people are always saying that timing closure is the top issue, I agree and it is an important issue, but I think that we basically know how to control it. It's not that bad and we can figure it out, I mean, we can do adequate iteration to meet the closure. I think the most difficult issue is how you go to 0.13-micron and forward – crosstalk, signal integrity and other issues come to affect the timing and it becomes a very big issue. EDAVISION: Which signal integrity tools are used now in your design flow? REDSWITCH: We are using the Avant! tools, but I think the general issue is that this these are all “fixing” tools and not “prevention” tools. I think that we realize there has to be a prevention tool. Actually, the timing we know pretty well and can control it, but the signal integrity factor you don't really know until final route and everything is done. EDAVISION: What do you think is the best way to address a prevention tool to take into account signal integrity from the beginning of the design so you don't run into the problems? REDSWITCH: I don't know, it really is a very difficult issue and I don't really have a good solution here. I personally feel any tool that can give you adequate warnings for [the issues] that can be taken care of before the chip routes then we can take care of the critical matter. I don't know, we are getting to the stage where, anything we could do even manually or semi-manually [would be helpful]. EDAVISION: What type of desktops do the engineers use? REDSWITCH: We use desktops as terminals, which are Sun Solaris-based. EDAVISION: What type of servers does RedSwitch use? REDSWITCH: We are mainly using Sun E450/E420 servers with eight CPUs and 12 gigabytes of memory, and 2P Linux servers with x86 processors. EDAVISION: If you could say one thing to all the EDA companies about the kind of software they deliver, what would you say? REDSWITCH: Well, that's a good question. We have been using Avant! for so long and we really appreciate it. We still feel good about the Mercury database, which is very, very good and can do many, many things because of the single database format. But I think [one issue that could be better addressed] is their compiler and one thing they need is the coordination between the front-end timing closure versus the back-end routing and actually they have not been very consistent, they've just been average. This is one of the things that would be nice. |
|||||
|
|
|||||
|
|||||
