IP 集成挑战持续演变

Key Takeaways:

• Integration challenges go beyond making sure a block is properly connected. Semantic issues cause the most problems, and many are due to incomplete or bad specifications.
• Complexity, including increasing software content, makes keeping track of everything included in a design more challenging.
• Many designs are pushing power and thermal boundaries, and this requires a new layer of information that must be specified and tracked.

IP integration is not the most glamorous task in semiconductor design, but it often is one of the most troublesome. At the intersection of block-level verification and system-level interactions, bugs are often very difficult to find.

The creation of the Virtual Socket Interface Alliance (VSIA) in 1996 was, for many, the first time the notion of designing a system by integrating third-party IP blocks became a reality. Its charter was to unify and standardize the way IP was constructed, verified, delivered, and supported. The alliance dissolved in 2008, considering its work to either be complete, or transferring parts of it to other organizations that were more focused on specific pieces of the problem. Eighteen years later, the problem continues to evolve.

The idea was that each company should focus on developing the part of the design that was novel and unique, adding their expertise, and allowing the rest to be developed by domain experts.

“Ten years ago, a design may have had tens of IP blocks,” says Pedro Pires, SOS product manager at Keysight EDA. “Today, a company may have thousands of IPs, dozens of different versions of the same IP, and you want to make sense of all of this. In addition, they are much more configurable than they were in the past. With the increasing quantity and different types of data now required for each block, it is becoming very difficult to manage in an ad hoc way. “

This puts a lot of stress on verification. “The nastiest failures are almost never inside a single block,” says Ashish Darbari, founder and CEO of Axiomise. “They show up between blocks — message-dependent deadlock, credits that slowly leak away, a reorder buffer that gets corrupted, an ordering rule broken across a bridge. Each block passes its own verification, yet the system hangs because two teams read the same protocol rule slightly differently.”

Over time, the number of cross-IP issues has increased. “From an SoC point of view, it could be a lot of different issues, including address mapping, interrupts, coherency, QoS, security,” says Madhumita Sanyal, senior director for technical product management for HPC IP portfolio at Synopsys. “Then there are physical implementation scenarios like DVFS, dynamic voltage scaling for lower power. Plus, there is software and operating system interaction. If you consider a die-to-die IP, there’s interoperability. There is known-good-die package, signal integrity, power integrity, power delivery network, thermal coupling, telemetry, and so forth.”

While design size has steadily increased, that alone is not an indicator of complexity. “I may be designing a giant CPU with 32 cores, but that is just 32 copies of the same thing,” says Dean Drako, CEO of IC Manage. “It may have a giant cache on it. That is just one cell repeated 100 million times. The complexity is not always proportional to the size of the chip. They are complicated, but the complexity has not linearly grown with the size of the chips. The human brain can’t deal with it.”

What matters is how many assumptions a block makes about the world around it, and that number climbs much faster than size. “A UART needs a clock, a reset, and a register interface, and that’s about it,” says Axiomise’s Darbari. “A coherent cache, a CHI home node or a NoC carries hundreds of assumptions. There are ordering rules, credit contracts, limits on outstanding transactions, reset and power sequencing, address-map expectations and security attributes. On top of that come configuration parameters whose effects the datasheet often doesn’t fully explain.”

Increasing pressures
Many areas add to the integration pressures, such as badly written or incomplete specifications for the IP blocks. At the system level, there is increasing software complexity, power and thermal issues – especially when associated with chiplets, increasing analog content, and added complexity with licensing, geopolitical restrictions, and export controls. Each of these will be touched on briefly.

Bad or incomplete specifications: Specifications are notoriously difficult to make unambiguous or complete. “The information is oftentimes not complete enough to give you an accurate picture of how it’s going to behave under all circumstances,” says Keysight’s Pires. “Knowing the conditions in which the system is going to operate will probably help you, depending on the quality of the documentation of your IPs. It might be that the IPs have information that is relevant for that particular set of circumstances, and in that sense, knowing the circumstances where the system is going to operate will help you, but it might not.”

The problem is often discovered when a bug escapes. “The architect, the designer, the software team, the DV lead and the formal team all look at the same failure and see something different,” says Darbari. “Nobody can agree on what the system was supposed to do, because nobody ever wrote that down in a form everyone shared. Those differences of opinion were there from day one. They just surface two years later, often in post-silicon debug, when they are most expensive to fix.”

Software complexity: While some software is fully encapsulated and hidden from any external interfaces, much is not. “Even something as simple as a PHY has a significant software content,” says Synopsys’ Sanyal. “There is the boot firmware that will establish all the clocks, resets, and memory. Then the PHY has calibration firmware, which will do the initial calibration and adaptation, and it’s updated continuously. That driver needs to tie in to the operating system interrupt and the DMA framework, and the BIOS and hypervisor or coherency or IOMMU dependencies for PCI controller and stuff like that. These all extend the dependency to interrupt between topologies and operating system services and power management framework.”

These issues are problematic enough that the UCIe standard attempted to address it. “UCIe 3.0 standardizes how firmware gets downloaded early in initialization,” says Darbari. “The trouble is that the hardware is often only correct under some software assumption. For example, registers might have to be programmed in a particular order, or a field must never be written while a transaction is in flight. Those rules are rarely written down, and RTL verification on its own never checks them.”

The divide between hardware and software is wide. “The world of software and the world of hardware are very different, meaning different people operate on the hardware side from those that operate on the software side,” says Pires. “This includes firmware, software that ties deeply with the IP. The workflows and the cadence in which these two teams work are also different.”

Power and thermal: Controlling power is becoming a larger problem. “Power management has become a functional feature, and a major source of functional bugs,” says Darbari. “Every power domain adds states, transitions, isolation, and wake-up sequences. A block can be perfectly correct while powered on and still drop a transaction or hang a handshake when its neighbor powers down mid-transfer. Questions like, ‘Can this request be lost if that domain switches off while a response is outstanding,’ are classic formal problems. Simulation rarely lands on the exact cycle where it goes wrong.”

When power is consumed it generates heat, which in turn can alter the behavior of sensitive circuitry. “With power and thermal now driving SoC limits, analog IP can’t just sit there passively anymore,” says Chris Morrison, vice president of product marketing at Agile Analog. “We have to design it to actively manage the chip using embedded PVT sensors, timing monitors, droop detectors, and glitch detectors that feed real-time telemetry back to power management units to catch issues before they affect operation.”

Analog content: Analog content has always had unique challenges. “These IPs have a limited range of operation, and they’re very tailored to specific use cases,” says Pires. “While AI is helping in many areas, we are seeing a big challenge in creating AI automation to accelerate RF and analog design, because of scarcity of data. It’s not so easy to come by a good quality data set with enough volume that you can use to train an agent to do a specific part of your flow. It’s much more tailored, focused, narrow information, and oftentimes it is proprietary information not available for us to consume.”

Analog block creators are looking for ways to abstract their designs into a digital world. “Customers are increasingly asking for complete analog subsystems rather than wrestling with a dozen individual blocks,” says Agile Analog’s Morrison. “Simulating large analog subsystems in SPICE takes far too long at the SoC level, so verification can be simplified by insulating the IP with a digital wrapper. Doing the heavy mixed-signal lifting internally means digital SoC integration teams can take SystemVerilog real-number models (RNMs) early on and run full-chip verification within their digital environment.”

Chiplets: Chiplets can be viewed as a new physical delivery mechanism for IP. “Chiplets magnify that issue and make it a supply chain integration issue too,” says Frank Schirrmeister, executive director of strategic programs for system solutions at Synopsys. “You not only have the IP issues, but you move the design up from the SoC boundary to the packaging boundary. Now it turns IP integration into supply chain integration. You’re not only integrating the designs, but you’re also integrating all these bits that may come from different companies, nodes, and foundries, and they all have their own verification methodologies at the IP level.”

None of the integration issues go away. “NoCs are now being stretched across die boundaries, so several dies look like one fabric,” says Darbari. “UCIe is handling the physical and link layers well, and cross-vendor interoperability is being demonstrated. But a working link doesn’t make a working system. You still need agreement on address maps, coherency models and software, and those are exactly the semantic questions standards leave open. The specs now include DFD, DFT, and DFM, and manageability, so a chiplet starts to look less like a passive block and more like a small system with its own management firmware.”

Chiplets need even more information than an IP block. “There are now multi-physics coming into play, which means that you need a whole lot more information about the IPs that you’re managing,” says Pires. “It’s just becoming unwieldy to have all of this data together. It means more complexity that travels with your IP. For example, the power intent needs to travel with your IP as an additional artifact.”

Verification: With IP, and even more so with chiplets, visibility into the block makes verification more difficult. “Large IP increasingly arrives encrypted, so you can’t read the RTL to work out what it really expects,” says Darbari. “You’re left with the documentation, and in my experience that is often where the bug is. These blocks are also shipped as generators rather than fixed designs. The vendor verified some set of configurations, but you are probably taping out a different one. With more than a handful of parameters, it is very easy to land on a combination nobody tested.”

The good news should be that not every capability of an IP needs to be verified. “Identifying the legal subsets of functionality is an architecture and verification task,” says Sanyal. “It’s not one-size-fits-all that can be automated. If you look at the verification aspect of it, there are now AI models that we are using, our customers are using, to get into those corner cases faster than before. It’s getting into the verification part of it.”

Version control
Very few things are perfect on the first attempt. Bugs will be fixed after the initial release. “The non-AI version is this is about IP lifecycle management,” says IC Manage’s Drako. “With AI, those life cycles may move faster, but you still need to manage those lifecycles. And maybe you can ask AI to do it for you, but you must have the data and the systems in place to keep track of it, know what you taped out, know what you built, know what was used where, which IP was used where.”

Hardware and software ship and update on different schedules. “A firmware update in the field can change how silicon behaves after it was signed off,” says Darbari. “Interrupts, power states, DMA buffers, and security attributes are shared between hardware and software, and conflicts tend to surface at bring-up when the first real driver runs a sequence nobody specified.”

Hardware and software generally use different mechanisms for version control. “The challenge has to do with integrating all of this data within a single system,” says Pires. “A specific version of your hardware needs to correspond to a specific version of the software, and this is a link that exists often in Excel spreadsheets, which is messy and error-prone. When you are integrating a system, you need to manage the configuration itself, like the bill of materials for a specific system, the specific combination of components that you have in a system. Every time that you do a change to it, you need it to persist. You need to save it so that you have that traceability aspect.”

Conclusion
It might seem as if this is a growing cause for alarm. But like most problems within the EDA space, as a problem grows, so does the attention it receives, and the investment in the problem ultimately leads to better solutions.

“The management problem is growing, but also the mechanisms to address the problem evolve alongside it,” says Pires. “In relative terms, the pain remains constant, but the problem underlying it is a bigger one.”

Editor’s note: A second part of this report will examine recent improvements and how AI is being used to improve the selection, configuration, and integration of IP.

Related Articles
Accelerating IP Reuse
How to put 1,000 pieces of IP into a chip design and make sure they work together.

Vertical Integration Becoming Pervasive
No system can be optimized without an understanding of both the hardware and software, and making the right architectural choice requires cooperation.