Moving to the next process nodes will produce volumes more data, forcing chipmakers to adopt more expensive hardware to process and utilize that data, more end-to-end methodologies, as well as using tools and approaches that in the past were frequently considered optional.
Moreover, where that data needs to be dealt with is changing as companies adopt a “shift left” approach to developing software, and verifying and debugging the chip. It now must be considered much earlier in the design flow. But combined with an increase in the number of transistors and complex IP blocks, more design rules, multi-patterning, and many more standards, even the best-equipped organizations are finding themselves swimming—and sometimes drowning—in data.
All of this makes it harder to optimize chips for performance and power, as well as ensuring that enough corner cases are included to have confidence that a design will turn out as planned, that it will perform reliably, and that it can be manufactured with sufficient yield.
Architecture
This data explosion stretches from one end of the design process to the other, and well beyond that, and it affects every facet of chip design along the way. Architects used to be able to visualize what functions needed to be included and then hand their specs off to designers. There are now so many choices, rules and considerations that many engineers question whether new chips will work at all—particularly when it comes to ECOs, new processes and transistor types, and the integration of more IP from more sources. That often leads to panic before signoff and extra costs for debug and verification, so the chips do function correctly, but that approach doesn’t always produce optimal results.
“To optimize a design, the architect really has to know what they want up front,” said Kurt Shuler, vice president of marketing at Arteris. “But it’s becoming a real bear because with each node they have more and more data, more and more libraries at each new node.”
This is particularly apparent as chipmakers shift from homogeneous multicore processing to heterogeneous cores in an effort to reduce power and right-size a chip’s resources to fit a particular application. “As we move into heterogeneous computing, you’re creating data based on one read or write, but you’re dealing with up to 10 coherency messages saying, ‘Where is the data?’ You’ve got more reads, writes and load stores, and more metadata above that. And that’s where the real complexity comes in. If the data isn’t consistent, then you risk reading dirty data as if it is correct.”
Designing for this is a challenge in its own right. Optimizing it in a rising tide of data is an even bigger problem.
“Automation is the key here,” said Sundari Mitra, CEO of NetSpeed Systems. “Humans are good at analyzing to a certain degree, but if there is too much data they make mistakes. We need algorithms and machine learning. Right now we use judgment and make calls. And we need this at every step. You have to make intelligent decisions about which IP blocks to use and how to put them together. You don’t want a powerful processing engine with a weak memory controller. Everything has to be matched, but it’s being optimized with too many constraints.”
That often leads to overdesign, which can negatively impact performance, power, as well as area.
“With legacy design, it was all spreadsheets. You could tweak them, and even then there was a lot of room for lapses,” said Mitra. “Heterogeneity kills you. An incremental change can have a ripple effect.”
It also produces results in even more data, which in turn leads to the need for higher levels of abstraction and more automation.
Implementation
How and where to apply automation across different segments in a design flow isn’t always clear, though, particularly as more things need to be considered at the same time. This is basically a big data problem, but with a lot of dimensions and dependencies.
“While there’s certainly a lot of promise—and corresponding hype—about big data, the fact is that it’s not an easy fit for chip design,” said John Lee, general manager and vice president of Ansys. “The easiest fit for big data is what I call ‘log file mining.’ It’s easy to harvest log files and report files from EDA tools, and process those results, such as tracking DRC violations or timing convergence across multiple groups and projects. But this application has relatively low value to customers and can usually be done without real big data architectures. The harder fit is to make big data actionable. In customer terms, actionable means something that fundamentally improves performance, cost or reliability. Actionable data requires multi-domain analytics.”
This would include such areas as power integrity, timing, routing, and reliability analysis.
“When you map it out, multi-domain analytics requires that you do a serious amount of scientific computing, such as logic/timing graph traversals, circuit matrix solutions, geometric searches,” Lee explained. “So big data also requires ‘big compute.’ But big compute has to be done in a way that customers can afford.”
Verification and debug
What’s affordable is a relative term, often defined by specific markets and sometimes for the same market at different times. A maturing smartphone market, for example, is going to be far more cost-conscious in design than a market that is on the upswing and which can leverage one design for billions of units. Likewise, equipment in data centers may be more price-sensitive if the application is not mission-critical, and an automotive chip may have more perceived value if it is used for a unique competitive advantage rather than one where there is more competition.
That has a direct bearing on what companies are willing to pay for tooling to get chips out the door, which is why companies typically use a mix of simulation, emulation and FPGA prototyping to verify their designs rather than buying only emulators. But as the amount of data continues to rise, they also are recognizing that technology needs to be applied more efficiently and effectively, no matter how resource-rich the engineering organization may be.
“The challenge is how to verify in the environment in which this is being used,” said Jean-Marie Brunet, marketing director for Mentor Graphics’ Emulation Division. “It’s the same script environment, but it’s time to verification within the context of a live application. It’s no different with power. You verify in the context of how that power is utilized.”
This is harder than it sounds, because to get to that point requires processing huge amounts of data earlier in the design cycle. “In networking infrastructure, you have to look at the traffic being run through a switch or a router,” Brunet said. “Post-silicon is too late for that. It has to be done pre-silicon with simulation or emulation.”
Lauro Rizzatti, an independent emulation consultant, agrees. “The addition of embedded software to the hardware design mix creates large data sets that need substantial verification resources to analyze and debug them,” he said. “Hardware emulation has the ability to debug big data, including embedded software, when other verification tools can’t. It offers an accurate representation of the design before silicon availability, since it is based on an actual silicon implementation. Today, processors with embedded graphics and networking chips approach 1 billion ASIC-equivalent gates. Add to that the embedded software that would require billions of verification cycles for exhaustive testing. This setup leads to a great deal of data that needs to be sifted through and analyzed.”
That’s one slice of it. Formal verification is gaining in popularity as the amount of data grows, as well. Long ignored, misunderstood, or underutilized, formal has turned out to be a highly efficient use of verification resources.
“Verification has always been an issue with big data,” said Dave Kelf, vice president of marketing at OneSpin Solutions. “Engineers get a mass of data and they have no time to go through it all. If a chip doubles in size, there is a massive amount of new data. And now physical effects are making their way into verification.”
Kelf said that formal is basically a huge database, and as security issues become more pronounced—and produce their own volumes of data—it’s being used to transition between states that can be used for side-channel attacks. “What you’re doing is characterizing the propagation of information through a device. So is there is a secret key, you can propagate that through a device on every signal the key goes through. The formal tool figures it out. This is big data. What you’re doing is monitoring the path directly. It acts like a big filter. The machines are powerful enough to handle this, and big data is contained in the database.”
Conclusions
Whether these kinds of issues can be avoided in the first place is debatable. Correct by construction proponents have argued for years that one of the reasons there is an explosion of data and the need for so much verification is that design methodologies are flawed.
“People try to search for the needle in the haystack,” said Anupam Bakshi, CEO of Agnisys. “Why put the needle there in the first place? For example, debugging through deciphering information from a large log of messages can be avoided and the whole debug step eliminated if a proper specification-driven methodology is followed.”
No matter how good the design methodology and execution, though, there is no question that the amount of data that needs to be considered by design teams is on the rise. There may be less in a perfect design, but there will be more at each new node. While this is good for tools vendors in the short-term, the bigger question is whether some of this data can be handled more effectively through other means, such as platforms, subsystems, advanced packaging of discrete elements, and a revamping of some of the silos within chipmakers to deal with data at different points during the design flow.
Still, the challenge isn’t the ability to process all of the data. The problem is how to use all of this data more efficiently, ignoring what is not essential in one part of the design while understanding that it may be useful somewhere else in the flow. In effect, what is needed is a comprehensive understanding of all of the data being produced and how it can be used for maximum effectiveness at what time and by whom. This is the equivalent of architecting the data behind a chip design, and so far no one has effectively tackled it.