Data Coherence Across Silos And Hierarchy

Shift left has become a rallying cry for the chip design industry, but unless coherent data can flow between the groups being impacted, the value may not be as great as expected.

Shift left is a term that encompasses attempts to bring analysis and decision-making forward in the development process. The earlier an issue can be found, the less of a problem it ultimately becomes. But in many cases, the action being brought forward is performed by a different group of people, sometimes in another time zone or country and with different skill sets. Although both groups may wish to work on the same data, they may not want to see that data in the same format, or at the same level of abstraction.

This problem is compounded when looking at other aspects of development flows that are changing. Shift left is not the only thing happening. We also have extend right and stretch sideways.

Extend right means that a chip is no longer finished when tape-out is done. For example, many chips contain circuitry for diagnostics or analytics that can be used to show how well a chip is performing in the field, or to aid in things like reliability analysis. Some of that circuitry also may be used for manufacturing or in-circuit test. Runtime analytics becomes part of a large feedback loop that is used to influence the next version of the chip. The electronic system also may need to become part of a much larger digital twin.

Stretch sideways includes additional analysis that needs to be performed for certain verticals. For example, in automotive, safety and security are important elements of the development flow. This brings in additional disciplines that traditionally have been taken care of by separate groups of people.

“It is a hierarchy, and you have silos within that hierarchy,” says Chris Mueth, new opportunities business manager at Keysight. “On one end you have people who are tagged with the responsibility of being system architects. They are doing high-level modeling, but they need to interface with people who do lower-level designs. That could be analog or RF, it could be device modeling, or those with electromagnetic specialization. Specialists are really good at what they do. You need these people to work together. You have to merge the data, and you have to communicate.”

As 3D-IC becomes more widely adopted and third-party chiplets become a reality, new models and abstractions will become vital. “Hierarchical modeling is becoming very hot, given that the traditional way of verifying a chip is not working anymore,” says Lang Lin, principal product manager at Ansys. “Today, the chip is not always sitting alone within the package. It can have a neighbor chip. It can have 20 chiplets sitting in 3D stacks. The traditional way of validating a single chip before tape-out no longer works. You must consider the environment, and that may include 20 other chips. My focus may be one chip, but for the others, you need reduced-order models. You need hierarchical models.”

Put simply, data management approaches will vary. “Managing hierarchical verification data involves transferring data across various stages of chip design and verification,” says Insaf Meliane, product management and marketing manager at Arteris. “This process includes data generation, abstraction, and iteration to manage multiple aspects such as functionality and power consumption.”

This becomes harder when teams are distributed. “The silo problem has become bigger, more complex, more compounded, because the data is often sitting somewhere else,” says Simon Rance, director of product management at Keysight. “Nobody knows where it is or if it has been duplicated. We’re seeing complexities from different design domains, concurrent verification, different workflows, different tools in the process, and the handoff of data between these tools, importing them and exporting them in and out. We’re hearing about a lot of security concerns, not just about the data itself, but who has visibility and access to what data, and that’s becoming a management problem.”

Too much or too little data can cause problems. “Designers would love to minimize data, because it is your biggest enemy as well as your biggest friend,” says Suhail Saif, principal product manager at Ansys. “It helps you make the right decision, but as the amount of data increases exponentially, it becomes more difficult and confusing to handle that data and still keep the analysis meaningful.”

But it also has to be the right data. “Depending on the use-model, individual teams often create the data they need, but it may not have been holistically planned,” says Frank Schirrmeister, executive director for system solutions at Synopsys. “They often depend on the fidelity of the tools that use them and the abstractions that are connected. For example, architects will create data supporting architectural decisions, only some of which will eventually be physically connected to confirm these decisions later.”

Verification hierarchy
One of the biggest changes involves verification hierarchies. New languages are enabling system-level vector sets to be generated, while at the same time software workloads often are being used to ensure that real scenarios are covered. Those vector sets are not just testing functionality. They are being used to understand power, thermal, and even mechanical stress across the entire SoC and package.

“We see the need to embrace things beyond RTL simulation,” says Matt Graham, product management group director at Cadence. “Coverage needs to come from multiple sources. How we manage this problem and bring it all together is being solved in a number of different ways. Some people do it ad hoc. Others are using tools that use formats and databases to bring all of the data together.”

Both top-down and bottom-up flows need to be connected. “Hierarchical data is useful for low power intent, verification plans, coverage, and lint reports,” says Taruna Reddy, principal product manager at Synopsys. “Data can be passed from the lower-level IP blocks to the top-level blocks using a black-box or sign-off abstract model (SAM) flow. In the black box flow, as the name suggests, the data is abstracted and only the boundary ports are visible. The SAM flow gives the best QoR by retaining enough logic needed from hierarchical modules, while the performance of the runs would be better than flat runs. This flow enables top-level integrators to focus on top-level violations and integration-related issues, and not worry about violations deep inside the hierarchical blocks that block owners would take care of.”

Verification has to become more structured. “Systems needs to have well-defined use models, so you can generate the appropriate vectors or stimulus, and generate the right power profiles or thermal profiles so you can feed that back into that entire process,” says Cadence’s Graham. “That’s going to require vectors or stimulus at many different levels, including the system and including multi-die. With these massive systems, we’re going to need to be able to generate vectors at the system level, such that we can do things like dynamic powers assessment, so we can virtually glue them together in terms of a larger digital twin, and so we can get reliable data at both ends, the top end and the bottom.”

Another change feeding into this is that worst case is often not the design goal. “The industry used to heavily rely on synthetic vectors,” says Ansys’ Saif. “Synthetic vectors are used when the chip designer uses his knowledge to say this piece of design will be stressed for maximum power or maximum performance in these particular scenarios. It’s a stress condition. Those were used predominantly to do power analysis, thermal, stress analysis, assuming that this is the worst scenario we are simulating. Instead, you pick the most popular, realistic scenarios, and this is what you should be optimizing your design for. This avoids over-margining. When you put your design into a stress situation that might happen only 1% or 2% of the time, and you optimize for that, you are leaving a lot on the table.”

How vectors move between groups is changing. “In between hardware emulator and the thermal, or mechanical analysis tool, there’s a new step, which is called vector profiling,” says Marc Swinnen, director of product marketing at Ansys. “This analysis step takes huge vectors and chops them into pieces. It may then determine the average for each piece. It could identify where the gradient is steepest, because it may need to do finer chopping. Where the gradient is gradual, it can make bigger leaps. What you hand off to the analysis tool is a much simplified, pre-analyzed picture of the activity, rather than the fine detail of every single node changing or every single time step. That’s a very important step between the source of the vectors and the use of the vectors.”

Team structure
All engineers need to become more aware of what is above them and below them. “Engineers are very specific,” says Keysight’s Rance. “If they are a digital engineer, they probably have little to no clue about the analog design tools. All they care about is RTL synthesis and simulation. They don’t want to learn another domain, but they have to interact and work with them more so than they ever did in the past. There needs to be more experts who are multi-discipline, especially with chiplets.”

This also is true for the verification team. “Twenty years ago, there were verification engineers,” says Graham. “Then we had formal verification, which required a formal expert to operate the tools. As the tools associated with formal became more applicable, any verification engineer could then use them. Today, a lot of customers talk about the SoC verification group, or the system-level verification group, or the top-level verification group, or the IP-level verification group. We do see stratification, but as things like portable stimulus (PSS) become more widely deployed, that kind of system-level capability becomes more accessible. Then there will be reunification, and possibly a stratification into something else, possibly the digital twin expert.”

Concurrent engineering is essential, as well. “When we’re getting into system-level workflows, which is what we’re facing now, you have multi disciplines and specialization,” says Keysight’s Mueth. “Even on an analog chip, you might have an RF expert, you might have an EM expert, you might have a thermal expert, a circuit expert just on one particular thing. All these disciplines need to work together, concurrently, and efficiently. You’re bringing in acoustics, vibration, you’re bringing in thermal, structural dynamics along with the electronics. These people all speak different languages. There’s an interpretation required.”

Some changes are becoming essential because additional concerns are impacting larger portions of the flow. “More than the physics or the expertise problem, it is often an organizational problem,” says Ansys’ Swinnen. “The person they need does exist, but he’s already assigned a manager who’s in a different group and who has different responsibilities. You need to rejigger your organization managerially, which is often more difficult than physics. They always hoped they could adjust the physics to the management chain rather than the management change to the physics.”

Top-down, bottom-up design and development flows are under pressure. “There has to be an agreement as to what data exists, how it flows, and how it gets used in a context, because you have to verify it,” says Rance. “This has to be top-down for it to be meaningful, especially in the big system context. For example, in an automobile you need to make sure that the sensor system is getting the data correctly, and that it is being fed into the main processing units for autonomous driving decisions. You can design each of these sensor pieces bottom-up, and that’s how it is being done today, but it needs to be verified top-down so you get that entire context. In industries like automotive, they want to bring in real data that shows what is happening in the field, showing how it is performing and how it is behaving. The next version of the design, perhaps even a software update, can be honed to improve the vehicle. When chip designers tape out, they think their job is done, but for automotives, there is a five plus year life expectancy in terms of tracing all of the data and performance.”

Derivative data is becoming more common. “Abstractions can be defined using IP-XACT, which allows for the encapsulation of complex data into manageable models,” says Arteris’ Meliane. “Many teams want a ‘single source of truth’ environment where design data is centrally managed and accessed. This setup ensures that any updates or changes to the design are immediately available to all team members across different departments. IP-XACT eases the collaboration by providing a standardized way to package and communicate complex IP data to ensure a robust design.”

Using real-time data is creating new feedback loops. “Those loops vary heavily by project and often do not affect the current project,” says Synopsys’ Schirrmeister. “The data only feeds into the next revision or project. An example may be an architect team that finds a performance or power optimization issue that requires a functional or partitioning change. That change can no longer be in the current project but makes the list for the next.”

Conclusion
There are many changes that are possible in these flows. “Flows run on data, so the aggregation and correlation of all that data from multiple places will become more important,” says Graham. “Can the EDA industries start to automate the creation of models from the data with AI? Can we automatically generate models with enough fidelity to make them useful? Is it cheaper, faster, and easier to create models and do abstracted simulations, or should we concentrate on the simulation architecture making it bigger, better, faster? We see this everywhere in the verification space today. Many people are saying they will live with cycle-accurate or transaction-level-accurate models and just make the whole system faster. Others think it is worthwhile to build abstract models. It will likely be some combination, and we don’t know what that combination is going to look like.”

Data has limited value, but abstraction and encapsulation can turn data into something more valuable. “Data needs to be captured with knowledge,” says Rance. “If an engineer decides to work for another company, that knowledge goes with him. Engineers are not the best documenters. They’re not capturing everything they thought of, or workarounds they made. But if you capture that knowledge with the data, in a digital form, it becomes part of a digital thread. Then, on the next design or the next iteration of a spec, especially with a top-down approach, that can be included.”

Related Reading
Shift Left, Extend Right, Stretch Sideways
Development flows are evolving as an increasing number of optimization factors become interlinked. Shift left is just one piece of it.
Chip Industry Silos Are Crimping Advances
Development teams constantly wrestle with new technologies and tools, but often it’s the associated corporate structures that cause the greatest challenges.