Over-Design, Under-Design Impacts Verification

Designing a complex chip today and getting it out the door on schedule and within budget — while including all of the necessary and anticipated features and standards — is forcing engineering teams to make more tradeoffs than in the past, and those tradeoffs now are occurring throughout the flow.

In an ideal system design flow, design teams will have done early, pre-design analysis to setup appropriate constraints. As the design progresses, they can test against those constraints, as well as perform fast, first-pass analysis to make sure no glaring problems are being designed in. But every design needs to go through some sort of signoff and optimization phase. This requires experience, computing resources and time. If you rush through, or under-design, quite often prototypes will fail to meet specification. Or even worse, those designs may be released into the field with quality/reliability issues, according to Brad Griffin, product management group director, multi-physics system analysis at Cadence.

Once a design team has been through this trauma, they may swing the pendulum too far in the other direction. “Not only will they design to all the constraints, but they may choose to ensure there is extra margin,” Griffin said. “This may mean using more expensive components or extra layers, which results in a higher product cost. The results may be a higher quality product, but the excessive cost may erode all the profits of the product.”

Analyze the needs
An efficient system design flow analyzes early and often during the design process, Griffin stressed. “The schedule must allow for the signoff and optimization phase to actually look for ways to shave cost off the design (i.e. decoupling capacitor optimization) and still end on a predictable design schedule. Design teams using integrated design and analysis tools from a single EDA vendor tend to have the most success pulling off this tricky balancing act. Meeting the design spec at the lowest possible cost is what helps increase profits and meet market demands ahead of the competition.”

Consider an interconnect, for example, where communication bandwidth needs to be managed so no performance bottlenecks occur. This is particularly important as more intelligence is added into devices and more processing needs to happen locally, but sizing the interconnect correctly is tricky.

“For deeply embedded applications with deterministic workload, like a smart security camera, the traffic streams can be handled explicitly, such as by prefetching data for known traffic patterns with DMAs and memory buffers,” said Tim Kogel, principal applications engineer at Synopsys. “In this case, the interconnect can be optimized rather tightly for the predictable traffic requirements. On the other side, the applications running on open devices, like a mobile phone, are not known upfront, so the actual interconnect workload is difficult to predict. Here it is prudent to provide more expensive mechanisms that can dynamically accommodate different traffic requirements, like caches, cache-coherent interconnect, QoS regulators, etc. Even in this case, it is still important to analyze power and performance of critical use-cases, such as mobile browsing of a Facebook livestream with embedded videos.”

Wade through trade-offs
At the next level, many detailed design decisions are related to the configuration of interconnect design parameters, such as topology, data-width, clock frequencies, buffers. Here the tradeoff is typically that higher performance can be bought with bigger area, higher power consumption, and potentially physical implementation issues.

As devices become more complicated, every solution has one or more tradeoffs, and this is apparent with interconnects:

• Wider data paths and higher clock frequencies increase the bandwidth, but entail higher power and potentially timing closure and wire congestion issues.
• A deeper transaction pipeline improves throughput by hiding long memory access latencies, but increases register area and power.
• Cache-coherent interconnects have further tradeoffs, including cache sizes, directory vs. snoop-based coherency protocol, central vs. distributed directories, etc.
• For mobile devices the energy consumption is an important additional vector in the tradeoff analysis. In many cases, higher performance leads to higher power consumption, but the energy consumption to execute a use-case might still be lower because the device can return sooner to a lower power state.

Early planning with system-level analysis is crucial.

Analyze the whole system
“System-level analysis doesn’t just tell you if a design is working,” said Neil Hand, director of marketing for the Design Verification Technology Division at Mentor, a Siemens Business. “It will if you have over-designed this or if you have under-designed it. If you’ve over-designed it, you can back off some of the performance requirements and reduce the cost of the system. Let’s say you find out you’ve built in 3X overhead. What do you do with that? You could back off the clock speed. You don’t need to run the clock speed as high. This gives the synthesis tools the ability to implement using less area. You could also decide to remove some components, such that maybe you don’t need four cores, or maybe you can keep them as dark silicon for now. The same tools that let you understand if you have you hit performance from a verification perspective, you can also use to identify potential performance tradeoffs.”

In one case, a design team added some custom instructions and custom memory fetches to an embedded processor, and suddenly the processor was much faster than the previous processor, and they were able to use an older process node. They got a much less expensive processor because they went to two or three generations older in the silicon implementation. That also  gave them a better power profile because there was less current leakage. The only way they were able to do that was by doing performance analysis of the embedded processor in a system context.

“At the same time, in this upfront analysis, pre-tapeout, you have to have the right methodology to enable it because if you just turn around and tell someone to run everything in emulation, that’s not going to work,” Hand said. “The amount of effort that’s going to be involved in getting the system up and running is very high so you want to get in there as early as possible because if you leave it too late, A) you can’t fix it; or B) you can’t do the tradeoffs, so you end up over-designing, and you never want to over-design. But people would rather over-design than under-design, so they just throw more resources at it, and if it blows out the chip area, so be it. Whereas if you can do it earlier, you can see that you didn’t need all of that extra stuff that you put in.”

Who can future proof via over-design?
Companies that can afford to manufacture chips at the most advanced nodes may be the ones that best can afford the wiggle room to over-design. Today, these are the large systems companies.

Hand believes this has always been true of the market-leading systems houses. “They can throw resources at it, they can afford to throw as much in there as possible where their competitors can’t. And because they’re a system-level house, they have a different financial burden. As you look at high-performance embedded processors in terms of system-level analysis and system-level design, it’s really the system design houses that get most of the benefit because they have a fully closed ecosystem that they control. They control the applications, the OS, the hardware platform, and they can do top-to-bottom optimizations. These companies have the ability to integrate across the full supply chain, which gives them a significant advantage. While they can absorb the cost of over design, no one can afford the cost of under-design because with under-design, they lose customers, their product doesn’t work, they lose the market opportunity. If you don’t have access to the technology and the methodology that you need to right-size the design, by default you’re going to over-design because that’s your only other option.”

While over-design adds cost and potentially performance and power overhead, under-design can negatively impact reputations and market share. This is why design teams spend so much time on verification and debug, and why may spawn a whole other round of tradeoffs so late in the design process. And it’s also why design teams are putting a heavy emphasis on more planning earlier in the flow.

“You need to be sure how to go about designing for your use case, and usually it’s the verification where people tend to be in two minds whether to keep on verifying or when to actually stop verifying,” said Shubhodeep Roy Choudhury, CEO of Valtrix Systems. “There are a lot of guidelines available with respect to coverage completion and verification goals at the beginning of the project. Usually, when all of the regression goals are complete and coverage requirements are met, you can pretty much call it done. Further, nowadays everything is pretty well streamlined in terms of when to enable what. There are specific design cycles, after which you need to spend some time on an emulator and FPGA including making sure that the software use case is getting enabled before launching a bunch of IP into the market.”

Follow the market forces
Everything is guided by time to market — even the number of features that you would like to put in a design. “Everyone has a long list of what they would want to implement, but it might not be practical, so you need to figure out how many features you can actually implement and what the end use case really needs. On the basis of that, and on basis of what kind of verification complexity it introduces, you need to figure out the entire project plan,” Choudhury said.

So where to start? Darko Tomusilovic, lead verification engineer at Vtool, said that will depend on whether you know exactly what application you will be creating your chip for.

“Most markets for chips are fast-moving, so you’re never quite sure that requirements which were set for the application when you started designing the chip will be the same at the end of the design and verification cycle,” Tomusilovic said. “This dynamic pushes designers to include more functions than are actually needed at the time, as there is pressure to look forward and get ready for changes in standards, changes in protocols, or changing speed requirements. They do this in hopes of not losing that time during which other components in the application get upgraded, and not putting a product on the market based on an old standard.”

Unlike in the past, where many steps in the design-through-manufacturing flow were discrete, they now are much more tightly integrated. In fact, often they overlap, which means that tradeoffs can extend beyond the traditional boundaries of design into manufacturing, and vice versa.

“Something you may think has too much logic might be there just because it turned out to be cheaper than to produce two or three flavors of one chip doing full verification, full masks and the whole packaging lines,” said Tomusilovic. “Sometimes it’s just plain cheaper not to use some features than to manufacture a lot of them. Case in point: When AMD came out with the dual-core processors, those were quad cores with the two cores turned off because the line was already set up and nobody cared to pay for the expenses for the shrinking market of dual cores. From the designers’ perspective, it’s more about a bean counting decision than it is really of architectural or designer impact.”

This gets tricky when market requirements change rapidly. If you need to make an adjustment to an interface or the bandwidth, that can have a big impact on the design. Sometimes it can be like hitting the restart button.

“Sometimes you lose the opportunity, but sometimes if you are entering a market where standardization is already set, you can rely on the fact that standards will not change easily and you can maximize the chip only with the necessary functions,” he said, noting this is less common. “More often it’s general-purpose, and verifying a general-purpose chip can add a lot of additional complexity, which is not usual in some digital chips that have a target. What it can add is a lot of complexity from creating parametrized designs that can support many different configurations. So rather than have, let’s say, a single design, we actually need to verify a pool of IPs. In that case. the verification environment needs to be aware of all these parameters and handle all of them. This comes with an additional set of analyses, such as code coverage analysis and functional coverage analysis, because you cannot even define a meaningful code coverage for a single version of RTL across a multitude of different design chapters. Then you need a set of regressions, which will each target a different version of an RTL. That added complexity may be two to three times compared to usual designs, just due to the fact that you need to take the complex parametrizations into account.”

This is a delicate balance with big risks.

“It’s a big risk to be late to market. If you overdo complexity with redundancy, you’re never going to finish it,” said Aleksandar Mijatovic, senior design engineer at Vtool. “There are two sides of the risk here. One is to be over-simplistic and actually not be able to put a competitive product to market. The second is to support everything that somebody might want to use, and actually never finish the chip because you added too much complexity in order to get the design and verification manageable in reasonable time.”

As a result of these pressures, legacy blocks are often left in a design, even if they are not used in a certain spin of a chip, Tomusilovic said. “We have tended to leave them there and not deal with removing them from the RTL. But now, since there are safety requirements and safety standards — especially in the automotive industry — it’s not a luxury you can have anymore. You cannot have even a single line of code in the RTL that is not properly analyzed, properly exercised and defined. Otherwise, you might fail the standardization.”

Verification automation, modularity
To account for different flavors of a design, some companies have started to build design and verification environments to support automatic generation of design and verification.

“In that case, you need to invest a lot of time in advance, and you need to have a clear picture of the flavors of the chip for the next few years,” said Olivera Stojanovic, senior verification engineer at Vtool pointed out. “You also need to think about a modular way of approaching verification [such as UVM]. In some cases, it is very hard to see what can be changed in the future and what can be configurable. That is the main issue. Even if you predict certain things, if at some point they decide to change something, you need to invest more time in each generation. This approach helps some companies to be competitive in the market to be very fast, although they do lose some time in the beginning to set it up.”

Also with a modular approach, overhead must be built into the design. “If you want modularity you need to add overhead for features, both in design and in verification, which could have been integrated in one piece,” Mijatovic said. “You split it in smaller blocks, do all the interdependencies, and actually try to separate the different functionalities both on the design and the verification side. Then there is interoperability in separate blocks, so that you can easily change one or the other.”

Ultimately the verification environment should serve the design under verification, but in many occasions, ‘reuse’ comes in, observed Sergio Marchese, technical marketing manager at OneSpin Solutions.

“One may try to re-use an existing verification infrastructure that may not be a good fit, perhaps to please a manager that need to show the effort savings delivered from previous investments,” Marchese said. “But a few late bugs, or even just a missed one, can quickly overcome these savings. On the other side of the spectrum, the temptation to justify the additional effort of over-design with the claim that building a more flexible, reusable verification environment will eventually pay off, is also risky.”

Marchese suggested having a close EDA verification partner, rather than just tool and service providers, is a strategic advantage. Generic verification solutions can be customized to cover the needs of a new design flow or family of projects, while also delivering a level of quality and continuity that matches mature products.