By Ed Sperling
System-Level Design sat down to discuss where the hidden costs are in design with Ran Avinun, marketing group director for system design and verification at Cadence; Ken Brock, senior product marketing staff member at Synopsys; Kalar Rajendiran, senior director of marketing at eSilicon; Bo Gao, new product program director of design technology at Cypress Semiconductor, and Bob Smith, vice president of marketing and business development at Magma. What follows are excerpts of that conversation.

SLD: Where are the hidden costs?
Rajendiran: Many of the costs are hidden these days because of all the disaggregation. You can purchase many of the components for an SoC and you can even negotiate the lowest cost for that particular piece. But when you put it all together there’s a lot more needed to get a product out on time, with confidence that it will work, and still keep the total cost of ownership low. The problem is that when you buy IP from multiple suppliers that may not integrate that well your schedule may be delayed and you may not be able to close timing. These are problems that may not be accounted for by a project manager today. This is a big shift from the past where all the pieces came from the same supplier. All the EDA tools were homegrown. You had the IP, the process, and the tools so it had to work. You need to account for those costs up front before you start the project.
Gao: One of our challenges is logistics. I have teams spread across different locations. If I have a problem here in San Jose it will take me a minimum of 12 hours to get someone on the phone in India to talk about it. And then when I do get the answer, it might not answer what I meant. That’s one of the big challenges –dealing with teams globally. From an EDA tool issue, stability is a big problem today. Instead of just working on designs, I’m fighting tool issues almost every day. The worst problem of all is a tool crash because you can’t even debug that. You have to go back to the vendor to deal with it. You have to prepare a test case, take that back to the vendor and hope they can come up with a workaround. It usually takes a couple days. That isn’t something in the project management costs and it’s very unpredictable.
Avinun: In the past the focus was around IP creation and process innovation. These days there are more and more companies outsourcing their IP and outsourcing their fabs. The game is changing. The key cost is hidden in integration. That’s integration of multiple IPs into an SoC, it’s integration at a system level of hardware and software. It’s also the ability to integrate beyond silicon to the overall system. And it’s the ability to move from specification to RTL and eventually to implementation. Those are the key challenges, and in many cases companies are not dealing with those costs up front. The worst case is when you discover those problems late in the process. If you discover it a week before tapeout you can still recover. If you discover it two weeks after you get silicon back it’s starting to stretch your ability to recover. If you discover it when those devices are in the field, it can be a disaster.
Brock: Those are all hidden costs, but one of the biggest costs is coming out with non-competitive products. A lot of our customers are at the bleeding edge. At 40nm we have 40 customers working there and those processes are finally stable. We’re working at 28nm now. You have to have a long lead time to say, ‘This is the product and the spec I want to hit.’ It may be six months or a year before a product comes to market. But you need flexibility to deal with the changes and specs and standards. Some standard interfaces may change and you’re trying to tape out where the puck is going to be, not where it is today. It’s the Wayne Gretzky scenario. At the same time, you have to deal with the process. The process is changing. If you get to the finish line and you have the wrong power, performance, it’s a cost. There will also be people coming and going on the design team. You need to manage that change with flexibility to prevent hidden costs.
Smith: If you look at the ecosystem you’ve got designers, semiconductor providers, fab guys, test guys—there are a ton of moving parts. The automation tools are supposed to be there to make the job easier. The reality is that it’s not always the case. You may even go through a period where you ask yourself, ‘Why am I doing this? I’m trying to get my tools to work’ One of the big hidden costs is we’re developing products and the target is always moving. Design rules change, guidelines change, libraries change. We’ve got a process that we thought was nailed down and we just discovered this effect so now we’re going to change the rules. That affects the EDA tools, which are software trying to keep up with the changes. This is a very entropic system. The other point I’d like to mention is that we’re getting all this rich IP. There are a few standards out there. If you think about a PCB, most processors and memories come in well-defined packages. You know how to drop it into a board. That’s really not the case with a system-on-chip. People spend an awful lot of time trying to develop and verify these interfaces. There also are hidden costs in up-front planning. Chip design is very time-consuming. If you start with a bad plan and you find a problem, working your way back up to fix it is really tough.

SLD: How much of the unexpected cost comes from engineers used to doing things a certain way even though that may no longer be the best way to do it?
Rajendiran: If you look at characterization corners, there are a lot of corners at 90nm for things like temperature inversion. For many generations in the past people said that when temperature rises things are going to slow down. That’s not the case. If there’s something new and you miss the market window. If you miss that window by six months you lose x% of the profit. Add to that the complexity of the design chain. And even though companies like Cadence and Synopsys and Magma are doing a great job with tools, every company is different. They exercise different corner cases. You can’t have someone who just knows how to use a tool. They have to know how to use it well and know the intricacies of that tool. They can think slightly differently as things change and put the tools to use differently. This is harder now that it’s global and teams are all over the map. In our business, it’s important you don’t just find the lowest cost. That doesn’t always work. Those teams are not always working on the same time zone or the same plane. Things you can parse off to a time zone ahead so they’re working while you’re sleeping has its place. But there’s also a place for doing it in the same time zone. You need to be close sometimes. It can be a huge hidden cost.
Avinun: The main penalty is opportunity cost. Companies wake up when they find out they’ve got a disaster at the last minute.

System-Level Design sat down to discuss how to fix what’s broken with John Bruggeman, senior vice president and chief marketing officer at Cadence; Charles Janac, president and CEO of Arteris; Robert Hum, vice president and general manager of Mentor Graphics’ deep submicron division; Mike Gianfagna, vice president of marketing at Atrenta; and Bob Smith, vice president of marketing and business development at Magma. What follows are excerpts of that conversation.

SLD: Customer complaint No. 2: There are not enough tools around the edge, but the problems are now larger than what a startup can provide. How do you solve this?
Bruggeman: There are dozens of examples, but the economics don’t work. If you look at the birth of EDA, the semiconductor companies did everything, took a look at it, realized it was non-differentiating, and they spun it out. It doesn’t make sense for the EDA vendors to do it so the semiconductor companies will have to fund it. It’s the penalty for creating the EDA industry the way they did. But ultimately they’re going to spin it out and we’ll take it on. By then it will have enough maturity where it makes sense for us.
Hum: There might be some lessons out of the FPGA industry. There are a small number of players that dominate the market. They do their own place-and-route and they have their own tools. It seems the way the industry is heading there are some big players. TSMC may say for everyone who needs a standard flow that they provide one. Maybe they provide the tools, maybe they buy an EDA company. Maybe you pay for it when you produce so many chips.
Smith: The FPGA guys drove it to the point where the tools are free.
Hum: The tools are not free. They’re included. That’s a royalty model. But if things go the way they’re going, that could be one of the end points we end up with. Maybe the box standard flow comes from TSMC and GlobalFoundries.
Bruggeman: If they did that, it would be the end of the EDA industry.
Hum: It would. The ASIC industry got out of doing their own EDA because it was cheaper to use common stuff than their own proprietary stuff.
Gianfagna: If TSMC buys EDA, then we’re back to IDMs again and it will be time to spin it out in a few years. It’s a cycle. But you’ve re-created where it all started.
Bruggeman: It might not be a bad thing, but what will happen is a couple of smart EDA companies will see the industry is under massive change. We need to re-invent ourselves. Where is the new value we provide? I will argue it’s in the systems space. The same sort of solution set we provided to the ASICs and IC guys we can deliver to the systems guys, which is not anywhere close to where the TSMCs or foundry guys can play today. It is very conceivable that they could acquire an EDA company and define the flow and EDA as we know it is gone. What will happen is some other EDA companies will be very shrewd and say the next solution set is further up the stack. They will be solving a very hard and complex problem, which is not a software problem but an integration of hardware and software. And then there will be a much bigger industry.
Janac: The problem is that if the industry doesn’t make that leap it will continue to stagnate. It won’t grow, and it may shrink. There have been industries that have shrunk because they didn’t offer the customers value. The question is what’s the innovation people are willing to pay for? They’re not willing to pay for test. They’re not willing to pay for specialized hardware. But there are things people are willing to pay for, and those segments are going to grow.
Hum: The current problem we’re solving may be commoditized. We get to solve the next problem. Innovation is what drives this industry. Technology is not stopping. Von Neumann architectures are not the future. It’s all multiprocessing. How do you help people exploit multiprocessing? Things aren’t getting faster. They’re getting parallel. The software industry hasn’t done such a hot job solving this problem. There’s a whole other architectural side of the world that many companies have been reluctant to let go of because their architects are the smartest guys in the world.
Gianfagna: Maybe there’s a re-learning piece here. How good are we, as an industry, at finding new customers and selling to new customers? We have an abysmal track record there. We’re not willing to try to understand a new problem and adapt our sales. It’s a more difficult version of the same problem at 28nm vs. 180nm, and it’s the same people buying the tools. If you look up the stack at the people building the software, those are our new customers. They talk a different language and they have a different culture.
Hum: They also have a different perception of value.
Gianfagna: That’s an opportunity. We messed it up the first time.
Janac: The question is how you make a $400 million business out of a low ASP. It fundamentally operates on different dynamics than the EDA direct sales force model.

SLD: The customers say they have the EDA industry they’ve paid for. They also say they need lots more standards. And they say there’s an assumption at this point that they have to do the integration.
Janac: It has to be done, and every PCB maker integrates their PCBs. But they do it with standardized components using standardized software. It’s like building a castle out of Lego blocks. You can build it out of Lego blocks, which is what most people do, or you can carve the blocks yourself and build a castle. What they’re doing now is carving the blocks and building the castle, and it takes more money, takes more time and has more errors. We need to provide a platform on which this innovation takes place.
Gianfagna: How much standard infrastructure do you need to make that work from an industry level? And where are we today? It’s a big change.
Janac: One of the things that made Cadence was a language called Skill. Everything was standard about Cadence except for Skill. It allowed people to write features on top of the Cadence software without going to Cadence. You wound up with hundreds of thousands of lines of Skill code at major IDMs. Everything else was standard but this was sticky. I would say it was to the benefit of the industry the way Microsoft Office benefits the software industry. You can go anywhere in the world, fire it up on any system, and it works. Skill would work on any system and it was a marketplace standard. It was the same with Verilog. These standards have to be set, but they cannot be legislated. They have to be established by a powerful company behind them that manages to get it adopted on an industry basis. While Skill benefitted Cadence it also benefitted the industry.

SLD: The business model of the whole industry, coupled with disaggregation, are causing problems. For a company like ST, they can fill in the pieces and write their own tools. But is that the future.
Janac: ST also loses money, which is not a good model. So the question is how much of an R&D footprint do you want to have? That’s decreasing, which is why the industry is disintermediating.
The market decides. The question is what is your core value.
Gianfagna: One of the ways MediaTek became popular is they sell both hardware and software. And they sell into the Chinese marketplace like mad.
Hum: They also don’t take on new things.
Gianfagna: But they level of integration they provide is a value add.
Hum: They do cost reductions.
Gianfagna: It’s not just cost reductions.
Janac: I disagree. Saying someone is an innovator and a copier is misleading. When they get profitable they begin to innovate.
Bruggeman: I would argue they are an innovator now. They have a level of innovation we don’t associate with.
Hum: That’s cost innovation.
Janac: But their path to getting bigger is functional innovation.

System-Level Design sat down to discuss how to fix what’s broken with John Bruggeman, Senior vice president and chief marketing officer at Cadence; Charles Janac, president and CEO of Arteris; Robert Hum, vice president and general manager of Mentor Graphics’ deep submicron division; Mike Gianfagna, vice president of marketing at Atrenta; and Bob Smith, vice president of of marketing and business development at Magma. What follows are excerpts of that conversation.

SLD: One of the top issues for customers involves co-design—lack of tools, lack of standards and lack of communication. How do we solve that?
Janac: We don’t, and here’s the reason: We’ve been whining about the EDA problem, but when you get up into the software world it gets much worse. You wind up with the ASP (average selling price) of a software tool being in the single-digit thousands. As much as we mind the ASP of EDA tools being in the tens of thousands and IP being in the hundreds of thousands, none of us are geared up to compete with our distribution channels and the support mechanisms in the single-digit thousands for tools, no matter what the volume is. Until the customer institutionalizes that the software is a huge amount of cost and that the reduction of that cost needs to be funded—this is a cultural issue, actually—then we’re going to have a worse problem than EDA has.
Hum: There is a problem in the semiconductor industry. Richard Beyer (CEO) of Freescale said he can’t deliver a chip without software and the software costs way more than the chip, but the buyer measures the chip and says this is what he’s paying.
Bruggeman: You’re hitting on a key point here. You talked about our joint customers are consolidating us out. The real issue is their customers are consolidating them out. To differentiate between one chip and another is virtually impossible these days unless you can get at that software layer, and the only way the chip manufacturers can truly differentiate themselves sustainably over time is through the software they deliver. The reason is that software is sticky.
Hum: Their customers are forcing them to create a software layer that has a standard API on top so they can go to another vendor and get the same chip.
Bruggeman: But that instantly commoditizes them. Once you standardize that software layer you’ve reached the lowest common denominator. Then you don’t get to call out any of the differentiating features of the hardware.
Hum: That’s what the handset guys are doing to the hardware suppliers.

SLD: How do we fix that?
Bruggeman: So if I’m a chip guy and I’m looking downstream at my EDA guy, they don’t get to differentiate so I want the same thing from my EDA vendor. I want co-design, standards and APIs so I can design the EDA vendor out anytime I don’t get the right pricing or a customized feature. If we in EDA don’t solve the higher-order problem we’ve relegated this industry to its own self-demise.
Hum: There are some examples where standardization helps. On one side, it helps to commoditize. You can swap out one tool for another. But every time the EDA industry has standardized something, that becomes the platform on which further innovation takes place. Before Verilog as a language showed up there were a zillion mediocre simulators. All of a sudden you had linting tools, ways of getting your netlists massaged and you had optimization tools. Once you didn’t have to write 15 parsers, we were able to reduce our costs. The latest standard that has helped is System Verilog. That has brought some fresh air into verification methodologies. Now we have to figure out what we can add.
Gianfagna: At one level you have to embrace that and see what you can add on top. If you try to avoid it so you won’t be designed out then you’re stuck. But that’s easier said than done. There aren’t enough financial resources in the industry to do that.
Smith: The heavy lifting is all in the software. At some point in the future it will be a pretty small club designing some pretty powerful chips surrounded by tens or hundreds of thousands of people writing the code. Once the chip is stabilized there will be a ton of verification and emulation.
Bruggeman: But if we all have to feed off of five or six guys that’s not sustainable. In addition, you have to wonder what happens to the other 300 companies because Moore’s Law doesn’t work for them. What’s going to happen is transformation of the value they provide. Rather than creating chip technology or chip IP they’re going to become integrators. They’re going to create only the IP that differentiates them. The rest is all re-use or integration of existing IP. Where EDA must innovate is in the area of integration. We provide horrible tooling for the other 300 companies. Companies like MediaTek have shown if they can be the best integrator they can be wildly successful. How do we tool up the Freescales and TIs? That’s a big opportunity.

SLD: But it’s more than just the software and the hardware, right? It’s also things like packaging. And the IP has to be thought about across the design and even across chip boundaries and geographical boundaries.
Hum: I just met with a medical company that integrates mechanical, chemical, electrical and physical.
Janac: One of the things happening to the customers is that companies used to doing all of their own IP are starting to focus on their commercial advantage.
Bruggeman: That makes a business for you.
Janac: And networking techniques are the best way to absorb this IP and integrate it. One of the things that mystified me was that at the architectural level the play is really the integration of IP and tools. The ESL market is a plant that is being watered year after year after year. It never grows and it eventually gets run over by a train. You have to let the customer adopt a PCB-type of methodology at the IC level. The other innovation is you want to expose the software stacks at the SoC level so you offer not just the hardware but a couple levels of software IP that get integrated at the software level. The EDA industry has done a miserable job of delivering on that even though that’s what the customers really need. Their margins no longer sustain writing all the software themselves.
Bruggeman: We’re focused on creation and not integration.
Hum: And I only want to pay $99 for it because that’s what the Microsoft suite costs me.
Janac: When you offer true value to someone they’re willing to pay. It’s only when you offer something they don’t want that they won’t pay.
Hum: I don’t think that’s true. People get trained for what they’re willing to pay. Ikos Systems had a simulator that ran 1 million times faster than a digital logic simulator. It really solved the problem. If you want to simulate your software stack on that it works great, too. The hardware guys will pay for that because they’re conditioned to pay for it. The software guys won’t.
Janac: We need to extend into the software stacks. They’re not used to paying for this, but their problems are becoming bigger and bigger.
Bruggeman: That’s not totally true. I come from that world and we sold open source software.
Janac: What was your revenue?
Bruggeman: $400 million. For free software we did pretty damn well. The customer was conditioned to not paying anything for open source. Yes, you have to re-train the customer and that’s non-trivial. But you have to tie your business model to the value of what the customer is getting and we don’t do that. We want this panacea of delivering the same value and we’ve lost the link between what we charge and the value the customer receives. We have to tie the value to the pain the customer is feeling, and that clearly extends into the software space. This is a huge challenge for us. Most of us can’t spell software.

By Ed Sperling
System-Level Design sat down to discuss how to fix what’s broken with John Bruggeman, Senior vice president and chief marketing officer at Cadence; Charles Janac, president and CEO of Arteris; Robert Hum, vice president and general manager of Mentor Graphics’ deep submicron division; Mike Gianfagna, vice president of marketing at Atrenta; and Bob Smith, vice president of of marketing and business development at Magma. What follows are excerpts of that conversation.

SLD: We’ve already sat down with your customers and asked this question. But from your standpoint, what do you think is broken in EDA and what needs to be fixed?
Smith: There’s a lot of good stuff out there, but there also are a lot of issues. One thing customers will say is the business model is broken. I’ve had more than one customer tell me they take they take their best shot at getting a chip out, they put in a lot of resources, and if they’re lucky at the end they get some return. With these tools we want to be paid up front. They say we don’t have any skin in the game and that we need to re-think the model and take the risk. But at the same time, customers are not saying they’re willing to offer royalties.
Hum: We had that happen with TestKompress, the DFT compression tool. We said, ‘We think we add a lot of value in the back end with our tool. We’ll give that to you for free if we get a portion of the money you save.’ I didn’t get any takers on that. They like the free part.
Smith: The other thing that’s tough is we’re always chasing a moving target. Unlike Microsoft Word, which has reached some level of maturity, at the leading edge things are changing all the time. You’re never going to have a piece of software that’s bulletproof.
Bruggeman: I think the industry has gone through a disruptive transformation. Everything has changed and EDA has not responded to the change. We continue to move forward as if it’s business as usual. The problems we’re solving got a little bit harder, but they’re basically the same problem. We are massively missing the fact that the industry has turned itself on its head. It used to be that hardware was king and you designed the chip and the chip mandated how everything above it would work or how it wouldn’t work. That has changed. Now you differentiate yourself on the application and software and the software dictates how the hardware works. That will define different tools, different processes, different rules, and it will completely change what we have. Until we’re prepared to deal with that we’re going to be the same $4 billion industry we’ve always been.
Hum: The industry has changed, but I don’t agree with that. The hardware has a complexity that is more than just a little more complex. At 45nm and below that brings lack of design closure. Hardware will still be king because that is the tangible platform that gets manufactured. The problems at 45nm and beyond are non-linearly complex. The fundamental problem is that EDA companies are not treated in partnership with the industry. More and more we deal with purchasing departments rather than engineers. They buy the simulator for the lowest price and don’t even want to pay for it. We are no longer in partnership with how our customers are defining their design methodologies. The industry will continue to unbundle. Specialization is still needed. There are spinouts of functionality, but I get the feeling we haven’t created a cooperative ecosystem. Software does need to drive more things, but that’s not enough.
Smith: There is a mentality that it’s all the same. It’s a numbers game.
Bruggeman: Until we deliver something of value what’s the motivation of our customers to partner with us? We all give roughly the same thing. Why wouldn’t it come down to price?
Hum: But it begs the question of how we got there? Did we decide as an industry we to commoditize ourselves, or did the industry commoditize us? It’s clear our customers have consolidated us, whether we like it or not.

SLD: Cadence and Mentor are welcome to slug this out, but first we need to hear from the others.
Janac: Back in the late 1980s, the curve constructed for the SDA showed that every tool we made was going to be commoditized. Schematic capture was going to go from $30,000 per seat to $6,000, full custom layout was going to go from $80,000 to $12,000, and place-and-route was going to go from $100,000 to $40,000. The only way out of that was to keep on introducing new tools. Cadence executed brilliantly on that by buying up new technology and the average seat went from $60,000 to $300,000. It’s always going to be like that. The problem is that the rate of new tool introduction has slowed down to the point where this commoditization is driving the price down. People are willing to pay money for unsolved problems, but the basic core of the EDA flow is considered to be working and commoditized. One of the new problems is that the hardware has been static in terms of cost and that the increases have been in software.
Hum: The hardware NRE has been lower.
Janac: Yes. But the issue is the customers are trying to figure out how to stop the runaway costs in the software. But it’s not just software. As Apple has shown, you can manage the cost of the software by having an integrated strategy between hardware and software. There are companies with libraries of software and they need to modify the software for the hardware. Those people have done well. That’s one of the things that’s wrong with EDA. We have to look at what people are willing to pay for. Another thing that’s wrong involves Moore’s Law. At 28nm the power isn’t that much lower, the performance isn’t that much higher. The only thing that’s better is density. The customers are used to decades of massive improvements, and now they’re trying to figure out how to take the money out of the supply chain because they’re getting less. It isn’t there. They’re having trouble because their customers are expecting quantum leaps. Those factors are causing serious difficulties. The only way out is serious innovation.
Gianfagna: We all say we don’t get what we should for the tools, so the value has never been established. If you go back to the beginning, this is an outsource business. The people who used to write the tools lived inside the big companies. Then they formed these standalone shops and the buyer said they’d pay a little more than if they built it themselves. The buyer wasn’t willing to talk about what it cost to make it. But it’s like selling a car to a master mechanic. It’s different than selling to the average consumer. All of our customers are like master mechanics. They pegged it at just above what it would cost them, and assumed that would provide enough for everyone else to survive. That was the starting point. Then all of us decided the way we win is to get the budget and move on. The way to do that was throw more software at it. No one tried to lift themselves up after that. That’s the problem. You can talk about the fact that we don’t innovate, we don’t solve new problems and we don’t go to the next level. But you need money to do that. That’s the box we’re in and we have to figure out how to climb out of it.

By Pallab Chatterjee

With advanced process development occupying the 32nm to 22nm corridor, production SoC and ASIC designs are being built at the 180nm to 45nm nodes. In these processes, the designer has to contend with cross-wafer variation and non-correlated design corners, as well as multiple operation states. This is referred to as multi-corner multi-mode (MCMM) and variation analysis. And at the 45nm node, all of these analyses become mandatory.

To address the updated design flows for the 180 to 45nm process, static timing analysis (STA) is used to set up the system-level criteria for block-based IP that makes up the chip. This area has received updates on STA tools in the past few years to make them adaptable to the new processors and machines.

Mentor Graphics was one of the first to introduce a fully automated analytic solution with the inclusion of the MCMM capability that was part of the Olympus SoC Place and Route environment. This product was introduced supporting both distributed processing and multi-threaded/multi-core capabilities for handing large designs. Synopsys, around the same time as Mentor, introduced the VX extension to its industry “gold-standard product” Prime Time. The product likewise was introduced supporting multi-core/multi-threading and distributed processing for faster throughput. Both of those products maintain their accuracy while significantly updating performance and automation. The tools are utilizing a licensing model that is different from the standard one, so the MCMM analysis does not require a license for each corner simulated.

To address the needs of the new processes, there are number of multithreaded single-machine, single-license STA tools on the market that replace the function of distributed processing of multiple simulations, one for each corner or mode, on a different machine requiring a separate license. The capabilities of these new tools are targeted at embedded controller and embedded processor applications that have a very large state space. These tools, from Mentor, Synopsys and, now, Magma, automatically perform static timing analysis over the full design space and dump the results into their respective databases, without the new user starting the runs for the individual corners and correlating the results.

Device-level simulation has changed and now requires them to be multi-threaded and multi-core aware. HSPICE, Eldo, Spectre, and SMARTSPICE have been on the market for several years and have recently been joined by the FineSim simulator from Magma. These tools identify the corners of the MCMM space and then perform a reduced number of simulations to cover the space based on algorithmic determination of what are relevant points in the design space, rather than traditional Monte Carlo variation analysis. The reduced space is more representative of the realizable corners in the process, and produces results, of the same accuracy, significantly quicker.

Other simulators supporting a reduced design space simulation environment include HSPICE and SMARTSPICE. Solido Design Automation has variation analysis engine that supports Spectre and the Berkeley Design Automation Simulators for the reduced state space analysis. The Solido tool is built around a visualization environment that not only drives the simulations for a reduced simulation space, but uses active trend identification to help steer the design toward a targeted specification.

All the main players in EDA now have tools to address the automated design verification of MCMM design applications. The new process technologies no longer have simple correlated design corners (fast, nominal, slow). Instead, they have uncorrelated device model properties with global process and cross-wafer variation. In order to signoff on designs in these processes, (65nm and below), Monte Carlo or advanced variation analysis are the only methods to understand the design.

Mentor Graphics introduced a tool for thermal characterization for semiconductor packaging and design, which has become essential as density on an SoC continues to grow, along with both active and static power leakage. The new FloTHERM IC solution is a Web-based platform that simplifies many of the characterization and validation tasks.

Rumors of Magma’s death appear to have been overstated. The company generated revenues of $31 million for its fiscal Q3, ended Jan. 31. It had a net loss of $2.6 million, but when you compare that to a net loss of $78 million in the previous year—not to mention that the company beat expectations—things are definitely on the upswing. Revenue is expected to be relatively flat over the next quarter. Like many EDA companies these days, proof of success will be the bottom line, not the top line. Magma says it has positive cash flow.

Intel Capital and a group of 24 VC firms pledged to invest $3.5 billion in U.S.-based technology companies over the next two years. Intel’s share will be $200 million. In addition, a group of 17 technology companies ranging from Intel to EMC, Cisco, Marvell and Broadcom said they will increase their hiring of college graduates—some by doubling their hiring over previous years—to sustain the market for future scientists and engineers. This is very good news.

IBM put a green spotlight on the lithography process, creating fluorine-free photo-acid generator compounds that are used to transfer patterns onto wafers. Green is good, and in IBM’s case it’s also the green that comes from licensing patents.

TSMC is collaborating with Dialog Semiconductor on a bipolar-CMOS-DMOS technology that can improve power management in chips for portable devices. Dialog, in case the name doesn’t ring a bell, is based in Stuttgart, Germany.

GlobalFoundries Singapore—the company previously known as Chartered Semiconductor—announced a tender offer for any and all of its senior notes due in 2010. Consider this yet another step in a complete takeover of this foundry by ATIC, the Abu Dhabi-based investment powerhouse.

By Ed Sperling

Mentor’s Dennis Brophy pitches the benefits—and long list of disciples—of OVM. In case you’ve forgotten, OVM is a highly compatible verification environment with VMM, whose supporters also pitch their own verification environment’s benefits. Funny how that works, isn’t it?

Need proof? Check out the blog from Synopsys’ Varun S. Verification Martial Arts. There’s lots of detail about Datastream Scoreboard Iterators, which is important in the VMM world.

Cadence’s Jason Andrews takes a look at models and what engineers really need to know. Hint: Not everything is being modeled, and it doesn’t look like it will be anytime soon.

John Cooley sheds some light on Magma’s super-secret project called Tekton and what’s behind all the whispers. It’s a fine piece of sleuthing and putting together pieces of a puzzle.

Harry Gries, aka the ASIC guy, takes a look at all the ways to use engineering terminology to optimize them for search engines while combining it with a grade school writing assignment. This is so far out there that it’s definitely worth a look.

Speaking of strange, why is GlobalFoundries exhibiting at Mobile World Congress? Daniel Nenni has a point there—and a good explanation.

You’ve heard of inline skates. But how about inline code? Mentor’s Colin Walls lifts the covers on ways to improve performance by reducing the amount of software. This is always welcome advice.

Cadence’s Richard Goering looks at a DVCon presentation by Brian Bailey that should be of prime interest to a lot of system-designers, namely how to get high-level modeling into a real flow. This is an important topic, and Mr. Bailey deserves a pat on the back for suggesting ways to fill in the gaps. Now if only the RTL folks would starting using this stuff. This is a nice reporting job, too, by Goering.

And if you’ve attended DVCon this year, you might want to know how this compares with last year. Synopsys’ Karen Bartleson is offering some upbeat news—and it’s about time. Although if you’ve been driving in Silicon Valley lately, you’re probably aware that the traffic has gone up again, and it isn’t just road repair projects funded by federal stimulus dollars.

By Ed Sperling
System-Level Design sat down to discuss the future of synthesis with Shawn McCloud, product line director for Catapult C Synthesis as Mentor Graphics; Chris Eddington, director of marketing for system-level products at Synopsys; Bret Cline, vice president of marketing and sales at Forte Design Systems; Sanjiv Kaul, executive chairman at Oasys; and Andy Biddle, director of business development at Magma. What follows are excerpts of that conversation.

SLD: Why is high-level synthesis, which has been around for awhile, suddenly so necessary?
Kaul: In the typical chip there are multiple physical partitions. It can take a typical design team 15 hours to get through the logic synthesis portion and a week to two weeks to get through physical implementation—per block. And it can take multiple iterations through that loop. Some design teams go through that loop seven to 10 times. They’re looking for ways to get timing closure much faster, and the only way to do that is to bring physical information up earlier in the process.
Cline: That’s not the only way. High-level synthesis guys can make much better tradeoffs into the RTL schedule before it even hits a logic synthesis tool, which can eliminate a huge class of timing problems.
Kaul: You’re still dealing with RTL after that.
Cline: I agree, but we own the schedule. So if the schedule gets filled up and you go through synthesis place and route and don’t meet the timing, you can go back through the high-level synthesis tool and change the schedule. You just can’t do that in RTL. We can make the flow smoother by allowing people to not make stupid decisions in the creation of that RTL.
Eddington: That’s one of the big advantages of high-level synthesis. You iterate quickly at the architectural level and you minimize the iterations that you have to do for back-end place and route.
Cline: You should never miss timing with high-level synthesis.
Kaul: It’s not so much a question of missing timing closure. It’s how long it takes you to get there.
McCloud: High-level synthesis allows you to get to timing closure more quickly. Let’s say you’ve hand-coded an architecture that completely misses timing. The time it takes to re-code , especially if it’s a significant architectural change, could be weeks to months depending on the complexity of the design. With high-level synthesis it’s easy to adjust the percentage that you’re reserving for placement and reschedule the design. And what happens when you have a spec change late in the design? That’s a nightmare to deal with in hand-coding, but it can be dealt with relatively quickly with high-level synthesis.
Cline: In addition, the tools that are coming out at the RTL level are doing smarter things with these designs. It does make it easier for us in the long run. The things that people are happiest with using high-level synthesis, which you would never expect, are the verification improvement and the predictable timing closure. You’d expect them to say productivity.

SLD: Is there a cost for that timing closure?
Biddle: And do you see more flip-flops?
Cline: You certainly can. We have a timing address knob. You can overfill the time schedule or you can underfill it. On average, we beat a hand-coded design between 10% and 20% in terms of area and still meet timing. Generally people would worry we are larger. We’re just a compiler. We can shrink down without a penalty.
McCloud: It’s a question of how much time you want to spend on a design. We’re typically within 10%. Sometimes we’re a lot smaller. Sometimes we’re bigger. If someone wanted to spend enough time they might be able to do a better job.
Kaul: It’s not an ‘either-or’ issue. It’s an ‘and’ issue. High-level synthesis can do certain things. If you want to add a pipeline to your design or you want to change your architecture, high-level synthesis is very well suited. If you want to go from RTL to GDSII in a 28nm design, then you have to have technologies that understand what’s going on downstream.
Cline: I agree. The better the logic synthesis tools get, the better the overall results.

SLD: How accurate does synthesis have to be?
Cline: It’s different for different abstractions.
Eddington: For architectural decisions you’re leveraging the capabilities of the logic synthesis tools. The decisions you’re making aren’t exactly where you’re going to put a register but roughly how many you need and roughly where they need to go. You let the logic tool do the fine-tuning.
Kaul: It’s very design-dependent. Some designs are pushing the performance. Logic synthesis has to get you very close to where you’re going to be at the end of place and route. Otherwise you can have a lot of iterations. If your design is not pushing performance, then I think you have a lot more give.
Eddington: Logic synthesis has to be pretty accurate. You need to make better decisions at the logic level. Integration with placement is still an ongoing area of innovation and improvement. The high-level synthesis, in terms of logic accuracy in the architecture and placement of registers and so forth, doesn’t have to be quite as accurate as the RTL logic synthesis.
Cline: Our customers get a number for a baseline, run that through logic synthesis and then correlate the two. You want them to be as close as possible. After that, one of the nice things about a high-level synthesis flow is the turn is really quick—literally minutes. We don’t hear people running things for four days. If it’s running for four hours, we wonder what’s going on. That’s a curse from a licensing standpoint because you don’t run this stuff for that long. But at the end of the day, they’ll run a number 100 times and then track a number. If that number correlates with what logic synthesis would have looked like, had they run it every single time, then I think they’re generally pretty happy. It doesn’t have to be 100% correlation, but we’re not going to run logic synthesis every time because it’s fairly expensive.
McCloud: It needs to be able to give you relative comparisons. All of these tools eventually take a candidate design down through RTL synthesis to give you some accurate estimates. Once you have that, you’re comparing the candidate architecture to new ones you can create in a matter of minutes. If your candidate architecture has 150,000 gates and you have another one that has 200,000 gates, is that relative comparison correct? Our number is accurate enough to do exploration. Typically you’ve got a high-level design model that’s technology independent. You take that into an FPGA and prototype it. When you take it to ASIC, almost always you do multiple architectures. We estimate the timing and where potential timing issues will occur. The next step is to take those through RTL synthesis, and that’s when you’ll know for sure. Did it meet timing or not. The architectural exploration benefits are really the big win, along with the verification benefits—being able to do those transformations without having to change your high-level model verification.

SLD: What determines who wins in high-level synthesis?
Cline: The technology takes a bit of time to mature. It’s quite easy to synthesize a C algorithm into some RTL. That’s not a hard problem and it makes the barrier to entry look fairly low. But getting a C algorithm into RTL that’s actually manufacturable is actually quite a hard problem.
McCloud: It is centered around completeness of flow. But I would say the most important aspect is the tool that addresses the verification side of things. When you look at the RTL design flow today, 60% to 70% of the design cycle is consumed by verification. A high-level synthesis tool needs to address the verification side of that problem. The approach you take with high-level synthesis can actually complicate verification if you don’t do it right. One of the important things is to have a source description that is deterministic and predictable so you can re-use that work you’ve done in C down at the RTL level. The tool that combines synthesis and verification is the right approach.
Eddington: Both of you guys stated the obvious. A high-level synthesis tool has to deliver productivity in design. It has to deliver productivity in verification. That means reliable verification from high-level models. But right now we’re all limited by these application-specific domains. The question is how we expand beyond those.

SLD: What are the limitations?
Eddington: Mostly it’s the algorithmic guys who are adopting this.
McCloud: I think that was the case three or four years ago. That’s not the case anymore.
Cline: I would agree.
Eddington: Achieving higher levels of abstraction and having design entry environments that are tailored to the different application spaces is what’s going to help this expand a lot more. We’re doing something a little different. C is important, but we have the Matlab in the model-based stuff. That seems to work very well for designers in the system-level space who may not know RTL or C. Software engineers and video engineers know C. But other environments are needed to expand this beyond the application spaces now being addressed.
Cline: Do you worry that ability of the system designer who doesn’t understand RTL is diminished because of their lack of understanding about how the architecture is implemented?
Eddington: No. I don’t think there’s any reason you can’t have a fundamental description that’s understandable and capable of being captured by a guy who has no understanding of RTL.
Cline: We would disagree. We’ve had designs that involve a hardware engineer who knows nothing about C and someone who’s an expert software engineer who understands C to the nth degree. The hardware designer will kick their butt almost every time. The reason is that algorithms can be specified in ways that imply architectures that cannot be implemented in a reasonable amount of silicon. An H.264 implementation is a good one. You can read the data in, but data has a temporal aspect in hardware. In software it’s always there in a buffer and you just go get it. But in hardware it comes in 8 bits. What do you do with the first 8 bits?
Eddington: I agree that if you ask a software engineer to write something in a sequential language, he’s going to write something that cannot be converted into a hardware implementation without having to do some fundamental changes. In our case, we’re not doing pure language. We’re building on an approximately timed, higher-level, model-based data flow graph.
McCloud: High-level synthesis doesn’t remove the need to design. You don’t just download an MPEG-4 algorithm and push a button. It’s not a tool intended to turn software developers into hardware engineers. You still need to understand what you’re trying to create, and that’s best done by hardware designers. But what it does do is remove a lot of the details you don’t have to worry about.

Experts At The Table: The Past, Present And Future Of Synthesis
High-level synthesis raises the abstraction level, but it doesn’t eliminate the need for synthesizing at the RTL level; still no all-in-one solution.

By Ed Sperling
System-Level Design sat down to discuss the future of synthesis with Shawn McCloud, product line director for Catapult C Synthesis as Mentor Graphics; Chris Eddington, director of marketing for system-level products at Synopsys; Bret Cline, vice president of marketing and sales at Forte Design Systems; Sanjiv Kaul, executive chairman at Oasys; and Andy Biddle, director of business development at Magma. What follows are excerpts of that conversation.

SLD: Is synthesis changing, and if so, why?
Cline: It’s definitely changing. The reality is there is a merging of various capabilities throughout the synthesis design flow to allow better transformations of data to happen in shorter order. It’s easy to say it’s because of productivity, market pressures and cost, but that drives EDA all the time. The key point is that with tools like the new logic synthesis tools, the new place and route and the new high-level synthesis you’re able to combine functions that typically were in three or four different tools into one or two, which allows you to make better tradeoffs and ultimately get better results.
Biddle: The focus on RTL to GDS is becoming more important because of the challenges of 65nm, 40nm and now 28nm designs. Traditional RTL synthesis has to become much more physically aware. Engineers can no longer throw netlists over the wall and expect to meet timing on schedule. We’re seeing the merging of technologies, as well. There’s a need to tighten up the links between the front end and the back end. We’re similarly seeing the need for greater productivity, particularly for algorithmic-type work.
McCloud: One of the most important things is that when these new synthesis tools come out they need to build on the existing RTL flows. One of the mistakes we see is when a tool tries to replace RTL synthesis. That’s reinventing the wheel, and there are already years of R&D behind RTL synthesis. It’s more important to have high-level synthesis built on top of existing RTL methodologies. Even today, gate-level design hasn’t gone away. That helps reduce risk. RTL is a necessary stopping point. It gives the security it’s working.

SLD: What will synthesis look like in the future?
McCloud: I think we’ll see more and more technology built inside and leveraged.
Cline: I agree that leveraging the technology people already have put into a design flow is important. That’s a strategy we’ve employed. When you go to a customer that’s had an ASIC signoff flow with Synopsys or Magma or anyone else and they are going through to gates you don’t disrupt that. But we also believe you can make better decisions inside the high-level synthesis tool if you know more about what logic synthesis is going to do with it. We don’t specifically go down to GDS II as part of our flow. But there are some tricks you can do if you have an embedded logic synthesis engine inside of your high-level synthesis tool to bring some of the higher-end pieces of the RTL synthesis up.
Kaul: You need a robust RTL platform to be able to take the RTL and go down. For large parts of the design, RTL synthesis is pretty stable, but for the very large designs, it’s becoming deficient. You have designs that are 50 million or 100 million gates. Most logic synthesis tools go from RTL to a mapped netlist, and then they optimize the gates and map it to a technology platform. Then you do physical synthesis after that. There can be 50 or 60 blocks that do not quite match your physical partition. So now you’re managing constraints, you’re dealing with very long runtimes, and you’re talking about closing the loop with physical implementation. When you move up to high-level synthesis, one of the things that would be useful is a capability that allows you to get quick feedback on whether your architecture is going to work or not. Is the QR going to be good enough? Is the implementation going to be good enough? Tools have improved a lot, but you need to know whether the chip architecture is going to be good enough. As the chips get larger, it’s harder to get a good answer.
Eddington: High-level synthesis has to utilize the key technologies in the RTL flow. It has to know what the RTL logic synthesis is going to do in order to make its decision. RTL logic synthesis is not going to go away. It’s part of the design flow and well established, and you’re crazy to try and change those. The high-level synthesis tool has to plug right into that. But it also has to have the right information to make its architectural decisions. That’s all about leveraging the downstream flows and making sure that information is brought back up.

SLD: How do you define synthesis vs. high-level synthesis?
Eddington: Synthesis is logic-level decisions and optimization. High-level synthesis is architectural-level optimization that takes a behavioral description and brings it down to a logic-level description.
Kaul: From RTL down is logic synthesis. Above that is high-level synthesis.
McCloud: To me the difference is in the source. A source to high-level synthesis is, by definition, untimed. It doesn’t contain any registers or clocks or I/O timing. In RTL it’s fully timed. It has a register with logic in between. That definition is part of the source. Another difference is the set of building blocks. High-level synthesis tools are working with adders, multipliers and muxes. RTL synthesis is dealing with gates. The process of inserting time is the process of scheduling.
Eddington: I disagree with one point. Some descriptions are approximately timed and have a notion of latency. They are very valuable ways of describing something at a high level that can be synthesized.
Cline: There are certainly people in the market claiming to have high-level synthesis and it’s debatable whether that’s really high-level synthesis.
Eddington: But even in the C environment where SystemC is defined as approximately timed and untimed. I consider the untimed is high-level synthesis, for sure. But approximately timed is also high-level synthesis because it isn’t describing all of the clocks and logic-level architectural details.
Cline: High-level synthesis is a bad term. Behavioral synthesis is better but it got a bad rap a couple years ago, so people are trying to stay away from that. And so if we’re high-level synthesis, what’ the next thing that comes out? Is it higher-level synthesis?

SLD: So how much of an SoC design is done with high-level synthesis these days?
Cline: It depends on the customer. The possibility is 100%, other than processor, bus and analog. One multifunction printer company does everything that isn’t analog, bus or processor in SystemC with our tool. A lot of it is re-use from the past. You can describe all that stuff in SystemC. Some of it may look pretty low level and it can be done with RTL synthesis. It’s not what we recommend, but let’s face it. Designs have all different levels of abstraction. You need a way to handle everything.

SLD: It sounds like the definition is far from clear-cut.
Cline: Some of us disagree with the definition. We output RTL. That’s our job, and our customers go off and use that RTL. In the real world, they have to go off and use some tool and they get gates out of it. What we’re finding is that when they use a tool that combines Talus or DC-Topo into place-and-route, as well, then they get some more advantages in optimizing. You have one pinch point in the middle, which is RTL, which is our common language. I don’t think the definitions matter. But there is a real sense in the market that a different task is taking place. It doesn’t matter what you call it.
Biddle: We have a handful of customers that are using SystemC. We’ve been partnering with Mentor on making sure the structures they’re putting out can be synthesized and that we can build a flow. Ultimately, one of the big bottlenecks we see is formal verification. Most people rely heavily on formal verification today. There are a lot of techniques and tools.
McCloud: There’s no single approach for verification. There’s classic functional-based simulation as well as prototyping and emulation. Calypto has a product out called SLEC that does do C-to-RTL verification.

SLD: What happens at the next level above this?
Cline: The RTL market has a well-defined flow and there are tools that plug into this flow. At the ESL level above that there’s a lot of interesting stuff—everything from virtual prototyping to formal verification. But that hasn’t jelled into a flow that everyone uses. Everyone picks their parts and puts them together.
McCloud: You are starting to see some parts of the flow solidify. We’re seeing that in the way that people verify designs. You develop a C description, you spend as much time as you can verifying that C description is correct, and what you’re generating is something that hopefully is predictable. You want to be able to re-use it, not re-do it at the RTL level.

SLD: How accurate are RTL synthesis and high-level synthesis?
Biddle: Everyone is always demanding greater predictability. There is constant pressure to correlate better. Once you have a netlist, what will area and timing really look like? That’s forcing us to add more physical modeling. But where we’re starting to have problems, particularly as we move to 40nm and 28nm, is how long it’s going to take to close timing. Once you come out of synthesis, are you done? We see designs where they’re throwing in gates just to meet timing, so chips are getting bigger than then need to be.
Kaul: For a large chip at advanced nodes, doing timing without understanding the placement is becoming less prevalent. You have to have placement information to have accurate timing. But for larger chips, understanding the floor plan is very important. Where the block goes in relation to the rest of the chip becomes very important. You have to look at global wiring, congestion and timing convergence. It’s important for the synthesis tool to look at all of that.
Eddington: There’s more innovation available in physical synthesis—integrating these placement and logic synthesis optimizations and doing them better. We’ve been adding physical synthesis in the FPGA space, but it’s still an area that needs further innovation.

By Ann Steffora Mutschler

At 65nm, design for manufacturing optimization and analysis has mostly been an afterthought. At 40nm and beyond, DFM has been pushed well up into the design phase.

There are good reasons for this shift. What emerged at the 65nm node were signoff tools that understand manufacturing used in semiconductor design, said Manoj Chako, a product director for digital sign-off solutions at Cadence Design Systems. DFM used to occur post-DRC and included the work done by the foundries. At 40nm, ‘design-side DFM’ is forcing design teams to take into account the lithography, CMP (chemical mechanical planarization) and electrical (parametric yield) issues.

“The systematic effects on the layout have now become a prominent problem,” Chako said. Among the problems to surface at 40nm and beyond are parametric yield due to tight geometries and the very tight pitch in designs, performance issues caused by strict design rules and the addition of stress in designs that is being added to improve the mobility and performance of transistors.

From a high level, this is being caused by a fundamental disconnect. The process geometries are scaling but the wires do not scale uniformly. The wires are getting narrower, which is causing a problem with cross-talk, but they’re not getting as short as everyone expected, said Rob Knoth, technical product manager for Magma Design Automation’s design implementation tools.

Moving from 65 to 40 and 28nm has driven other changes, including the penalty of a via. “There are now rules governing redundant vias and the shape of a via, for instance, said Knoth. “Some foundries change their recommendation for what a good via would look like. This can be multiple square or rectangular cuts.”

Knoth said he is also concerned about stress-induced lithography violations at 28nm, a lot of OPC (optical proximity correction) checks, and very complicated end-of-line rules. “At 65-nm, things were a little more vanilla. People were looking at dummy metal to improve the gradient across the chip. They were definitely looking at redundant vias but it wasn’t nearly as critical as it is at 40nm and 28nm, both from a manufacturing standpoint and a timing standpoint.”

These technological impacts have changed the way semiconductor implementation is performed, noted Sudhakar Jilla, director of marketing for Mentor Graphics’ place and route products. At 28nm it’s important to have the router be able to call the signoff quality engine during the routing phase. Typically what happens is that once routing is finished, DRC (design rule checking) and LVS (layout vs. schematic) are run. At 65nm, the DFM analysis was an afterthought once the design was judged DRC and LVS clean. At 40nm and beyond, it needs to be considered much earlier in the flow or it will cause some very late stage surprises that will make recovery difficult, he said.

Jilla said that for one 28nm library a customer ran the design through the flow and performed the LFD (litho friendly design) analysis. It showed a number of L1 hot spot errors due to fidelity issues of the manufacturing process.

“This occurred one week before the tapeout, and if they had to go and fix all of the violations it would have taken a few more weeks and would have to be done by hand,” he said. “We are working on a technology for the router – which is utilized four to six weeks before tapeout – that can invoke the same LFD engine inside the router. Once the router is done routing it asks if it is LFD clean. If yes, it is done. If not, the fixes are made at that time. If you don’t have a solution where the router can take advantage of the signoff engines, you are going to have to wait until the last minute or let the design go as it is, taking a risk on the yield.”

Knoth said that one of the big things Magma is doing, especially moving from 40nm to 28nm, is changing some of the cost functions that are driving the tool, and looking at things like spreading wires earlier so that congested hot spots are not created. The company also is building intelligence earlier in the cycle to avoid future manufacturing problems.

“It’s hammering more on that ‘correct-by-construction’ concept,” Knoth said. “The cost of fixing a problem once you analyze it is huge. That being said, though, the other main effort that we are working on for 28nm is building a better infrastructure so that timing can be considered as you are going in and fixing lithography problems.”

In Magma’s place and route toolset everything is integrated: the timer, the DRC checker, the router, etc., so the router can call the other engines as it is making decisions. If it is reordering wires, or is jogging something to make it more litho-friendly solution, it understands the timing impact of that because you can’t just fix DFM.

“That’s a very big fallacy that I think happened early on when a bunch of DFM solutions hit the market at 65nm,” Knoth said. “Everyone was just looking at DRCs and DFM and we made sure that timing was also part of that, so that as we went off to hammer on those problems we weren’t creating a new timing violation that would cause you to rip up and rebuffer a whole net.”

The foundry effect
“DFM in general is a concept that is never going to go out of style,” Knoth continued. “The frustrating thing about DFM is that it just reflects a foundry’s lack of familiarity with a process. As a process matures the foundry figures out what yields better and what doesn’t. They make hard rules to improve the yield and a lot of the soft rules that are needed for DFM, those go away.”

At 65nm, TSMC and most of the foundries had DFM as a recommended rule, but it was not a mandatory signoff check. But starting at 40nm, most of the foundries are making DFM handoff mandatory.

“What that tells you is that the foundries are now starting to realize you can’t just squeeze the DRC rules some more and hope it addresses DFM success,” Jilla said. “DFM is a big enough issue that they can’t hide it in the back. And what that indirectly means is that although the customers say they do run a DFM check and find 20 or 30 LFD hot spots. or you do the critical area analysis and there are a lot of opens and shorts, what do you do about it? That’s where the router comes into play and the designer needs to have a router that can respond to these sign-off checks and give a clean design that not only is DRC/LVS and timing clean, but also DFM clean.”