EE Times: Could each of you take just take a moment, and tell us what kind of chip design work you're most involved with? Tell us what your primary job function is, and just give us a brief idea of the complexity of the devices you're currently working with.

Joshi: I'm responsible within Sun for two main areas. One is all of the CAD tool acquisition, development, and deployment for the tools and flows for both the processors, as well as the ASICs within Sun. The second area is the computer resources and facility that we have here, which runs most of the simulations for us. I would say that 90% of my energy and effort goes into the processor design side.

Fazeli: I'm responsible for the identification, development, and integration of EDA technology for TI digital application specific products, and wireless business unit products. That's basically 95% of all the DSP based designs that we're doing within TI, as well as digital SoCs. I'm basically focusing the majority of my time on the processor and the DSP side of the house. However, we are also working with our ASIC infrastructure development team to drive some of the technologies that we've proven on the DSP based designs, so there's a close cooperation with us.

Chris Malachowsky

Malachowsky: We're a smaller house so we get to do more. I have in my organization product developments, computer resource management, and our corporate CAD effort, which is mainly aimed at very high-leverage in-house development. I'm also the guy here that buys and procures most of the CAD tools. I still participate in all our designs.

We have COT [customer-owned tooling]. Our chips are all ASIC oriented, and we have graphics processors. I'm probably more involved with the graphics processors, which are very large, but not nearly as regular as CPU designs. The group also supports all the core logic efforts in our end product line.

EE Times: So we have a pretty good mix here. What I'd like to ask each of you now is whether you have a set of established best practices for SoC design, and if so, how these practices are disseminated through your organization, maintained and enforced.

Joshi: Yes, we do, and we have practices both at the technical level as well as at the management level. From the technical side there are clearly things that you want to make sure that you do in your design. For example, for any tools or flows that will need to have scalability and performance, we want to make sure that that's built in. That requires you to really plan out and architect the right tools and flows. You really do them as very well thought-out architectures, which can grow, and deal with the hundreds of millions of transistors that you're going to have.

The second thing we do is to make sure that we have designer views, and that we test them thoroughly. There's a whole bunch of stuff we do on the management side as well. There are key hot buttons I have there. One is documentation to make sure that we save every piece of work that we develop, both on the design side, as well as the CAD tool side in a central repository. That's so we don't lose our IP, it's there and we can share it.

Number two is communication. There needs to be a lot of communication between different groups and the developers, so that we can have the leverage and avoid the duplication.

Fazeli: We definitely do, and there are several areas that I think are appropriate to mention. One is the integration of new tools into the TI design environment. That's based on a rigorous process of early engagements with vendors based on the design requirements, and the complexities that we're seeing. We're evaluating and then proving the concept on driver programs, and then finally deploying it to all our worldwide design centers. We have established criteria that are company-specific. I consider them to be globally based on criteria such as the ability to support our worldwide design teams in terms of capacity, quality of code, and what processes they have.

The other area that comes to mind is a very strong, management driven, full reuse strategy, that basically includes establishing on a continuous basis documented standards, specific goals for quality of results, and reusable tool boxes. There is also a common chip creation strategy that will allow us to build our systems on chip, based on a peripheral reuse strategy and also on the best EDA capabilities that have been identified.

Mike Fazeli

Then, thirdly, we will work with vendors to develop the technology that is needed to design our DSPs without compromising performance, power, and area. That may seem like a lot of words, but that's actually what is happening. The DSP creation process is very much different and separated as far as the infrastructure is concerned from the rest of our chip creation methodology.

Malachowsky: I'll just focus on a couple areas. We have a way of progressing designs from concept through production. The flow of information milestones, checkpoints, and certain information that's required to progress a design through those stages are documented in a schedule template that we use, and in checklists that we use to make sure we don't miss anything. The complexity of these things is getting pretty high.

We capture as much as we can in automated flows, which are documented and posted on the Web. Design requirements that enable the flow of best practices are captured with as much automation as possible. That's what my group does a lot of -- trying to capture what has been determined as a best practice, or a best result, into an automated set of flow progressions, tool progressions, or checks to ensure adherence to certain things.

So, the design is checked for all sorts of things that have been determined to be good. We're capturing a lot of what are best practices into checklists, and documented ways of doing business. We're characterizing a new checkpoint when it enters the door, measurements we're going to take, and the way we're going to take measurements. We standardize on a number of things, and we expect a certain level of completeness before we'll declare something good enough to sample, or good enough to ship. And hopefully it's done in a machine readable way.

EE Times: You mentioned your own workflows, and the best practices -- do they ever go awry? Do they ever not meet expectations, and if they don't, where in the design process do they break down?

Malachowsky: It's not unlikely that something going awry is what made it a best practice! The previous best practice, or lack of best practice, is what caused the problem. I think the rules of operation of today generally apply tomorrow, but not completely. The complexity of what we're doing is changing, along with the speeds and the personnel. It's hard to know sometimes whether you're lucky or good. After a while the luck runs out, and so you tend to improve something.

For example, we took a measurement this way, but we didn't look for some cross correlation with another type of signal. We say, okay, next time we do this measurement we're going to make the other side of the chip active, and measure a quiet signal on the opposite side. I think our methodologies are always improving; we're never content. You bring in new folks who have new ideas, and you're always evolving. I guess best practices are not something that could ever be stagnant, and remain best.

Joshi: Yes, I completely agree with that. I think the best practices have to keep on getting better and better over time. You have to challenge yourself to find new corner cases and holes, and plug them before they even show up, so I think anticipating the potential hazards is the name of the game to stay ahead.

Fazeli: I also have to agree with the other two gentlemen. I have another angle at this, which basically says our methodology continues to change based on the complexities of the designs. For example, take the capacity of tools.

We have to start developing the design hierarchies, we have to be able to work around the limitations that the tools' capacity poses on us, and basically improve the methodology to include hierarchy. The fact that we have to bring in IP from different sources is forcing us to have mixed language simulation capabilities, so it is an evolving process, and it really is being evolved because of the complexity and the dynamics of SoC design.

EE Times: Let me follow that up with one question. Do you have best practices that are actually used for selecting and evaluating IP? What do you require of the vendor -- VSIA compliance, or other standards?

Fazeli: I'm not involved with the external IP selection criteria. I would think that the VSIA bus standards are criteria that need to be there. The choice of HDL language that the IP is being transferred in was an issue at one time, but I think we've worked around that in the industry as a whole.

Sunil Joshi

Joshi: At Sun we actually have a very formal process, which we call Sun Craft, which is a process that we use for making buy decisions. As well as the technical evaluations, we make sure that we know up front what we are planning to do, what we are going to assess, how long it's going to take, what resources we will put on it, and what the decision criteria are. So we apply it rigorously, and that has worked really well for us to buy the best of the breed tools that are out there.

Malachowsky: I guess we're a little less formal in our external IP selection, but the things that we've learned to ask for and look at over the years have been captured in checklists and decision-making forms or flows. For us, the acquisition of IP is a matter of really understanding how well the IP, as designed and verified by the vendor, will integrate. Not only will it solve our functional need, but how well will it integrate with our design flow and our existing tools?

EE Times: Are any of you involved in the creation of reusable IP, and if so, could you tell us a little bit about the best practices you've developed for ensuring that IP is reusable?

Fazeli: Within TI, as I mentioned, we do have a very strong peripheral reuse strategy. It basically is the foundation for our chip creators, it includes standards which come with the hardware. There's a path to production RTL using reusable tool boxes. It should be ready to be installed anywhere in the world in an IP delivery platform and repository, with well defined and documented characterization corners, and also verification practices.

As I mentioned, the whole effort is focused around the effort that it will take in order to bring the chip into a reusable IP process so that IP could just be plugged in. There is a lot of automation that is built into it, so that we will be able to give a chip description that is generating all the different views that are needed in order to go into full-chip verification and implementation.

Joshi: At Sun, too, especially in the microprocessor domain, internal generation of IP and reuse of IP is very natural because a lot of the processes do leverage what existed before. And it's not just the soft IP or design content, or even custom designed hardware blocks, but also the tools and the methodologies at every level -- whether they be circuit design methodologies or layout rules. They're all leveraged quite a bit. It's natural to some extent because you don't have a tremendous amount of resources, so people will automatically go look for what's available before they invent something new.

Malachowsky: One of the things we've evolved to, as I said, is standard practices that focus on standard interfaces. We document designs and keep functional models of everything in a repository. That tends to make reuse in a similar application quite natural. We're not selling our individual block IPs; we use them in the context of initial use. A very large percentage of our designs are highly leveraged -- very rarely is it actually used unchanged.

Joshi: There is another aspect that I wanted to add to that. We have a cookie cutter approach for making sure that we have identical machines with identical versions of OSes and patches and so on, so we very consciously, and through a lot of automation, avoid any diversion or change in configurations of these things. Having standardized configurations has helped us a lot in making sure that the tools run flawlessly. We're up running 98% of the time, 24/7 [hours] by 365 [days] at multiple locations.

EE Times: Somebody mentioned functional models a while ago. Do you guys have any standardized practices about behavioral or functional models at the beginning of design, or are those things that come along during the process?

Malachowsky: We start our next generation functional models by revising the last generation functional models. We try to get them as early as possible, and we use them to ferret out good ideas from bad ideas, and get early estimates. But as the design progresses we require our model to interface accurately with the hardware. Actually the performance of the functional model isn't required to be identical, but the transactions across the I/O boundaries have to be exact and accurate, and transaction for transaction accurate.

Maybe it's our best practice, I'm not sure -- but we try to restrict as little as possible the functional model from just getting the right answer. In our case we're doing whole algorithms and sub-routines within our functional block to send through the pipeline. We standardize our set of libraries, and C++ class libraries that allow for bit-wise accuracy, and conversions are done, so everything is very explicit when we're computing the value to a certain precision. Beyond making use of standard libraries, making use of standard function calls for floating point operators and so forth, and requiring a level of interface accuracy, the exact style within the product is not dictated as far as I'm aware.

Joshi: Let me add to that. We have, on most of our products, tried to standardize the coding styles, and they have been particularly useful when you have to come up with a synthesizable subset. It's also essential to do that early on at the very beginning of the project. Naming conventions, signal conventions, and all of that, especially with large teams, makes the overall integration much smoother down the road. You can also build in certain constructs that will help performance, so that when you're simulating, if you have conformed to the best practices, your simulation performance can be higher, too.

Fazeli: We actually are following two different models for two different types of businesses. In the vertical businesses, where there are a lot of customer engagements, we basically are going with the attitude of no compromise, customer-driven specific requirements whether it be in performance, power or density.

We start at out at a very high level of abstraction of providing models, and these models start out being very, very high-speed. They work themselves down into the implementation levels with a lot more accuracy. We have established checkpoints from system specification all the way down to implementation, where we will be providing different levels of models for functional verification.

On the vertical side of things, it's a different story. We basically are, again, based on the peripheral reuse strategy. We have documented models, and a modeling methodology that basically covers most of the items that the other two gentlemen mentioned with respect to interfaces. And the "plugability" that is being used for our catalog business, where the emphasis is on offering a wide breadth of solutions and functions in one single product.

EE Times: I'd like to ask a little bit more about verification, which as we all know is a huge part of the design process. Do you have some guiding principles behind your verification strategies? For example, is there a verification plan that's developed fairly early in design, and are there some practices that you maintain with respect to things like a particular level of coverage, or a particular methodology?

Fazeli: Test plans are a must as part of our peripheral IP development strategy. We basically have processes in place where they get reviewed by cross-functional teams of application product engineers and designers before we pass them on to the verification teams.

I would say that our objective is 100% coverage of the test plan. I think the issue is going to be, is your test plan going to be adequate enough? We're debating that but we believe that we have a good process in place right now. It's been proven on a number of different projects that we just went through, and so far samples and all the units are functional, so we haven't missed anything. In my opinion, the issue is going to be how good you do your test plan, and then it is measuring against 100% coverage of that test plan.

Malachowsky: I guess we also have a test plan here, and our principal goal is 100% test plan coverage. We supplement that with code coverage, not so much as it's 100% enforced, but just as a way of assessing the quality of the test plan and it's implementation. We're figuring out how to use code coverage most effectively.

You were asking about tenets of verification. One is that we will have an alternate model of everything we're building compared to our functional model, and we will validate the two against each other. It's easier in our application to validate it against the requirements of the product from a compliance and compatibility point of view. We also are never happy with just directed tests. We always end up with a pseudo-random and directed random set of cases to bolster our confidence. We're also actively pursuing lots of formal tool applications that aren't so vector, and human, biased.

The other thing is we end our simulation based verification almost 100% of the time in an emulation based world, where, again, we get the opportunity to run more cases. It gives us the chance to go in-circuit and take out the bias of a test bench or a test writer, and run real applications, as well as more extensive tests. Then we use that as a gate to declaring something functionally correct for tape out.

Joshi: We do all of the things that were mentioned by Mike and Chris, and again, verification is the most important thing that you have to do to guarantee that your chips are functional. We use test plans, which are there up front, plus we keep refining them; we cumulatively add all the known kinds of tests that we have learned from other processes. We have architectural models that we verify against RTL and gate levels. We do a tremendous amount of pseudo-random simulation. We do a lot of formal verification checks.

We have coverage tools built in, but you can measure coverage in different ways. You can measure by lines or by different constructs, and I think there's a lot more opportunity to actually improve on that space. We have added a lot of other formal tools for property checking, model checking and so on. You're never done with verification. You have to keep on looking for different ways to break the mold. How well you do that is really the name of the game, and we normally do it at the pre-tape out time. But even after it comes back there's a lot of verification that goes on.

EE Times: Has your accumulated experience so far suggested any generalizations about when is the appropriate time for vector-based tools, and when is the appropriate time for formal tools?

Joshi: We are actually using the combination, so I think that's a tricky one to answer in terms of how to generalize. There is a middle ground that we're looking for where we don't do brute force, where we can formally verify, but to only do simulation where we cannot formally guarantee something.

The other challenge with verification is that you may find that your RTL is okay, but your RTL for full custom design is translated to a transistor level circuit. You need to also make sure that the two are exactly equal. That's another interesting challenge if the silicon really isn't reflecting what you thought you simulated. We spend a lot of time on that as well.

Fazeli: I totally agree with Sunil's comments, and especially with the comment that there are lots of opportunities in verification. I do not believe we have the commercial solutions in place -- and we are just seeing the tip of the iceberg as far as the complexity and the issues that we'll be facing in functional verification. Unfortunately, I believe the vendors are reacting to the situation rather than being proactive, and as a result, there's a lot of effort within the companies being taken to develop solutions. There's a wait for the commercial availability of tools.

Formal methods are a good example. We've been involved with the model checking and property checking with the early releases of tools from the vendors, but they're just not where they need to be. They're maybe addressing one percent of the issues that we're having. Links to implementation from the system level, and system level verification, are not there. There are lots of opportunities that exist in that area of verification that we need to explore.

Joshi: At the very beginning of this conference call I mentioned that we have to architect for scalability and performance, and I think you'll find that with formal verification, it's a very interesting challenge. If you wanted to verify some property at a complex microprocessor or a multi-processor system level, I'm not sure the tools can deal with that and be able to deliver the result in a reasonable time frame.

Fazeli: I totally agree.

EE Times: Does that imply that eventually we may have best practices for architecture and coding styles to meet the needs of the formal verification tools?

Fazeli: We may.

Joshi: I think coding style alone is not going to do it. There has to be an algorithmic breakthrough. You have to figure out ways of breaking down the problem into multiple problems, and integrate back again, to figure out what's broken. So, I think it's a complexity problem that needs technical breakthroughs.

Malachowsky: The spirit of the question was, would we ultimately tune our approach to the tools that we have? I think that answer is unequivocally yes.

Fazeli: Yes.

Joshi: Yes.

Malachowsky: So, given the tools of today we would absolutely tune our approach for success, and efficiency, and quality of results, based on the tools that we have or we plan on developing in the near-term. Now does that say that you couldn't do better, that you're not going to evolve as new tools show up?

Formal tools represent a really interesting supplement. They're not a replacement yet, but an interesting supplement. It represents progress that's hard to get when you're writing the individual vectors, and biased by having this clock versus that clock. I think maybe equivalency checking is the closest to maybe relieving you of some other efforts, but as an industry, we're trying to figure out what the best practices are, given the state of the art of the stuff.

The fact is formal verification tools are evolving, while simulation and vector-based tools really aren't. They get faster because the platform gets faster, the code gets a little better tuned, but we're trying to find the best practices in a world that now has access to model checking, and property checks, and that type of stuff. So, the spirit of the question is will we tune ourselves? Absolutely.

Fazeli: If I may, just a comment, Chris. I agree with you, but due to the gaps that exist with tool capabilities we are forced not only to change our methodologies, but also invest in developing tools that we could otherwise put into some other development activities internally. When we're looking for capabilities that are driven by our design complexity, the first thing that we ask ourselves is whether a commercial tool is available. Basically, if we cannot either find a solution or identify a vendor that will partner with us, and develop that capability, we will have to invest in tool development.

Malachowsky: If there's one overriding best practice that I bet everybody would agree to, it is, don't let anything stand in the way of success. So if you think of a way to move ahead, to overcome whatever the obstacle is, you're going to make the investment, whatever it is. But you want to succeed in as highly a leveraged way as you can.

And if that means buy tools, I go out and buy tools; I'm not cheap. In the procurement of tools, you don't want to bear an expense, but then I'll make an investment, and if it's an investment in my future and my success, then it's justified.

EE Times: A couple of people have mentioned needing algorithmic breakthroughs and formal tools. Is the problem now the capacity of the tools? Or is it that they're unable to analyze designs, or is that they get the wrong answers?

Joshi: No, it's the capacity of the tool, the depth of the search, and the explosion of the data as you look at the cone of logic. It explodes as you try to prove formally whether some condition is true or not, and to be able to deal with that you need algorithms. As well, it's a partitioning problem -- how can you break down that thing into multiple threads?

Malachowsky: The fact is that most formal tools have now just gotten over the hurdle of usability. The average, smart, savvy engineer can take on a lot of these tools, whether in house or vendor provided, and make headway with them. The focus now has the opportunity, I think, to shift more to capacity, and a lot of applicability, now that the basic usability hurdles are over. There are some tool types that seemed to have caught on, like the model checkers and the vertical checkers.

Joshi: Yes. So we'll wait for the next wave.

Fazeli: At least you can keep the tools running.

Malachowsky: At least I know how to run them. I can't say how many books on formal stuff I read, and didn't understand a word.

EE Times: I'd like to at least touch on physical design before we go. I'm curious if you have developed some practices for bridging the gap between logical and physical design, and if there perhaps some practices you've come up with in placement and routing, extraction, and analysis, all the way through to getting to the tapeout.

Joshi: I think the physical design practices are at least as important as the front-end practices. You can start with your basic circuit design, such as topology rules, and make sure that if you have dynamic logic it looks the same in different parts of your chip or in different chips within your organization. There can be other little things you can do, which can all add up. You know, making sure that you have the same numbering, or that your rule check files look the same, or that your color coding on your schematics or layout or whatever are similar. So there are little things, there are big things, they all add up.

The other thing I wanted to add here is that sometimes knowing what to do with respect to best practices is good, but I think making sure that it becomes a part of the DNA of the entire organization is the real trick.

Fazeli: I think we've made a lot of progress in as addressing the gap between logical and physical with the introduction of a lot of new tools within the last two or three years. But I think we still fundamentally are spending a lot of time trying to calibrate the front-end tools with the routing tools from a timing closure perspective.

I think we will be able to address this, finally kill this beast, if we move to single timing engines. Now I'm not really referring to a streamlined tool capability where some of the vendors are offering a push -- you know, RTL all the way down, and you get GDSII -- but I'm basically referring to trying to converge on the timing engines that are being used in the front-end logical design, and the physical design.

Malachowsky: We have best practices that span the gap. We're more of an ASIC oriented house. Layouts for 70 million transistor chips take on the order of ten to twelve weeks, and we make some compromises. What we've done is we've burdened the logical netlist structure such that the issues that we used to see in the back end don't show up now.

Now we're not going to get a GHz, like a processor guy might. We're running at a couple hundred MHz, and that's a compromise we're willing to make, so we've bridged the gap by almost over-constraining the net list to avoid physical problems. The best practices in the back end are not only the circuit ones that were mentioned, but also a strict adherence to a checklist oriented flow so that you don't miss anything. An automated checks of logs, and consistency of versions, and everything with version control. That's actually an innovation from a few years ago. Since the files were so big, we just didn't want to deal with it.

EE Times: Everybody has mentioned doing things in the front-end as best practices for making sure the back-end goes well. This sounds like a really dire message for those COT design teams who farm out the physical design to a service company.

Malachowsky: Well, I'm not so sure it's dire. It just means somebody works harder or you compromise. You either set targets consistently, or you work harder to achieve them, or you end up compromising some when you see the reality. You know what the back-end results will eventually be, and you can bias yourself so that you're not so surprised. I don't think it's dire. I think you end up dealing with it hopefully beforehand, rather than later.

Joshi: There's actually one more dimension to this as well. We are looking at it as front-end and back-end, but really there is a life to the product, which could be a number of years, or a decade. In those cases you need to have best practices that ensure that you have a robust, highly reliable product, not something that just runs initially. There's a lot of best practices relating to DFT, or Design For Test, with respect to reliability, to yield, and electro-migration -- they all go into the design process.

Malachowsky: You're absolutely right, but even that's very specifically silicon based. These things go into a system of some sort, and before that system can be introduced, there's a whole lot of things needed to ensure the product's life.

EE Times: We're getting to the end of our time here. If I could ask just one more question, I'm curious how well commercial tools support your best practices, and if there's any particular thing that EDA vendors could do to support your best practices better.

Joshi: I see the best practices as orthogonal to the tools. I think you need to come up with best practices that don't necessarily rely on the tools. To me, best practices is a design discipline, and making sure that you're doing the right things, in spite of the tools. I see those as two orthogonal issues.

Malachowsky: I both agree and disagree with Sunil some, but it's really the context, and where you're applying it. One of my hot buttons is something the tools could help support, and it's a multi-vendor issue. I think consistency is a good way of getting things right, and if there's ever a place you have to specify some piece of information, data, constraint, or requirement, I'd like to specify it once, and have everybody operate from that.

The tool environment that we're in, even with tools from the same companies, requires us to specify similar information multiple times in multiple ways. I think our best practices would involve a lot less internal CAD development if we could have a single industry-supported way of specifying whatever that "something" is.

Fazeli: Without a doubt the tool capabilities force the design methodologies that we use, and based on those design methodologies we've come up with our best practices. I'd also like to echo back requests to the EDA vendors to standardize on interfaces. I think we need to have that capability so that we'd be able to be more flexible on our use of the tools, and the design methodology that we put around them. And also being able to be more flexible as far as bringing point solutions into the overall design environment, and integrating them, and having more flexibility on the choices of the tools that we have for any one given solution.

EE Times: We've reached the end of our time here, so I'd like to thank each of our panelists for all of your very insightful answers.