Posts Tagged ‘Virage Logic’

Next Page »

Experts At The Table: The Trouble With Corners

Thursday, September 9th, 2010

By Ed Sperling
Low-Power Engineering sat down to discuss corners with PV Srinivas, senior director of engineering at Mentor Graphics; Dipesh Patel, vice president of engineering for physical IP at ARM; Lisa Minwell, director of technical marketing at Virage Logic; and Jim McCanny, CEO of Altos Design Automation. What follows are excerpts of that conversation.

LPE: As we get to 22nm we’re starting to get to things like double patterning. Does that affect corners?
Srinivas: Double patterning is more of a manufacturing variation. It has some effect on the length, which affects the device. There are tools for addressing these kinds of effects. You can do an exact simulation or you can guard-band it.
McCanny: The transistor length is larger because of double patterning. The sensitivity to variation will be reduced. So it actually may help—inadvertently.
Patel: Double patterning poses more of difficult questions about the viability of going to 22/20nm from an economic perspective. The throughput will go down, the cost of wafers will go up. At what point do you go from 28nm to 22nm? You’re expecting a density benefit because it shrinks the size of your function. But it’s going to take you ‘x’ times longer to do this. Is it viable?
Minwell: At least part of this concerns design techniques. If you also have algorithms built in for test, the customers will have the comfort to pick it up on chip when it’s running. They also have the ability, when they test their parts, to tweak things. There’s a whole other aspect to this that can reduce the stress of our customers from an up-front perspective.

LPE: That’s basically model up front and then tweak as you go, right?
Srinivas: This is post-silicon tuning.

LPE: But that’s only part of the picture. You need to have the ability to tweak all along the way, don’t you?
Patel: Yes. There are a number of tests. When the silicon comes back you run the DFT (design for test) and at that time you use these techniques to tune certain parameters. Then when you’re in the field you can do some tuning.

LPE: Like bringing your car in for a software update?
Patel: Yes, it’s a similar approach. You might find the load is getting very heavy, so you turn the frequency down a little bit and still keep the same performance.

LPE: What happens as we get down to 22nm and we can no longer do the same kind of guard-banding we could do at 90nm or even 45nm?
Srinivas: Over-design doesn’t necessarily help you because as you add more area to the chip to make the critical path faster. You need to model some of these effects realistically, not over-pessimistically. So you don’t say every path is 10% faster and slower at the same time. This tends to cancel out the random variation. That mitigates this over-design. You can’t model everything, so there is still some work to be done.
McCanny: AOCV (advanced on-chip variation) is being done outside the corners at the moment. That’s the current state of the technology, but it’s a significant amount of character work. We think it’s worse than statistical, and you end up with a global number per cell. We see a lot of variability, depending on why the circuit is operating. Another issue with corners is mining data. It’s putting a stress on everything. If you look at the corners you create there’s tons of duplicated data. If you have 100 corners there’s an enormous amount of data that’s duplicated.
Patel: We have challenges not only in creating the data but also in validating it and even distributing the data. We have to distribute all this data to our customers through a Web-based channel. Imagine trying to transfer gigabytes of data down a pipe that isn’t particularly thick. There are lots of changes we need to think about in terms of the number of corners that we are giving customers.
Srinivas: EDA tools usually suck up all the libraries and work with it. But with the machine size and 128 gigabytes being the norm, that’s causing a problem. Everyone wants to reduce the memory, but it’s not uncommon to have 10, 12 or 15 gigabytes being taken up by the library. Imagine if you add more corners. EDA companies are putting libraries on a disk so they can be used as needed.
Patel: A while back we couldn’t even compile the DCS corner we had created because the machine we were using was not big enough. That was just trying to compile one corner.
Minwell: On the subject of guard-banding, I am noticing that customers are starting to move away from that. One thing we haven’t discussed here is accuracy. Every time you’re transitioning from the fab, creating a model, the model being used in a simulator with the IP vendor adding their characterized view—at every level you have a certain amount of approximation. By the time you get to the chip level the designers have to deal with layers and layers of approximation. It’s hard to know where you are with accuracy at that point. What I see is more compensation effects in post-silicon and more customers pulling back on the guard-banding.

LPE: Does the problem get worse at older nodes because those nodes are being optimized for low-power?
Srinivas: Yes, even at the older nodes SI is harder. Things like L-gate are becoming global problems. People use a 10% rate to cover their problems, but it’s no longer that easy.
Patel: At 180nm, the strategies are still the same. What has become more complex at 180nm is the low power. We have introduced voltage domains. From a corner point of view it’s not exploding. But if someone is doing a complex microcontroller, they will need additional corners for each voltage domain.
Srinivas: When people are looking at advanced nodes they are looking at more Vt levels. At 45nm we saw three Vt levels—standard Vt, low Vt and high Vt. Now people want more flexibility to manage power, leakage and timing. Now we’re seeing six or seven levels. It gives you more flexibility but it makes it harder.
Minwell: It also increases your library size. The tools are going to break.
McCanny: It does break the tool in terms of capacity. But also, in trying to optimize a problem the number of variables has a major impact on performance. We may be completely overloading the optimization problem. We’re seeing people using a subset of corners for optimization and another subset for signoff. If you make the optimization problem manageable, you pass the problem off for an ECO. But guard-banding is inherent in the whole process. There are guard-bands in the SPICE model. There are guard-bands in the library. If people are trying to be more fine-grained about their voltage level and their Vt, they need to better understand what the guard-bands are. In the past, people would take a library from their supplier and trusted it. Now they’re starting to question it. There are little decisions that get made behind the curtain that can have a big impact on a design.
Minwell: There’s also an increasing fabrication cycle. Now it may take six months. That’s difficult for customers.

What’s In The Package?

Thursday, September 9th, 2010

By Ann Steffora Mutschler
The growing market for smart mobile devices and high-performance processors requiring more than 2GHz of processing power is driving IP providers to do even more work to prepare their IP offerings for customers.

This theme was reflected at last week’s GlobalFoundries Global Technology Conference when the company’s senior VP of technology and R&D Gregg Bartlett shared details of the foundry’s 28nm high performance plus (HPP) technology, meant to give a performance boost of as much as 10% over the company’s current HP technology. HPP also offers optional ultra-low leakage transistors and SRAMs meant to extend the range of application from high performance down into the low power range.

Navraj Nandra, director of product marketing for mixed-signal IP at Synopsys, confirmed customer demand for IP characterization for packaging because of the speeds that customers are requesting. Logic libraries, CPUs and other IPs are running anywhere between 1 Gbps and 2 Gbps internally, while interfaces are running at 8 Gbps to 10 Gbps.

“That’s great because we can build the IP and we’ve got very smart engineers at Synopsys put that together, but it has to go through a horrible package,” Nandra noted. “I say that because people invest hundreds of billions of dollars on fabs to make transistors go faster but the packaging is still super low-cost. All of this stuff goes into very low cost applications.”

The fast-running protocols are first evident in the data center infrastructure area and then start to transition down into the consumer markets. “When they do that consumers want the performance but they don’t want to pay the price—and that’s where you see a lot of the interesting challenges of getting very, very high-speed signals on-chip and off-chip in very cheap packages where the key careabouts tend to be related to whether you are using flip chip or wire bonds, the type of substrate, length of the bond wire and the distances between the actual bond wires,” he observed.

Added Ken Brock, Synopsys senior staff for product marketing: “We have to start worrying about the I/Os and characterizing the packaging because there is a whole lot of inductance; it’s not just the capacitance that’s a struggle. What it does is set up this funky little resonant frequency that has to be managed. So what is happening at these extreme frequencies, and when you are working with the package, this resonant frequency can come up like the Bay of Fundy with its 53-foot high tides.”

In electrical waves, the results can be disastrous for the chip. “Even just doing a single chip you really have to worry about balancing the capacitance and inductance of the package because these are big chips and are moving very fast,” said Brock, who joined Synopsys from Virage Logic following the acquisition of the company that was completed last Friday.

From a technical perspective, there are a few ways to characterize IP for packaging.
“The first way is really verification in terms of lots of simulations. We talk to package vendors, get a package model, and implement that model in HSPICE. When we are running through the verification of the blocks that we have designed it’s not standalone — we add the package model to the simulation and that gives us a very good understanding of how the package is going to influence the performance, and it does. There’s a loop there where we have to make sure that the package parasitics are not impeding the performance too much,” Nandra said.

For logic libraries it’s usually a simple capacitor and resistor that all the logic cells and memories are characterized to, Brock said.

Synopsys estimates that it spends approximately 10 CPU years simulating a complex piece of IP with all of its resistors, capacitors and inductors. “In terms of hardware characterization, that’s where the fun really starts,” Nandra said, “because there you get the IP packaged in whatever package we were interested at the time and we typically go for something like a BGA—a very low-cost package—typically it’s a bond wire.”

Full characterization is run on that package and the actual IP has been manufactured with split lots so all the process variations have been included in the characterization. Then, a few hundred samples or a few hundred packages will be characterized, meaning that they are automatically put into Synopsys’ test head and go through all the characterization routines at temperature.

For example with USB, he noted, the full suite of electrical tests for USB is performed which could take up to a couple of weeks to finish for one package. However, that provides a pretty good understanding of how the package interacts with the IP under fairly hostile conditions, Nandra concluded.

The Week In Review: Sept. 3

Friday, September 3rd, 2010

By Ed Sperling
Andes Technology, a Taiwanese maker of SoCs and processor IP, adopted Cadence’s digital front-end low-power design flow, which is based on the Common Power Format. Score one for CPF.

Toshiba Information Systems expanded its adoption and deployment of Mentor’s Catapult C for high-level synthesis. What’s interesting about this deal is Toshiba’s shift to untimed C++ and System C from an RTL-based design, which the company says is unproductive.

Synopsys completed its acquisition of Virage Logic, greatly expanding Synopsys’ IP portfolio from standard interfaces to everything from memory to processor cores and logic libraries.

GlobalFoundries held its first conference, which was largely a coming-out party for the combined company that includes pieces from AMD and Chartered Semiconductor. There were several themes of note. First, GlobalFoundries is gate-first high k/metal gate, while TSMC and Intel use gate last. For most customers, that means it becomes even harder to move from one foundry to another. Second, GlobalFoundries sees this as a strong ecosystem play. It has lined up ARM—which is playing across both foundries—as well as Freescale for its 90nm flash memory.
And finally, the company introduced a 28nm analog-mixed signal flow development kit.

In the memory space, memory resistors, aka memristors, are gaining attention. The technology is considered faster than flash while also drawing low power. Solid state memory already lowers the amount of power being used because there are no moving parts, but memristor reportedly uses as little as one tenth the power of flash. HP is teaming up with Hynix to develop what it calls ReRAM, which should put a big dent into the DRAM market.

Experts At The Table: The Trouble With Corners

Friday, August 27th, 2010

By Ed Sperling
Low-Power Engineering sat down to discuss corners with PV Srinivas, senior director of engineering at Mentor Graphics; Dipesh Patel, vice president of engineering for physical IP at ARM; Lisa Minwell, director of technical marketing at Virage Logic; and Jim McCanny, CEO of Altos Design Automation. What follows are excerpts of that conversation.

LPE: How does software affect all of this?
McCanny: Software has the ability to regulate the voltage. That creates an almost infinite number of scenarios for testing the chip and to do timing before you manufacture it. The only solution we have right now is to build more and more corners. There is no worse problem for systems integration. If you don’t pick the right corner, it may create a nightmare. We should be looking beyond corners to the model. The voltage keeps changing or it isn’t correct. Maybe we need better models that can deal accurately with voltage variation without having to build tons and tons of corners. We have seen better models for systems integration. Then there are the models for statistical modeling, which has its own set of issues. It does cut down the number of corners you need, but it doesn’t cut down the amount of work you need to do to get to those corners. As an industry, we need to address this. Doubling and tripling the number of corners at every node doesn’t work. We all fail when the industry hits a wall.
Minwell: I agree.
Srinivas: There’s one more issue I want to mention. Another complication comes from combinations. When you have 50 blocks and various permutations—this block is on, another is off, another is in sleep mode—you have to verify your chip for each permutation. Your block will look different with Block A on, Block B on, and Block C on. As the number of blocks increases, so do the number of permutations. The interplay between the various voltage domains becomes critical.
Patel: The interplay is important, and a lot of people are using asynchronous communications between those domains. We can’t expect a synchronous behavior to exist all the time between the domains. This is asynchronous in that the communication between the domains doesn’t have a relationship in the timing sense.

LPE: Are there tools for this?
Patel: There are clocks, but it has to be dealt with at the system level.
Srinivas: The low-power methodology using UPF or CPF is very well known in terms of how you do level shifters and things like that. The challenge is in the verification.

LPE: Then it’s on both sides of the design process, the architectural model and the verification?
Srinivas: Absolutely.

LPE: Who’s responsible for creating the model?
Minwell: It starts at the foundry level. It’s a combination of that and the simulation world of EDA. But being able to understand and extract the correct parameters to support a model is extremely important. The models really haven’t changed much in recent years. We’ve enhanced that model and added some elements to it for statistical purposes, but the time has come where the foundry needs some help and some sort of new methodology to comprehend the variations we are seeing. We’re seeing a significant falloff in temperature, for example, when we’re looking at timing corners. How are you going to meet any kind of timing with that? There has to be something in the model or the data collection where there is something between 0 degrees Celsius and -40 degrees Celsius. You need to be able to look at the variation by the various poly layers. That contribution is really important. We really haven’t seen innovation there.
Srinivas: On the interconnect side the problem is very well understood. There are much better models for the interconnect—how the resistance changes, how the capacitance changes, various local layout effects. The problem is on the device side.

LPE: But at 22nm and beyond, there are issues like electromigration at the interconnect, right?
Srinivas: There are models available for that. But at the device side the information is lacking because it is much more complicated. The L gate radiation has been well studied. The design community has never elected to adopt this model. They don’t like statistical models. They want to tape out the chip with a real number.
Patel: The problem is more complicated. We can model as many variations in the SPICE model as we want, but if you can’t find a way of representing them at the cell level it’s not going to be useful. That’s the issue we’re facing. Right now if I was told to generate models for something, the amount of effort it takes is enormous. We’re looking at a 5x increase in cost of characterization, validation, disk space, compute requirements, and it mushrooms out of control. If no one is willing to make that investment it doesn’t happen.

LPE: Some of the large IDMs are doing that independently, though.
Patel: Yes, because they can afford to do it. But the mass market is not. They’re not sure if something that is statistically significant will fail when it comes back. As soon as you get into that discussion, they go back to the old approach of margins and certainty.
Minwell: We definitely see a reluctance by companies to move in this direction.
Srinivas: Companies like TSMC are taking a lead in that. They are looking at L gate radiation. They give you tables, but it is not everything. They are looking at the dominant effects. But there is no comprehensive effect to make sure everything is covered, so we still need some margins.
McCanny: There needs to be work done on the process model side, but there’s a need for better modeling on the EDA side. We do use cell-level extraction, which is what all the EDA design tools use today. That can be improved. There are some people who believe you can do the modeling more accurately if you do transistor-level extraction. SSTA (statistical static timing analysis) is one innovation on the EDA side. It hasn’t been done on the IP side. We know the effects are real. Some of the consortiums in Japan have studied this. But there is still a roadblock among the IP guys. And I think 5x is an underestimation.
Srinivas: About five years back Synopsys introduced a CCS (composite current source) model that handled voltage variations much better than before. Things are progressing from that side.
Patel: But CCS is still limited in the voltages it can handle.
Srinivas: Yes. And there is no one cure for everything. There may be corners and nearby corners. A good way to predictably model corners allows you to go from 100 corners to 15 corners. That’s a practical approach.
Patel: From an IP perspective, some of the solutions we need to come up will have to be architectural. I don’t think we’ll ever get down to a small enough number where people will be happy. We need to be able to tune to whatever the operating conditions happen to be. If the temperature is up a little bit, the device is slowed down, so you can deal with it that way. But it has to come from that level.

LPE: Do you bring process variations into that, as well? At 22nm you may not be depositing the same amount of metal in a transistor.
Patel: Yes, and that’s going to show up as a difference in behavior for that transistor from a timing perspective or a leakage perspective, and the impact of that on the whole design. That could be treated as extra corners, or you can say that you expect this to happen and you can treat your circuit accordingly.
Srinivas: I disagree. It’s not a corner. It’s a random variation. It’s an on-chip variation.

LPE: But temperature can be a variation, too.
Srinivas: There are two components to temperature. One is the global temperature. That is global variation. There is an on-chip variation in temperature because of the activity. You may have one component of the chip that is highly active, so the temperature gradient will be more and for some areas it will be less. That is a local problem. When we think about these problems it makes sense to think about whether it’s a global problem or a local problem. Another example of random variation is dopant fluctuation. These are the ideal candidates for statistical modeling. For a more normal distribution you can model that.
McCanny: We can certainly reduce some of the corners with some of the variables. The temperature can be measured in situ and use some feedback mechanism to slow down the clock of the circuit.
Patel: As long as the user experience doesn’t get impacted. If you’re playing back a video and it stops momentarily, it’s okay. If it happens all the time, that’s not okay.
McCanny: Temperature and voltage are areas where we haven’t done enough in the modeling. Statistical timing reduces the number of corners but you still need corners.

Can IP Be Standardized In Low-Power Designs?

Thursday, August 12th, 2010

By Ann Steffora Mutschler

SoC designers are beginning to embrace low power formats UPF (IEEE P1801) and the Common Power Format (CPF) to express power intent, but are these efforts enough to create standardized IP in low power designs?

Mike Brogley, IP and solutions product marketing manager at Actel, believes it is possible. “Yes, IP can be standardized, but the main driver in low-power applications is really the device, not any particular circuit implementation.”

“Power-aware design is very important. Design practices like power-aware clock domain management are critical to the management of power in battery operation handheld device applications, and use of flexible sleep modes that retain data and circuitry states can yield major advances in battery life,” he said, but he cautioned that flash-based FPGAs, for example, can deliver such radically lower power consumption compared to SRAM-based FPGA devices that the selection of the “theoretical best vs. absolute worst design practices for power consumption would yield nothing close to the differences between the underlying device technologies.”

Brogley said IEEE P1801 (UPF) “certainly brings a lot to the table—a standardized way of describing power across the design spectrum cannot be undervalued. The degree to which tools providers support the UPF language and methodology in the tools applicable to FPGA design will drive the relevance to IP in the FPGA world.

Looking at it from a higher level, Ken Brock, director of physical IP marketing at Virage Logic said the standards efforts “take care of the needs of the EDA vendors, which is a very important component of the recipe. [But] it doesn’t really address a lot of the other issues for IP vendors. It doesn’t address which voltages, which temperatures are across the line, and certainly doesn’t address any of the functionality issues.”

Vic Kulkarni, senior VP and GM of the RTL business unit at Apache Design Solutions, agrees with Brock. “There is more to it than just the CPF or UPF standards—that’s really the key,” and points out the importance of understanding the bigger drivers at play. It requires looking at the technology migrations and technology advancements to put things into perspective.

Starting with timing, signal integrity was the key, he noted, followed by static IR. Dynamic power issues took over at 65nm as interconnect-driven timing became more critical, which impacted the RC as opposed to the pure timer. Then reliability came into the picture at 45nm with intra-domain challenges to cross-domain challenges; a domain defined as creating an IP, putting the IP in the context of an SoC, with that SoC put into the context of a PCB and package. In terms of creation of IP, it could be digital IP or analog to digital, then the I/Os come in the picture. How do you manage these extremely high speed DDRs? DDRs are pretty much driving the apps we just talked about, he said.

“CPF or UPF is very critical as part of driving a low power intent, but that’s not good enough for sign-off and assuring that indeed your IP works in the context of SoC and package,” Kulkarni explained. He said Apache looks at this issue holistically in terms of creation of IP at the ESL world, the RTL world, the logic world and then the process world and bringing all of them together.

“If you look at what happens to power, if you target it early in the design, you have the highest probability of making an impact on the creation of low-power or low-noise-aware IP and SoCs. You have to target at the higher levels of abstraction but as you go down toward synthesis and post-place & route, the ability to impact power gets further and further reduced. However, by the same definition the implementation and signoff importance increases because they have to be more and more precise toward the silicon. So combining these two is critical in terms of IP creation and IP validation. Mitigating power integrity issues from power reduction techniques happens in the implementation phase,” Kulkarni said.

“UPF and CPF are about low power intent and that is required only for extremely high-level designers, but once you get down in the RTL what do you do with it? It keeps you ‘low-power correct’ in terms of specifying islands that are created but if those island start switching, what happens to my physical design? That they can’t tell you,” he added.

While UPF and CPF are a great start, it may be a few more years before it is truly possible to standardize IP in low power designs given the use cases it needs to be characterized for.

Experts At The Table: The Trouble With Corners

Thursday, August 12th, 2010

By Ed Sperling
Low-Power Engineering sat down to discuss corners with PV Srinivas, senior director of engineering at Mentor Graphics; Dipesh Patel, vice president of engineering for physical IP at ARM; Lisa Minwell, director of technical marketing at Virage Logic; and Jim McCanny, CEO of Altos Design Automation. What follows are excerpts of that conversation.

LPE: Corners appears to be getting more challenging as move to advanced nodes. What are the main problems?
Srinivas: When you talk about corners you need to talk about variation. There can be three kinds of variation. One is operational variation, which includes different modes of operation. Your iPhone may be taking a picture, it could be in standby mode, or you could be talking on the phone. To tackle these issues you don’t need corners. You can deal with different timing constraints in different modes. The second is global variation. This is variation from fab to fab or chip to chip, but it’s identical variation. These are typically handled by corners. They could be slow-slow corners, fast-fast corners, or a mix and match. The third is on-chip variation (OCV), or local variation. These are variations in transistor length or Vt variations on the chip. These are the most difficult to model and the least understood. One progression is advanced OCV where you try to model random variation component by means of a state-dependent OCV. That’s where we see statistical modeling might help.
McCanny: The key thing driving the need for corners is process variability. Managing that is very difficult as you go down into these new process technologies. Global variation and local variation are problems. There’s also the need to address power and voltage scaling. Some of the corners we create are a way to bring accuracy to the analysis. What is my timing if my voltage is at this level? And what if I scale my voltage? People are creating additional corners just to deal with the voltage scaling issue, and maybe that’s a problem. We just keep using the same technology to scale. We’ve seen people looking at 60-plus corners. That’s already unmanageable. And then the analysis tools have to deal with all of this. How do you optimize a design when you have so many choices? If we keep using the same technology at 28nm and below, it’s going to break.
Minwell: From an IP perspective there are customers who require a lot of PVT (process, voltage and temperature) corners for all of those reasons. But early in the technology node there’s also the accuracy of the model that you’re using. For us, we have to use other methods to predict where the process will land and set our architecture that way, and to be able to provide the proper estimates for our customers and their designs. There are other challenges that come from the technology that lead up to statistical timing analysis and Monte Carlo analysis. We’re also seeing an increase in PVTs.
Patel: There are two sides to corners. One is application-driven, which is the end user need. Low-power drives a lot of decisions where people end up partitioning their chip into multiple voltage domains. That requires a different set of corners for the voltage domains, and it’s the first set of partitioning that happens. What does the SoC partition look like and how many voltage domains do you have, and do you need to sign off the voltage domains in a different manner? That’s the first level. The second level is what happens in the voltage domains. That’s where the variability effects come into play. In the past, we used to sign off with three or four corners per voltage domain. As the variability has increased and the mechanics of dealing with that have become more sophisticated, the number of corners per voltage domain is going up. People are now requiring five to seven corners per domain. And early in the process, you don’t know where that process will end up so you need more margin in the design.

LPE: Is it necessary to deal with every corner, particularly in a consumer electronics device where a failure is not life-threatening?
Patel: Consumer devices have less stringent requirements than a missile guidance system. But the issue then becomes the places that a device can go into. The same device can be sold in Finland where the winter gets cold or on the equator, so the extremes in temperature have to be taken into account. There is a basic set of sign-off criteria that everyone has to comply with.
Srinivas: The problem is that models are so simple that if the temperature goes up by 10 degrees your delay will increase by 10% according to the model. But devices don’t behave linearly like that. There are temperature inversion problems when the mobility of the electrons changes, for example. This kind of non-linear behavior complicates the modeling. Without understanding how the different parameters behave under different operating conditions it’s very difficult to create a generic model.

LPE: So the model needs to be more granular to deal with this?
Srinivas: That’s right.
McCanny: You have to deal with the extremes, but when you’re trying to optimize your design across very extreme conditions you’re going to have a design that isn’t competitive. We’re seeing people creating corners for optimization and a different set of corners for signoff so they can optimize around the sweet spot of where their product is going to be sold. They’re probably going to sell more phones in America than in Finland. But when it comes to signoff they have a different set of criteria. That adds to the massive amount of data and work that’s needed to get the design done. From the time a new process becomes mature enough and they need libraries, we have technology to create those libraries quickly. But there’s a point where you can’t keep up. We need to look at this differently as an industry. Can we be more sophisticated in the tools we use to look at things like voltage variation in a more accurate way without requiring different corners for voltage domains?
Patel: We have also seen is a move to deal with the least amount of optimization and deal with corners in signoff. There is a downside to that. People spend a lot more time doing ECO (engineering change orders) at the back end. If I simplify my design with optimization I have to spend eight weeks in the ECO process. It’s a chicken and egg problem. If you don’t see all these things in the beginning, then you keep adding work on the back end.

LPE: There’s a whole separate movement toward design for variability. How does that affect corners?
Minwell: There are various design techniques that may be used to adjust sensitive circuitry to the variability within the die. Those design techniques are being incorporated so that as the chips are tested and the variability is understood, they’re able to recover process variation. Design techniques also play a role in variability and the loss of predictability in the model. There are things the EDA world can do. There are things the foundries can do. And from a design perspective, there are techniques that can be incorporated, as well. But it definitely is more complex for all of us. Being able to provide reliable IP is really important.
Patel: Going to design for variability, that’s a key issue we will have to resolve in the next few years—especially at 22nm and 20nm. At 28nm, we have managed to use some of our existing techniques and gotten away with it. The variability is there but we know how to deal with it. For 22nm, where the variability will be even worse, the solutions you can provide are many-fold. It’s what can you do at the physical IP level. What sort of sophisticated strategies can you use to design physical IP? There also are techniques we can use at the architectural level. With Razor the CPU is designed with failure and recovery in mind. That’s all about recovering some of the margins all of us are designing into silicon. It’s when you finally get to silicon that you know how much it’s going to weigh because you don’t know quite where in the bell curve it’s going to fit. Those techniques will become more important.
Srinivas: One other trend we have seen along with the low-power trend is the growing complexity of signal integrity. At 40nm and 28nm, signal integrity closure is a very tough problem. When you couple that with variability and low power, it gets even more complex. All of this makes timing closure more difficult. It’s now a question of whether you make the runtime faster by merging stuff or deal with ECOs at the end.

Keeping Models In Sync

Thursday, July 8th, 2010

By Ed Sperling
Models and higher levels of abstraction have been hailed as the best choice for developing SoCs at advanced process nodes, but at 28nm and beyond even that approach is showing signs of stress. The number of models needed for a complex SoC has been growing at each new process node, which makes it much more difficult to keep them updated and in sync as the design progresses down the flow.

There are architectural models, transaction-level models, IP models, software models, and more recently power models that span the entire design from hardware to software and even to manufacturing. Problems can creep in at every step of the flow, from the time they are created to the constant tweaks by design teams, which often are in different locations. Those tweaks are necessary for a variety of reasons ranging from optimizing performance to cutting or in some cases boosting power, as well as for adding or subtracting functions. But all those changes make it easy to skip a synchronizing step, which is critical in keeping a design on track. And it’s becoming even more critical as chipmakers move to design for variability and computational scaling on the manufacturing side.

“Being able to build models that talk to each other is a tools issue and a methodology issue,” said Shabtay Matalon, ESL marketing manager in Mentor Graphics’ Design Creation Division. “The problem is when you split into teams and not all the models are alike. That means the abstraction of the models above RTL are not the same.”

That’s particularly troublesome when the models are created by different groups or even different companies, which is the case with software and IP. The TLM 2.0 standard is a first step toward creating a standard that all other models can work through. The problem is that while there are hooks for the various power formats there are no tools to automatically create those power models. Large IDMs such as IBM, STMicroelectronics, Qualcomm, Broadcom and Intel are all developing their own power models at present.

“Because there is nothing available we’ve had to do it ourselves,” said Bhavna Agrawal, manager of circuit design automation at IBM. “It’s not because we love to do it.”

Power models are particularly troubling because they have to span all of the pieces, all of the functions, and all of the various power tricks and tools that engineers use to make complex chips. Turning on and off a single power island is a fairly simple thing. Turning on and off 20 power islands, and putting some into reduced states of functionality can produce unexpected results that requires constant adjustments, and each adjustment affects everything else in the design and all the other models.

More software and IP
The complexity increases yet again when software and third-party IP are thrown into the mix. Software developers have their own methods and models, but they’re not typically compatible with the hardware models. Having teams work side by side helps force the issue, and having project managers bridge both worlds also helps. But those ideas are just being tested by major chipmakers. In the mainstream chip world they’re almost non-existent.

“Right now we only model the hardware and load the real software,” said Frank Schirrmeister, director of product marketing for system-level solutions at Synopsys. “But we do have IP models, and keeping those models in sync with the rest of the design is a problem. Even being able to keep IP models in sync with the correct version of IP is not always trivial.”

It’s particularly troublesome because SoC makers increasingly are being called upon to develop not just the embedded software, but also to make sure the operating systems and application software functions correctly on a device. Cadence’s whole push into EDA360 revolves around starting from the software down instead of the hardware up. But that also means creating models from the top down that don’t exist today, and potentially integrating them with the models that do exist.

“One of the challenges is that you may make changes in the TLM that are not reflected back to the overall spec,” said Schirrmeister. “You need to make sure everything stays in sync, whether you update that manually or automate it by connecting the TLM with the implementation model. About half of the users of TLMs rely on software to verify the surrounding hardware, so that becomes the link between the TLM and the implementation world. But not everyone is using TLMs, either.”

Opportunity knocks
Many of the large IP providers, such as ARM, Denali (soon to be part of Cadence) and Virage Logic (soon to be part of Synopsys) are keenly aware of the need for sharing information among various models. But Mentor’s Matalon said that to effective, tools are needed to capture the user’s intent and translate it into models that are TLM 2.0-compatible.

“Most design today is based on re-use and integrating IP, which is why the leading IP vendors are moving in this direction,” he said. “But that also means the platform creators need to change. Some of them are invested in legacy models and that cannot be re-used downstream because the use of legacy models is limited to one task. You need to use the same model for verification and power and build models that are scalable and can be re-used at the back end of the process.”

In addition, design teams need to understand how all the models fit together. And at each new node, where complexity is making models much more attractive, they also need a way of updating the changes made in those models. And while that seems intuitive enough, it’s a lot harder than it sounds.

The Power Of IP

Thursday, July 8th, 2010

By Ann Steffora Mutschler
As the number of design starts goes down the corresponding complexity of SoCs has gone up—and continues to grow. Everyone is looking at the value they can bring to the table as increasing proportions of SoCs are either reused from pre-existing IP within the company designing the chip or brought in from outside.

Because is economically impractical to start an SoC design from scratch, an estimated 70% to 90% of all new designs is re-used IP. This is making engineering teams choose very carefully what to implement themselves as their own value add and what to bring in from the outside. And that’s where the power issues begin.

“One of the big issues around IP integration is verifying the IP for the purpose you are using it for in the next design, said Pete Hardee, director of solutions marketing at Cadence Design Systems. “Putting IP in a new design with a different power intent means a lot of verification needs to be done and…the IP blocks themselves can be complex enough that they have their own power intent built into them. An IP block may have multiple power domains. It may have different supply pins for the different switched power rails that it’s got internally. It may not be clear which I/O pins are isolated and which ones need isolation.” All of these issues add up to a very complex problem when you’ve got power intent built into the IP block itself.

Some IP blocks have very complex power intent. Processors commonly implement dynamic voltage and frequency scaling, which is fairly complex, while memory IP (including embedded memory and off chip memory) often implements dynamic frequency scaling and sometimes multiple voltage, with the retention level possibly using some techniques like body biasing, Hardee continued.

Another issue in multivendor IP integration is that IP traditionally tends to be black box. “The IP vendor doesn’t necessarily want to share all the details of what’s in that IP. How is the power intent information, the power scheme that’s held with that IP block, communicated? Right now we see that there is very little support for that,” he said.

John Heinlein, vice president of marketing for ARM’s Physical IP Division, agrees there is an issue with different standards being used and at different levels. “On the one hand you have to ask what the design side criteria is being used by different vendors, and what the methodology was used to characterize power and performance. Having those standards be different may mean that there are inconsistencies when you bring together IP.”

Another problem is that different corners are employed for the voltage, temperature and environments being used. It is important that these be consistent in order to compare apple to apples, he noted.

Other challenges include support for different methodologies, support for a broad EDA ecosystem, and support for different process technologies. “At the physical IP level it’s fundamentally tied to a specific process and so you need to be able to support a broad range of process technologies,” Heinlein stressed.

Internally developed or sourced IP?
Given these challenges, one does wonder whether it is easier to integrate IP that is internally-developed or IP obtained from an external source.

“With internally-developed IP typically you’d have a lot more access to the history of that IP and every situation that it’s been used in. You’d have a lot more access to the full design files for it so you’ve got a lot more visibility into it,” said Cadence’s Hardee. “For external IP you’re in the hands of the IP vendors. A lot of IP vendors do a very good job. They are delivering their IP with the power intent file and we are working with all the major IT vendors to do that. But considering the power aspect of IP is another level of complexity that means if the IP vendor hasn’t paid attention to it and hasn’t done a good job, it’s going to be much more difficult for the IP user to integrate it and have it working correctly.”

Internal IP tends to be more customized and more narrowly focused for the users in-house infrastructure, its in-house EDA flow and methodologies, which has pluses and minuses, noted Heinlein. “On the one hand for their purposes that may be desirable. But on the other hand it limits their portability to other flows, it limits their ability to work with outside customers and partners who may need a different methodology.”

Once IP is obtained, design engineers sometimes want to use it in ways other than it was designed to do. Hardee noted that when this happens a different power intent could warrant the IP being switched off at various system modes and checking to make sure the isolation between power domains is correct. “I may be using an IP at a voltage level that is different from the one it was fully verified in. If I’m doing that I need to be aware of that fact—that I’m doing it by design and not by mistake. And if I am using the IP to implement any power intent that it wasn’t originally designed for I have to do all the verification to make sure that it operates as I expect it to in the new circumstance.”

Ken Brock, director of physical IP marketing at Virage Logic, echoed the comments. “People will try to use things as they were not intended.” Typically they hear from users, “Oh, we’ve got this particular memory and we want to use it at this very high-temperature,” even if it wasn’t designed to do that.

“At very high temperatures, very low voltages is where it mostly happens because people want to save power. Memories are very sensitive to low voltages, and while we go to great extremes to be able to provide the memories that run at the lowest voltages eventually they hit the point where they forget,” Brock said.

Because memories are more sensitive to power because of their cell structure, Virage uses foundry-supplied bit cells with design rules that are tighter than the regular ones. ARM likewise works with customers to provide characterization for those kinds of unique environments.

IP Integration Impacts Voltage
When it comes to IP integration, low-voltage support is important, has always been important, is becoming even more important, and must be “baked in” at the lowest levels of design, Heinlein said. “ARM collaborates with the foundries to make sure their low-level processes support the voltage operation. We’ve been taking a leadership position with foundries to try to drive the low voltage operation in the best direction for the industry. Too, you have to put circuit innovation and design innovations in place to support low-voltage operations and we are doing this as well,” he said.

With memories specifically, “you’re going to architecture memories in a specific way to support low-voltage operation. There are a number of things you can do there. In the case of logic, one of the things that happens with voltage is that you typically have multiple voltage domains in your chip,” he continued.

To deal with this, ARM has what it calls a power management kit (PMK) that is specifically designed to address the complexity needs and the circuit needs for chips with multi-voltage islands, incorporating things like level shifters to help facilitate connections between different voltage islands. “You can think about it like a power converter: It is an interface circuit that helps bridge between different voltage domains. Likewise, power gating is an important area and is becoming pretty much a standard thing for people using advanced SOCs to save power,” Heinlein explained.

Further, while mix-and-match may work well in the fashion world, one of the things that happens when low power and non-low power IP is combined in a single design is complexity as multi-voltage domains come together.

“One of the reasons you have voltage domains is if you have perhaps some IP that wasn’t designed, for example, for power gating or wasn’t designed to be powered down. You’ll tend to find power is managed at different levels,” he continued. As such, methodologies for looking at power in more and more detail continue to evolve and grow.

Tools, Techniques Help Bridge the Gap
To account for the challenges of integrating multivendor IP, moving up in abstraction can help mitigate the issues outlined above.

“The good thing that has come out over the past couple of years is the EDA vendor low-power flows that are characterized by Synopsys pioneering UPF, and Cadence, CPF which use two slightly different approaches to solve basically the same problem,” Brock noted.

“In doing that, it describes the intent of what you’re building so that all the tools that are looking at the IP know what to do with it… this was a very necessary step,” he said.

Another way for engineers to smooth the IP integration process is to start planning as early as possible. All of the major EDA tools vendors—Synopsys, Mentor Graphics and Cadence—have solutions for modeling power at the architectural level. That modeling now has to include power awareness in software, as well.

“Once you get into the netlist, you can optimize at the transistor level, you can optimize your clock tree, and you can do multi-threshold voltage optimization and various other things,” said Hardee. But it’s really the architecture level changes that make the big difference, and that’s where we need to make sure that you get the accuracy of estimation to be able to make the right changes.”

Getting Low-Power IP Integration Right

Thursday, July 8th, 2010

By Ann Steffora Mutschler
When it comes to integrating multivendor IP, power concerns dominate the challenges that engineers face. To get it right however, there are definitely questions that should be asked when considering which IP to use, along with techniques to manage power complexity.

When choosing IP, the following points should be considered:

  1. How mature is the IP being sold? Has this IP taped-out in silicon? What process and foundry?
  2. Or, if the IP is mature, how many customers are shipping ICs using this IP?
  3. Does the IP design team have high-speed design experience using deep sub-micron CMOS technologies with low supply voltages?
  4. Are there any customers that have used or are now using this IP? If so, can you contact them for reference and to find out if there were any serious problems with the IP?
  5. How was this IP verified? Has it been certified by any independent standards or compliance body?
  6. What are the current errata? Is there a plan to fix the current bugs? What is the vendor’s willingness to share such errata?
  7. What is the vendor’s track record in the industry?
  8. What level of support is the IP vendor willing to provide? Is the vendor willing to offer services to customize the IP for the application?
  9. What level of integration support is needed? Are there any special process options required, for example deep NWELL, thick metal for inductors, MiM capacitors or varactors?
  10. Has the IP been tested for ESD and latch-up robustness? Are ESD guidelines provided?

“Unless the IP being purchased is mature, it may contain bugs,” stressed Navraj Nandra, director for product marketing of analog/mixed-signal IP at Synopsys. “Due to the increasingly complex nature of IP, before any purchase is made the first step in doing due diligence on third-party IP is to determine the impact of the current bugs (and any other errata) on the intended application. Some bugs may only be present when specific features or configurations are enabled. If the bugs do affect the intended application, it is important to get a written commitment and schedule for their correction.”

Balancing performance and power
A significant aspect of the engineering effort occurs very early in the design process, when tradeoffs are made to balance power and performance. “Earlier on in the flow when you’re assessing macro-architecture and micro-architecture changes, it’s not a direct balance, but later on when you’ve fixed the micro-architecture you tend to see that it is definitely a balance,” noted Pete Hardee, director of solutions marketing at Cadence Design Systems.

“One of the biggest mistakes we see is to have a solution that is really trying to optimize for timing and what that does is try to eradicate skew in the clock tree. It will buffer not just the critical paths but lots of paths to get the maximum performance. There are many ways of deciding not to do that and only buffering the absolute critical paths with the faster, low-voltage threshold but higher-leakage buffers. You want to use those very sparingly and let the non-critical paths use the high-threshold voltage, low-leakage buffers. Basically, don’t try to fix a timing problem where you don’t have one. The same thing applies to the clock tree. You don’t have to eradicate skew everywhere to get adequate performance. It helps to have tools that are optimizing for timing and power needs at the same time rather than try to optimize for timing and go back after the event for power. We find that that doesn’t work that well,” he explained.

From Synopsys’ perspective, there is no compromise here. “You need the lowest power and best performance,” said Nandra. To this end, he noted that Synopsys supports all the popular interface and analog IP titles, with DDR as one such example. (http://synopsysoc.org/theeyeshaveit/2010/04/six-ddr-protocols-in-one-phy-not-for-softies/)

Further, finding the performance and power balance has a lot to do with the knobs and switches available in the silicon. “For a particular situation, finding the right set of those knobs and switches is, I believe, the art form,” said Ken Brock, director of physical IP marketing at Virage Logic. “We try to make those as easily accessible to designers as possible and so by releasing multiple variants—and again you can have covering all of the processes such as in 28nm TSMC for example they have an HP process and an HPL—the low-power version. Each one of those processes has three to four full-voltage thresholds that allow you to trade off power for performance. And then there is another dimension, which is gate length. That gives you yet another tradeoff. By having those two processes, each with three voltage variances and three different sets of gate lengths, you have about 18 different basic libraries and/or memories and each one has a little bit of a sweet spot trading off power and performance.”

Connected to this is guard banding, also called design margin, which concerns how closely you want to go to the edge of the cliff, he said. “Depending upon where people are in their risk profile they will go to various places. If it is a military/aerospace application, they are going to stay far away from the cliff. Likewise if it’s someone making a super scalar processor where there are only going to be 100 of them on the planet, they will go run a bunch of wafers and push it right to the edge and even overdrive the silicon—running it at a voltage above the standard voltage to get it another 15% or 20% faster.”

Staying within the power envelope
At the end of the day, staying within the allotted power envelope is the name of the game.

The system architecture can make a very large difference here, along with running blocks at different frequencies, running them as slowly as possible, shutting everything down when possible, putting the memories to sleep when possible when they are not being used – all of these techniques conserve energy and can make major steps towards having the tightest power envelope.

Brock recommends that engineering teams work closely with their IP vendor at the architectural level when they are selecting their IP. “Don’t wait until the whole thing is designed and say, “Oh oops, I need ‘this’ kind of memory.”

The Week In Review: June 25

Friday, June 25th, 2010

By Ed Sperling
ARM took a new tack in its war with Intel. The company is working on a Green Cloud Services project using the ARM architecture in conjunction with Nokia, IMEC, EPFL and the University of Cypress to create a 3D package with low-power processing. This is particularly interesting in light of gamers using Intel Atom-based servers.

Along the same power-saving lines, Actel introduced its power management solution for its SmartFusion mixed signal FPGA, complete with a reference design and a configurator for power sequencing and trimming. Given Actel’s focus on low power in its other chips, this isn’t all that surprising.

Also on the low-power front, Virage Logic introduced a big update of the open source GNU and Linux toolchains for its ARC processors, which will soon belong to Synopsys. That puts Synopsys firmly into the open source world, as well, with interesting implications.

Arteris joined forces with other EDA and IP vendors supporting TSMC Reference Flow 11, this time with network on chip interconnect IP. This is more like networking the industry on chip.

eSilicon will provide logistics services and production operations to Ember and Pixim. This is an interesting extension of supply chain expertise.

Mentor Graphics rolled out its commercial embedded Linux platform for Freescale, building on a strategic alliance the two had signed in April.

Mentor also won a couple deals with Mindtree for its Questa functional verification and with Autoliv for machine programming.

Both Synopsys and Cadence trumpeted successes with their products. Cadence global services enabled a 65nm TD-LTE baseband chip from Innofidei, a company with operations in Taiwan and Beijing. Synopsys, meanwhile, demonstrated interoperability between DesignWare IP for PCI Express 3.0. The company also awarded the Tenzing Norgay interoperability achievement award to IEEE-ISTO. We’re not sure what the famed Sherpa had to do with interoperability, but congrats.

Next Page »