SNPS1670747138 DAC 2025 800x100px HRes

proteanTecs On-Chip Monitoring and Deep Data Analytics System

proteanTecs On-Chip Monitoring and Deep Data Analytics System
by Kalar Rajendiran on 10-05-2023 at 10:00 am

On chip monitoring and analytics platform

State-of-the-art electronics demand high performance, low power consumption, small footprint and high reliability from their semiconductor products. While this imperative is true across many different market segments, it is critical for applications such as the automotive/autonomous driving and data centers. As electronic devices become more intricate and compact, the margin of error increases, necessitating innovative approaches to ensure optimal performance and longevity.

While traditional methods struggle to help deliver on this imperative, proteanTecs offers a comprehensive framework for enhancing product performance and reliability, through the integration deep data analytics. By combining data from specialty chip telemetry agents (monitoring IP) with machine learning (ML) algorithms, their solutions are deployed via cloud and embedded software to provide insights and visibility throughout the system lifecycle. These agents provide parametric design profiling, margin monitoring, power and reliability management, I/O channel health monitoring and in-field predictive monitoring. This groundbreaking solution is the proteanTecs On-Chip Monitoring and Deep Data Analytics System, and the company recently published a whitepaper on this subject matter. This whitepaper is an excellent read for everyone involved in the development of modern day applications that demand high performance and reliability. Following are some excerpts from that whitepaper.

On-Chip Monitoring and Analytics Platform

The success of the proteanTecs platform relies on two fundamental pillars, namely, comprehensive monitoring and data-driven analytics. By integrating these two elements into the chip design process, the company offers a holistic approach to optimization that covers the entire product lifecycle.

 

Ease of Implementing On-Chip Monitoring

The key is the platform’s ability to meticulously monitor critical chip parameters in real-time. This is achieved through a network of proprietary monitors, called agents, that are strategically placed within the chip architecture. These agents continuously gather data on parameters such as voltage, temperature, timing margins, and interconnect quality, all while the chip is in operation. This dynamic monitoring unveils a wealth of insights, unearthing vital information about a chip’s behavior under various workloads, conditions, and over its operational lifetime.

The hardware IP system from proteanTecs includes an extensive array of monitors for gathering data and a Full Chip Controller (FCC) that serves as the central hub. The FCC interfaces to the various monitors and relays the gathered data to the firmware (FW), edge software (SW) and the cloud platform via standard interfaces like JTAG, APB and I2C.

Ease of Incorporating Data-Driven Analytics

The data collected by the on-chip agents become the foundation for the second pillar of the proteanTecs platform which is deep data analytics. The platform boasts a sophisticated cloud-based analytics infrastructure that ingests, processes, and interprets the data. This complex ecosystem deploys advanced algorithms and machine learning techniques to dissect the intricate relationships between the monitored parameters and the chip’s performance, reliability, and power consumption.

The proteanTecs Software (SW) analytics platform operates in the cloud, acting as an interface to gather data from various sources like wafer probe, Automated Test Equipment (ATE) vendors, and the system during both productization and normal operation. The platform excels in Agent fusion and leverages Agent measurements to offer a comprehensive understanding of both the chip and the system.

Benefits from the proteanTecs Solution

During the New Product Introduction (NPI) phase, the platform’s Process Classification Agent (PCA) and Design Profiling Agent (DPA) collaborate to provide a comprehensive view of process characteristics and design sensitivity. This helps with process tuning, optimal voltage-frequency binning, and power management strategies.

As chips move from development to mass production, proteanTecs’ Timing Margin Agents (MA) come into play. These agents enable the accurate measurement of timing margins during functional operation, offering insights into actual system behavior that generic ring oscillators or critical path replicas cannot replicate. This leads to better understanding and control of the system’s performance, power consumption, and reliability.

Workload Agents (WLA) enable visibility into the application workloads and their impact on the hardware. They serve as a proxy for how much voltage and temperature stress the chip has been exposed to, during normal operation. This is important to determine the remaining useful life of a product and for efficient power and performance management.

The voltage droop sensor (VDS) and local voltage and thermal sensors (LVTS) enable real-time power and temperature management during the operational phase of a chip’s life. This not only maximizes performance but also extends the chip’s longevity by preventing excessive thermal degradation.

The solution’s impact extends into in-field monitoring and lifetime assessment, with embedded on-board software, in-chip monitoring and cloud analytics. By continuously monitoring key parameters, including those susceptible to performance degradation and latent defects, proteanTecs enables early detection of abnormal behavior that may lead to eventual failures. This preemptive capability is invaluable in critical applications, such as data centers and automotive systems, where reliability is paramount.

Summary

By integrating proteanTecs on-chip monitoring and deep data analytics solutions into their products, manufacturers can enhance their systems’ longevity, resilience, safety, and performance. The system offers unparalleled insights into chip behavior, performance optimization, and reliability enhancement. The end-to-end health monitoring fosters optimal reliability, performance, power efficiency, and cost-effectiveness across a broad spectrum of applications, ranging from automotive to data centers and beyond.

You can download the entire whitepaper from here. To learn more about proteanTecs technology and solutions, visit www.proteanTecs.com.

Also Read:

Predictive Maintenance in the Context of Automotive Functional Safety

Semico Research Quantifies the Business Impact of Deep Data Analytics, Concludes It Accelerates SoC TTM by Six Months

Maintaining Vehicles of the Future Using Deep Data Analytics


Pairing RISC-V cores with NoCs ties SoC protocols together

Pairing RISC-V cores with NoCs ties SoC protocols together
by Don Dingee on 10-05-2023 at 6:00 am

An architecture pairing RISC-V cores with NoCs

Designers have many paths for differentiating RISC-V solutions. One path launches into various RISC-V core customizations and extensions per the specification. Another focuses on selecting and assembling IP blocks in a complete system-on-chip (SoC) design around one or more RISC-V cores. A third is emerging: interconnecting RISC-V cores and other IP blocks with a network-on-chip (NoC) instead of a simple bus structure. And it’s not just at the high end – pairing RISC-V cores with NoCs answers many SoC design challenges where data must flow efficiently in any workload using any on-chip protocol.

Performance tiers changing with advanced interconnect schemes

Simply counting gates, cores, and peripheral blocks no longer describes the performance potential of an SoC design. Interconnect schemes now define the lines between SoC performance tiers, according to Semico Research, and a new tier has opened where interconnects change from simple bus structures to more sophisticated schemes.

Semico’s updated definition recognizes three forces at work: the pervasiveness of multicore designs, a higher bar for what is considered a complex design, and the subsequent blurring line between “microcontroller” and “SoC.” In Semico’s latest view, the notion of gate counts as a metric disappears since one modern processor core can drag many gates with it. Complexity becomes a function of interconnects, varying with subsystems and diverse IP blocks.

SoC performance tiers, image courtesy Semico Research Corp.

Where a simple bus will do, likely a part with a single processor core and low-duty-cycle peripherals that aren’t continuously contending for the bus, Semico sees a commodity controller tier. Anything above that becomes an SoC, presumably with at least some peripherals fighting for on-chip bandwidth and attention from the processor core(s). Higher SoC tiers have multiple cores and multiple IP subsystems, each with tuned interconnect technology.

NoCs pick up more protocols and subsystems

RISC-V has quickly moved up these performance tiers as more powerful cores appear, with no less applicability at the lower end of the Semico scale. However, RISC-V designers may have less experience in complex interconnect schemes seen in the higher tiers. “TileLink may be the first thought for RISC-V interconnect, but it can be difficult to use in more complex scenarios,” says Frank Schirrmeister, VP of Solutions and Business Development for Arteris.

A NoC’s superpower is its ability to connect subsystems using different protocols, and SoC designers are likely to run into several protocols at even moderate complexity. AXI leveled the playing field for simple IP block connections. Multicore solutions with co-processing blocks demand cache-coherence, giving rise to the CHI protocol. I/O memory sharing helped shape the faster CXL interconnect. “When it’s time to co-optimize compute and transport with various subsystems and protocols in play, a NoC is a better solution,” continues Schirrmeister.

What can pairing RISC-V cores with NoCs look like? Arteris customer Tenstorrent provides a glimpse into the possibilities. Their recent focus is creating a reusable chiplet combining RISC-V cores, machine-learning acceleration IP, and standard peripherals found in many edge AI applications. At scale, a single-die implementation could look like the following diagram, using the Arteris Ncore cache-coherent interconnect and several segments of the Arteris FlexNoC non-coherent interconnect.

image courtesy Arteris

A Smart Memory Controller (SMC) provides a high-performance, server-grade memory connection in memory-intensive applications. The unnamed “chiplet link” could be UCIe, a relatively new specification optimized for tighter chiplet integration. When new subsystem interconnects emerge, adapting a section of the NoC is more manageable than ripping up the entire chip-wide structure.

Pairing RISC-V cores with NoCs lowers risk and time-to-market

If that diagram looks complex, and granted, maybe most RISC-V applications aren’t that complex right now, consider this: chiplets are already driving integration much higher. Today’s advanced RISC-V multicore part will be next year’s value SoC as innovation picks up pace.

Arteris Ncore and Arteris FlexNoC development tools output RTL for implementation, providing several advantages. Physical NoC estimation is straightforward in an EDA workflow. NoC parameter adjustments, such as the number of pipeline stages, are also a few clicks away in EDA tools. The modifications mentioned above for adding a subsystem protocol are also readily accomplished. “At the high end, users gain immediate access to our NoC expertise,” says Schirrmeister. “At the low end, our tools are easy to use for first-pass success and provide a growth path for more ambitious future projects with complex interconnects.”

Pairing RISC-V cores with NoCs lowers the risk of one more IP block entering a design and triggering a ripple of interconnect redesign across the chip. It also reduces time-to-market for complex SoC designs compared to do-it-yourself interconnect structures. We haven’t discussed the other benefits of NoCs here, such as bandwidth and power management, but the case for NoCs in RISC-V designs is strong just considering a diverse protocol mix.

Visit the Arteris website for more information on NoCs and other products.


The Quest for Bugs: “Verification is a Data Problem!”

The Quest for Bugs: “Verification is a Data Problem!”
by Bryan Dickman on 10-04-2023 at 10:00 am

The Quest for Bugs Verification is a data problem

Verification Data Analytics

Hardware Verification is a highly data-intensive or data-heavy problem. Verification Engineers recognise this and spend much of their time dealing with large and complex datasets arising from verification processes.

In “The Dilemmas of Hardware Verification” we explored the key challenges around verification of complex hardware IP and systems. The “completeness dilemma” leads engineering teams to be heavily dependent on data and data analytics, to make incomplete processes measurable and bounded and allow product development teams to make data-driven decisions about signoff quality for product releases.

So, in fact, one of the many core skillsets of a good Verification Engineer, is data analytics.

Great Verification Engineers need to be great Data Analysts.

Engineers deal with huge volumes of data: suites of tests, test results, coverage results, resource planning and utilisation data, version control data, waiver analysis, bugs and defect tracking and ongoing optimisation and continuous improvement through trend analysis and root causes analytics.

In so doing, Verification Engineers utilise many different data sources to ensure projects are on track and progressing towards project goals whilst ensuring accurate information is available to support signoff decisions at key quality milestones occurring during the product development lifecycle.

Verification data also presents a huge opportunity to optimise and streamline verification workflows.

The ROI of the final delivered product is heavily determined by the development costs, and it’s been well documented that 70% or more of these costs are attributable to verification activities. So, care must be taken to ensure that verification activities are effective and efficient and not wasteful.

Of course, a healthy degree of paranoia is helpful from a Verification Engineer’s perspective as there is strong compulsion to run more and more verification cycles because a bug escape that reaches the customer or end user can be extremely costly, impactful, and potentially reputationally damaging! See “The Cost of Bugs” where we explore the balance between the “cost of finding bugs” (the verification costs) versus the “cost of not finding bugs” (the impact costs of bug escapes).

Insights from Data

The value of verification data is realised when it yields key insights.

Think of insights as questions.

An insight might be a high-level question that an Engineering Manager is asking of the engineering team to understand how effective or efficient the product development process is. It could also be a question asked by the senior leadership team, the quality team or the sales and revenue team.

Insights can also drive a strategy of continuous improvement enabled by an understanding of effectiveness and efficiency.

In some cases, insights can be unpredictable or unexpected. Curiosity and an analytical approach to cleaning, understanding, exploring, and validating the data, and reviewing the analytical views can reveal observations that were not previously available. These unexpected insights present opportunities to challenge the status quo sometimes and re-think established practices. However, care must be taken to challenge and validate the assumptions.

Beware that it’s sometimes possible to make the analytics fit the narrative rather than the other way round.

It’s useful to think of insights in the context of a data-value stack, as illustrated in Figure 1 The Analytics Inverse Pyramid.

Insights enable Data-Driven Decision making.

Insights are made possible by good Data Analytics, which are in turn enabled by Data Models constructed from the Data Sources loaded into the Data Lake. The point is to figure out what Data-Driven Decisions are required by the business first and let this drive the data capture, the data pipelines, and the data analytics, not vice-versa!

Figure 1 The Analytics Inverse Pyramid

The raw data at the base of the pyramid has little value unless it is clean and accurate and is fed through a data pipeline driving powerful analytics driving high value insights.

The anatomy of data and why we should care…

If we follow Exec-Level care-abouts driving verification excellence all the way through to verification engineering reality – daily activities – we can better describe what is happening at each stage.

From the CFO and CEOs’ viewpoint there are multiple issues to worry about, but when it relates to engineering development of the company’s all important revenue bearing products, it boils down to these.

Figure 2 Cost, Quality, Delivery

Customers want the same outcomes from their supplier, meaning the verification effort you put in must be effective and efficient, to drive cost effective solutions for them. To achieve this, your design and verification processes must be well instrumented to avoid the so-called “black box” syndrome, whereby products arrive without a clear idea of just how good the verification effort has been at finding bugs and perhaps without a good handle on costs, or project timescales.

Excellence depends on good data and an engineering culture that knows how to exploit it.

Figure 3 Data Pipelines, below, indicates the importance of analytics to provide insights into the verification effort to assess effectiveness and efficiency. Useful analytics require the correlation of information from various data sets generated by the daily activity of design and Verification Engineers.

Figure 3 Data Pipelines

It’s a useful thought-experiment to measure where your verification effort sits in relation to the questions in orange, at each of the data pipeline stages above. Perhaps surprisingly, not all engineering teams have a good enough handle on what data they have, where it’s located, how clean it is and how to exploit it. Later in the paper we explore creating the culture of curiosity and the competences necessary to make this transition possible.

Figure 4 Data Challenges, below, illustrates some of the challenges teams are likely to encounter when developing the analytics needed for good decision making, to drive important improvements verification processes and indicate necessary investments in tools and hardware.

Figure 4 Data Challenges

These challenges are not unique to hardware verification but must be overcome to reach basic levels of analytics capability.

Deriving analytics from diverse data sets can be extremely complex, particularly when it comes to correlating them. A simple example would be to illustrate bug discovery at different stages of the product life cycle phases so you can assess progress against your Verification Plan.

Other insight questions require more complex data engineering to provide the information required. In smaller companies this task could fall to the engineering team, or it might be outsourced. As good “data engineers”, the verification team need to be comfortable with thinking around these problems.

Larger teams may have the luxury of internal data engineering/analyst resource to make these developments in-house. In both cases, Verification teams need to be fluent with the data challenges, to ensure they get what is needed if analytics are to be developed, or improved. See Step1: Train your engineers to think like Data Analysts.

The data quality, data volume trap…

Our focus for this white paper is to discuss “Data Analytics” in the context of organising, automating, cleaning, and visualising verification datasets that most teams already have. However, you can’t discuss this topic without raising the question: –

What about AI? Can I use it?

Everyone is aware of the potential offered by Machine Learning (ML) currently being embedded in EDA tools (see Step2: Exploit Advanced EDA Tooling), as well as the opportunities offered by data science to improve the targeting of coverage and parsing of data to make for easier analysis. Although this paper will touch on these subjects, it is primarily focussed on how to make the best use of data to drive better insights into the verification process.

 

Figure 5 Low quality, small datasets are barriers to developing analytics or successfully deploying advanced ML/AI techniques.

Although there are no publicly available numbers showing how many engineering teams have successfully implemented ML and AI, it is likely many will have encountered problems with data quality or size of datasets.

In their thought-provoking article, “A survey of machine learning applications in functional verification”, Yu, Foster and Fitzpatrick asserted, “Due to the lack of large datasets, much research has to settle for relatively primitive ML techniques that demand only small training datasets with hundreds of samples. The situation has prevented advanced ML techniques and algorithms from being applied”.

In Figure 5 (Data Quality), above, small amounts of unreliable verification data are difficult to analyse with any degree of confidence – you find yourself in Trap 1. In this case, the plausible option is to invest in cleaning up your data and developing excellent analytics – there is no easy jump to ML/AI in Level 2 from Trap 1.

Large amounts of low-quality information may be very difficult to manage and understand, making it unsuited to ML or AI techniques, let alone any necessary data engineering needed to produce good analytics – This is Trap 2. As with smaller data sets, a large-scale clean-up operation is indicated. For these reasons, bad data quality and smaller data sets present significant challenges for companies wishing to move to ML enabled EDA tools and more advanced AI techniques.

A more plausible and necessary step for many organisations is to make better use of the data they do have to create useful analytics to enable great decision making and continuous improvement.

Although “just” creating good analytics may seem less exciting than going straight to ML/AI in Level 2, they may still be difficult to implement until your data has been cleaned and some of the challenges explored in Figure 4 have been overcome.

Assuming you have your data engineering organised, built on a foundation of high-quality data and stunning analytics to shine the light into those dark and bug-rich corners, it’s time to think about what insights to look for.

Insight: “Is my Verification Effective?”

Returning to “Insights”, many from verification datasets can be classified as effectiveness and efficiency insights. Let’s start with effectiveness. What does that mean for a verification team, and who else wants to know about it?

Effectiveness can be described as a function in the following way: –

Each of the variables in the formula is quite probably captured in a separate database and is described by a set of data schemas.

The richness of the data schemas used to collect the data has a direct impact on the quality of analytics that can be generated from it.

A “data model” connects these sources using primary keys to allow correlation of the data. Once the team have identified what analytics are required, there may be a need to elaborate the data schemas.

The effectiveness insight requires analytics that show testbench effectiveness in terms of ability to make verification progress, defined as increasing coverage and/or finding bugs. If a testbench is not advancing coverage or finding bugs, then it might be ineffective, unless verification goals are already fully met.

The utility of good analytics is the ability to analyse testbench effectiveness in a visual fashion so that development teams can make targeted improvements to testbench implementations. Continuous improvements are achieved through iterations of code refactoring, performance optimisations, or re-architecting, with a view to increasing the ability of the testbench to hit bugs and coverage with fewer seeds or cycles. Analytics are used at each stage to demonstrate actual improvements.

INSIGHT: “Does my Testbench find Bugs?”

For this, we need data schemas that enable analytics to visualise and drill into the bug curve over time. We expect to see a cumulative bug curve that flattens and saturates over time; or a bug rate curve that peaks and then falls towards zero.

Better still is to correlate these bug curves with verification effort to give a true indication of verification effort versus bugs found.

And with a hierarchy of verification such as Unit->Sub-system->Top->System, the analytics need to be able to present the bugs v effort data at each level and enable users to see how different levels and different units or sub-systems compare. Such analysis capability offers insights of which are the effective verification environments, and which are apparently ineffective. From this, teams can make decisions about where to invest engineering effort for the greatest return.

What does that mean in terms of data?

To do this we need to join the bug data with the verification results data so that we can explore how many cycles of verification are running between finding bugs – and to look at this over the product development lifecycle since it will vary according to what stage of development the product is at.

INSIGHT: “Does my Testbench increase Coverage?”

The analytics also need to correlate coverage data with verification effort data. If the analytics are revealing that the bug curve is saturated and the coverage is saturated, the engineering team can use this information to make decisions about what to do next; Run more cycles? Run less cycles? Improve the verification environment?

Further, with bug and coverage data collected across the whole product development lifecycle and all verification methodologies applied, you can reason about the relative effectiveness of each methodology. i.e., you must consider the effectiveness in the context of the whole verification lifecycle and the stage you are at. For example, Unit testing might appear to be ineffective (does not find many bugs) due to earlier top-level or formal verification doing a good job of cleaning out most bugs. So, you must consider the whole lifecycle of verification and the order that is chosen to execute various methodologies.

Insight: “Is my Verification Efficient?”

The second most important question relates to efficiency. You may have effective stimulus and checking, but can verification be done with the minimum amount of human and platform resources, and can it be delivered in the shortest possible time?

Efficiency is a function of the following: –

To understand efficiency, you must look at the details of:

  • Individual testbenches to understand if they have been architected and implemented in an optimal way for the highest performance with the given methodology.
  • Regression workflows to understand if they are running jobs optimally and not wasting resources by needlessly re-running full regression sets when more targeted runs are more efficient.
  • The available platform capacities which may be shared across multiple teams. Is there a shortage of resources that leads to inefficiencies in utilisation?
  • The performance of the platform, both the hardware (compute, storage, and network) and the EDA tools that are running the verification workloads.

This insight tells us how efficiently implemented simulation testbenches are. If a testbench is very slow, it will consume much greater levels of compute and simulation license resources. Slow testbenches might need to be re-implemented to make them run faster. This question relates to Unit or Sub-system testbench architecture and methodology.

Efficiency insights require analytics that reveal relative performances of verification environments tracked over time so that changes to performances can be identified and outliers can be observed and investigated. Since testbenches will vary by architecture and implementation, some degree of performance variability is to be expected, but having good analytics dashboards available to monitor these environments enables early detection of performance impacts that may arise from bad coding practices or platform/environment/tools degradations. When teams can see this data – they can fix these problems.

Without analytics, teams are flying blind regarding efficiency. 

Collecting bug data is the most important step towards Level 1 analytics capability!

We have discussed the value of bugs in The Quest for Bugs series of articles, but it is worthwhile to restate here why Bug Data is one of the richest sources of verification data and can drive the most useful insights such as verification effectiveness.

Bugs are a fantastic source of insights and learning, BUT only if you collect them!

…and the collection of good quality bug data is the challenging bit.

With enough accurate bug data, you can glean insights into both the effectiveness of your verification strategies, and the quality of your design (Level 1). If you look across the entire design, do some units or functions yield more bugs than others and if so, what is the cause of this? Maybe steps can be taken to reduce the number of bugs being introduced into the code? Does the bug data point at hotspots of complexity. What is the underlying root cause of these bugs and can bugs be avoided in the first place? From a verification effectiveness perspective, which methodologies are the most effective at finding bugs quickly? Are you spending vast resources running verification cycles that do not find bugs?

Can you “shift-left” and find those bugs earlier in the product development lifecycle and saturate the bug curve sooner, meaning release the product sooner?

To answer these questions, you need to ensure you are collecting enough bug data and that you have an adequate bug schema that captures the right information about bug discovery, bug impacts, and bug root causes. If you have a rich bug dataset, you will be able to drill bug analytics to answer many of these questions and perhaps expose some unexpected insights. Welcome to Level 1 Analytics!

The challenge is often persuading your engineering teams to get the bug-logging habit.

It’s an engineering practices or engineering culture thing. Some teams just do this as a natural part of their job, other teams are less willing and see bug-logging as an overhead to making forward progress.

Engineering teams need to see concrete value from the bug analytics as a motivation to collect the data. But of course, it’s a “chicken and egg” problem; no bug data or poor-quality bug data = no analytics or low value analytics.

When is the right time to start bug-logging? How do you ensure that the bug data is complete and accurate?

There are 3 key motivators for bug-logging: –

  1. Teamwork and communication: the task list to develop complex products (hardware or software), is long and likely to involve multiple people. Unless bugs are diligently logged and tracked there is a risk of bugs slipping through due to poor practice. It’s often the case that the bug reporter and the bug solver are not the same person, so you need to record and track the bug communications (triage, analysis, and solutions) to ensure nothing slips through the net.
  2. Progress tracking and sign-off: As the project transitions through the product development lifecycle there is a need to understand what the bug-curve looks like at any one point in time. What is the current bug rate? How many bugs are outstanding at each sign-off point? Is the bug curve trending in the right direction as expected? How many critical bugs do we have versus major and minor bugs?
  3. Continuous Improvement: By analysing the bug discovery data and the bug root causes, we can use these insights to improve the effectiveness and efficiency of our design and verification methodologies. This is where continuous learning from bugs, both within a project and between projects, can really reduce costs, improve quality, and reduce time-to-market for complex products.

If you can collect bug data accurately and consistently, then many of the above insights will be available to you. Furthermore, if you can join this bug data with other interesting data sources such as test execution data, project milestone data, or resource consumption data, then there are additional powerful insights that are possible that will illuminate the cost-benefit of your engineering efforts.

Step1: Train your engineers to think like Data Analysts

In Figure 5 we described routes out of data/volume traps towards Level 1 and 2 capabilities. We can also identify three more specific stages that will need to be attained to make progress.

As we mentioned, data analysis is a core skill for Verification Engineers, whether they realise it or not. Sometimes however, the basics of data fluency are not there, and this is something you can train your engineers in. Often, data analysis can be quite basic; maybe a static extract of data that is visualised as an Excel table, or better as an Excel chart. These basic analytics are static views of data that maybe need to be updated manually and regularly and are presented as snapshots in time for project reporting or progress tracking.

Live and fully automated analytics is the way to go. Engineers and managers need to be able to access data analytics at any time and trust that what they are seeing is the latest complete and accurate data. They need to be able to self-serve these analytics and not rely on engineers or data-analysts to refresh and serve the analytics on request. This requirement leads to the need to deliver user-friendly visualisations underpinned by automated data pipelines that consume data at source and clean and transform that data into reliable data models upon which interactive visualisations can be built.

So, more skills are required here than a basic competence with spreadsheets and charts.

We advocate the training of some core data skills for engineers that will enable them to understand and present their data in a way that leads to powerful insights. Some of these activities can be outsourced to trained data analysts, but a core knowledge in this area ensures that Verification Engineers gather and analyse the right datasets and understand what data is needed and how to interpret it. It also engenders a data perspective (or data fluency) where engineers start to understand how to read data, how to manipulate and transform it, and how to be wary of pitfalls that can produce misleading results, such as many-many relationships between data elements.

  • Data Capture: Where is your data coming from? What is the provenance of the data, and is it all being collected? This usually entails some instrumentation of verification workflows to capture data and send it to a Data Lake. In turn, that means that you need to figure out the correct data schema that will capture all the required fields needed to support the analytics. This should be an automated process so that data capture is on by default. Capture the data, regardless of whether you then need to filter and sample it later for the analytics.
  • Data Cleaning: Most raw data needs some level of cleaning or processing to remove nulls or duplicates, for example, correct errors or bad entries or to backfill data gaps. This can be done in an interactive way but is best done in an automated batch processing way wherever possible. Data cleaning can be scripted with Python NumPy and pandas libraries for example, where powerful data operations can be performed on data frames with just a few steps. (Many Verification Engineers will already be using Python for verification workflow scripting and processing, so the addition of these data analysis libraries and the concepts around data frame manipulations should not be a difficult step).
  • Data Engineering: This is the step where data is transformed and manipulated into a format suitable for data visualisation. This may involve joining and merging different data sources so that important correlations are possible that will deliver key insights from the data. See Figure 4 Data Challenges. Sometimes called the data model, it is the schema that controls how different data tables are joined, using common elements (primary keys) that link them together. It may also involve pivots, aggregations, summarisations, or the generation of derived or calculated data elements. For example, verification teams might want to correlate simulation testbench execution result data with bug tracking data to understand how effective different testbenches are at finding bugs in the RTL. Additionally, data engineering competence might extend to databases – how to set up structured databases such as MySQL, or unstructured databases (or Data Lakes) such as MongoDB or Hadoop, for example. There is much to learn in this domain, and it’s an area where data engineers and data analysts will specialise, so as a Verification Engineer or Design Engineer, it may be good to understand this discipline but to outsource the data engineering work to data specialists.
  • Data Querying: This may be more of a data engineering skill set, but some basic SQL capability may be useful to support early exploration of datasets, before full data visualisations are available. Exploring datasets is a key competence when presented with new data and prior to establishing any automated analytics. SQL is a core competence for most Data Analysts.
  • Data Visualisation: Finally, the bit that will deliver results and key insights is where the data is visualised, and the end user can interact with the data. Sometimes referred to as “Business Intelligence” since it presents intelligence or insights into the state of the business (or the state of a product development project). It should not be underestimated the importance of learning good data visualisation skills, and there are multiple good tooling options that are fun to learn and can deliver impressive visualisations very quickly e.g., PowerBI or Tableau. Learning to use these tools effectively generates real interest and excitement around data so it’s a worthwhile core skill to add to the Design or Verification Engineer’s skillset.

Step2: Exploit Advanced EDA Tooling

The EDA industry has been working on ways to exploit AI and ML to enhance their tool offerings for several years now. This is enabled by both the large volumes of data generated by many EDA verification tools, and the emergence and maturing of general ML algorithms which can be suitable to many verification data problems. These tools are often offered as new versions of the existing tools that can be licensed, or enhancements of existing tools where performance and efficiencies are improved thanks to ML under-the-hood. The end user may not need to know that ML is being utilised by the tools, or change the way that they use the tools, but the tools will perform better. This presents a low barrier to adopting more advanced tooling by your verification teams should you choose to do so, and without the need to train as data scientists or learn ML. We are not going to discuss the specific offerings of the EDA vendors or attempt to survey the market here. Our point is this:

Verification teams should be encouraged to explore and evaluate the available offerings…

… to see if the cost-benefit is there for their workflows and their product development lifecycles. Since the EDA industry is constantly evolving, the tools that are on offer and verification tooling have been an area of high innovation in the EDA industry for some time. It is the responsibility of the verification team to keep abreast of the latest developments and engage with the EDA vendors to ensure their current and future requirements can be met by the EDA vendor’s technology roadmaps.

Some of the ways (but not all) that ML is enhancing EDA tool offerings are in the following areas: –

  • Debug acceleration using automated failure clustering and signature analysis.
  • Execution optimisation to ensure optimal tool settings are used for simulation runs.
  • Optimisation of formal engine selections for formal verification.
  • Coverage closure acceleration by test selection ranking and optimisation.

You can think about verification workflows as a set of data inputs and data outputs, as shown below. Both input data sets and the generated output data sets can be candidates for ML opportunities. We know how much effort can be expended on coverage analysis and parsing of test results. Even small improvements in efficiency and effectiveness in these key areas can yield worthwhile savings in cost, quality, and time to market.

Figure 6 ML for EDA tooling

Step3: Train your engineers to think like Data Scientists

So far we have talked about the core skills required to perform competent data analytics, but of course there is a whole branch of data analytics that is often referred to as Data Science, which is exciting and appealing because it offers us opportunities to exploit our data in different ways and yield further insights from the data that may not be achievable with data visualisations alone. Often referred to a ML or Machine Learning, there is a well-established discipline that is accessible to all with a bit more basic training. There are libraries of ready-made algorithms available; you can find many of these conveniently bundled in Python’s scikit-learn library for example. Curious Verification Engineers love to innovate and problem-solve around verification efficiency and effectiveness. These are engaging and challenging problems and solving them by learning and applying new ML skills can be highly motivating. Learning these new skills is also fun and enjoyable and there are many excellent on-line learning platforms that can get you from zero-to-hero in a very short time e.g., DataQuest, DataCamp, udemy, coursera, codeacademy,  to name a few.

If your engineering team has mastered basic data analytics and visualisation skills, your data pipeline is clean and accurate, and you are collecting enough data, then there are many optimisation problems in verification that may be ripe for an ML approach – e.g., regression set reduction and optimisation, prediction modelling for resource demands, coverage closure optimisation etc.

Beyond this, there is much excitement about AI today, especially the application of Generative AI to problems such as test generation or code writing. We are not going to explore that topic here but, when Verification Engineers start to think and act like data scientists, there may be many opportunities to make tangible improvements to the way that complex designs are verified using less resources, in a shorter time, and delivering higher quality products.

Summary

Hardware Verification is a data-heavy problem.

Verification Engineers have known this for some time, and their day-to-day work involves the gathering, processing, and reporting on some large datasets. The reason it is a data-heavy problem is that verification is intrinsically an open-ended problem. Engineering teams need insightful analytics to make this open-ended process measurable and finite. Some engineering teams are still working with spreadsheet level analysis and visualisation, often using static snapshots of data, and manual data manipulations that are time-consuming to update. There may be many different data sources contained in many different systems which makes it difficult to join data and make insightful correlations.

For many, the challenge is how to exploit verification data with data analytics that will reveal significant opportunities to improve hardware verification.

There are mature disciplines available to assist with this, especially in the areas of data engineering, data analytics and data visualisation. Engineering teams need to either up-skill in modern data analytics, or engage professional data engineers, data analysts, data scientists, to bring these capabilities to the product development process. The end point is a set of interactive and real-time analytics that are intuitive, accessible, accurate, and self-service. Consumers of analytics should no longer need to raise a request to see an updated report. They should access the visualisations themselves and understand how to drill-down and filter to the view they require, which they can save or embed as a favourite view, knowing that this is real-time data, and trusting that the data is accurate. Report generation becomes a less onerous task when you have live analytics at your fingertips. The improved availability, and accessibility means analysis is devolved to those that need the data, and what’s more, curiosity should reveal previously unknown insights when the data is so much easier to see and explore.

If you do nothing else, refine your bug data capture behaviours and processes…

… because bug analytics can reveal insights that can be acted on in the near term.

That’s the baseline verification data analytics to aim for. Do this first. Establish a clean, accurate and complete data pipeline where the end point is fantastic explorable data visualisations. Beyond that, there are further possibilities to explore datasets more deeply and exploit more advanced techniques such as ML or AI to understand previously unseen patterns in data and build feedback loops into processes and workflows to optimise and reduce time, effort, and cost. We note that all the mainstream EDA verification tool vendors are already building ML under the hood for many of their advanced tool offerings. These can be exploited today without the need to train your engineers as data scientists. Most verification activities involve some sort of iteration or refinement towards a result. You may be able to get there with an acceptable % accuracy in a fraction of the time using ML/AI. More advanced teams or teams who are engaging trained data scientists may be able to realise these gains as data maturity grows and engineering teams adopt a strong data culture.

Authors:
Bryan Dickman, Valytic Consulting Ltd.,
Joe Convey, Acuerdo Ltd.

Also Read:

The Quest for Bugs: “Shift-Left, Right?”

The Quest for Bugs: “Correct by Design!”

The Quest for Bugs: Bugs of Power

The Quest for Bugs: “Deep Cycles”

The Quest for Bugs: Dilemmas of Hardware Verification


Samtec Increases Signal Density Again with Analog Over Array™

Samtec Increases Signal Density Again with Analog Over Array™
by Mike Gianfagna on 10-04-2023 at 6:00 am

Samtec Increases Signal Density Again with Analog Over Array™

Samtec is well-known for its innovative signal channel solutions. Whether the application requires copper or fiber, Samtec can deliver incredible performance and flexibility. The quality of the company’s models, eval kits and design support are well-known. There is another aspect of Samtec’s innovation. I touched on it in last month’s post when I discussed how Samtec can turn bulky waveguides into flexible cables. Beyond performance, this approach has a big impact on form factor and signal density – two very important topics these days. In this post, I’ll explore another innovation from Samtec that mixes analog and digital signals in the same connection. Read on to see how Samtec increases signal density again with Analog Over Array™.

What is Analog Over Array?

Samtec Analog Over Array connectors are dense, high-frequency connectors supporting digital and analog differential or single-ended signaling. An open pin field design is used that provides the flexibility to simultaneously run differential pairs, single-ended signals, and power through the same interconnect. The figure at top of the post shows what these connectors look like.

Samtec’s high-density array connectors are already proven in high-speed, high-performance digital applications. For RF applications, Samtec adds industry-leading differential crosstalk and return loss performance beyond 8 GHz. You get performance and a denser form factor in once package.

Features of the technology include:

  • Open-pin-field design with maximum routing and grounding flexibility
  • Analog and digital signals (differential pairs and/or single-ended) plus power though the same interconnect
  • Differential ground pattern supports RF SOCs
  • Single-ended ground pattern

The approach can be used in a wide range of applications, including 5G/LTE, remote PHY, phased digital/array radar, test and measurement, low/medium Earth orbit satellites, and RF SoCs. If you are working in any of these areas, you should check out what Analog Over Array can do for your project.

There are more details and references coming, but here is a top-level summary of performance:

  • 50 Ohm system impedance (single-ended); 100 Ohm system impedance (differential)
  • Return loss (maximum): -12 dB up to 4 GHz; -10 dB up to 8 GHz
  • Crosstalk isolation between channels (minimum): -69 dBc to 4 GHz; -53 dBc to 8 GHz

How Can I Get It?

Analog Over Array capability is available through several Samtec products:

NOVARAY® 112 GBPS PAM4 ARRAY, EXTREME DENSITY ARRAYS

Features

  • 112 Gbps PAM4 per channel
  • 0 Tbps aggregate data rate – 9 IEEE 400G channels
  • PCIe® 6.0 capable
  • Innovative, fully shielded differential pair design enables extremely low crosstalk (beyond 40 GHz) and tight impedance control
  • Two points of contact ensure a more reliable connection
  • 92 Ω solution addresses both 85 Ω and 100 Ω applications
  • Analog Over Array™ capable

ACCELERATE® HP HIGH-PERFORMANCE ARRAYS

Features

  • 635 mm pitch open-pin-field array
  • 56 Gbps NRZ/112 Gbps PAM4 performance
  • Cost optimized solution
  • Low-profile 5 mm and up to 10 mm stack heights
  • Up to 400 total pins available; roadmap to 1,000+ pins
  • Data rate compatible with PCIe® 6.0 and 100 GbE
  • Analog Over Array™ capable

SEARAY™ 0.80 MM PITCH ULTRA HIGH-DENSITY ARRAYS

Features

  • 80 mm (.0315″) pitch grid
  • 50% board space savings versus .050″ (1.27 mm) pitch arrays
  • 28 Gbps NRZ/56 Gbps PAM4 performance
  • Rugged Edge Rate® contact system
  • Up to 500 I/Os
  • 7 mm and 10 mm stack heights
  • Solder charge terminations for ease of processing
  • Samtec 28+ Gbps Solution
  • Final Inch® certified for Break Out Region trace routing recommendations
  • Analog Over Array™ capable

LP ARRAY™ LOW PROFILE OPEN-PIN-FIELD HIGH-DENSITY ARRAY

Features

  • 4 mm, 4.5 mm, 5 mm stack heights
  • Up to 400 I/Os
  • 4, 6 and 8 row designs
  • .050″ (1.27 mm) pitch
  • Dual beam contact system
  • Solder crimp termination for ease of processing
  • 28 Gbps NRZ/56 Gbps PAM4 performance
  • Analog Over Array™ capable

To Learn More

Samtec will soon offer complete evaluation kits to test-drive Array Over Analog technology. Stay posted for details about these kits here.  A detailed characterization report on a SEARAY design is available here.  Other Samtec product families mentioned in the article are on the roadmap.  A White Paper on the technology is available here.  And that’s how Samtec increases signal density again with Analog Over Array™.


Transformers Transforming the Field of Computer Vision

Transformers Transforming the Field of Computer Vision
by Kalar Rajendiran on 10-03-2023 at 10:00 am

The Structure of a Transformer: Attention

Over the last few years, transformers have been fundamentally changing the nature of deep learning models, revolutionizing the field of artificial intelligence. Transformers introduce an attention mechanism that allows models to weigh the importance of different elements in an input sequence. Unlike traditional deep learning models, which process data sequentially or hierarchically, Transformers can capture dependencies between elements in parallel. This makes it possible to train much larger models more efficiently.

While originally developed for natural language processing (NLP), Transformers have started to gain prominence and adoption in a number of different applications. One such application is computer vision, the field that enables machines to interpret and understand visual information from the real world.

Computer vision has evolved over the years, from techniques based on handcrafted features to the recent surge in deep learning models. The advent of deep learning, fueled by the availability of large datasets and powerful GPUs, has revolutionized the field. Deep learning models have surpassed human-level performance in tasks such as image classification, object detection, and image generation. This field has long relied on convolutional neural networks (CNNs) for its deep learning architecture. Researchers have realized that Transformers could be adapted to tackle spatial data too, making it a promising candidate for computer vision applications. This is the context for a talk given at the 2023 Embedded Vision Summit by Tom Michiels, Principal System Architect at Synopsys.

Why Transformers for Vision

Computer vision tasks, such as image classification, object detection, image segmentation, and more, have traditionally relied heavily on CNNs. While CNNs are effective in capturing spatial hierarchies and local patterns in images, Transformers excel at capturing long-range dependencies and global contextual information within an image. This is essential for understanding relationships between distant image regions, making them suitable for complex vision tasks. Transformers process all elements in parallel, eliminating the sequential nature of CNNs. This parallelization significantly accelerates training and inference times, making large-scale vision models more feasible. Transformers can be scaled horizontally by adding more layers and parameters, allowing them to handle a wide range of vision tasks. They can be scaled vertically to handle larger or smaller input images for image classification to fine-grained object detection. Vision tasks often involve multiple modalities, such as images and text. Transformers are inherently multimodal, making them suitable for tasks that require understanding and reasoning about both visual and textual information. This versatility extends their applicability to areas like image captioning and visual question answering.

Transformers also tend to produce more interpretable representations compared to some other deep learning models. The attention maps generated by Transformers provide insights into which parts of the input are weighted more for making predictions. This interpretability is invaluable for debugging models and gaining insights into their decision-making processes.

Applications of Transformers in Computer Vision

Models like DETR (DEtection TRansformer) have demonstrated remarkable performance in object detection tasks, outperforming traditional CNN-based approaches. DETR’s ability to handle variable numbers of objects in an image without the need for anchor boxes is a game-changer. Transformers have shown significant promise in semantic and instance segmentation tasks. Models like Swin Transformer and Vision Transformer (ViT) have achieved competitive results in these areas, offering improved spatial understanding and feature extraction. Transformer-based models, such as DALL-E, are capable of generating highly creative and context-aware images from textual descriptions. This has opened up new opportunities for content generation and creative applications. Last but not least is that Transformers can generate descriptive captions for images, enriching the accessibility of visual content.

Hybrid Models

While ViTs are excellent in image classification and beat CNNs in accuracy and training time, CNNs beat ViTs in inference time. While Transformers are more helpful for recognizing complex objects, the inductive bias of a convolution is more helpful for recognizing low level features. Training large scale Transformer models for computer vision often requires extensive datasets and computational resources.

As such, a vision processing application may utilize both CNNs and Transformers for greater efficiency. Combining the strengths of Transformers with other architectures like CNNs is a growing area of research, as hybrid models seek to leverage the best of both worlds.

Synopsys ARC® NPX6 NPU IP

The Synopsys ARC® NPX6 NPU IP is an example of an AI accelerator that can handle CNNs and transformers. It leverages a convolution accelerator for matrix-matrix multiplications, as well as a tensor accelerator for transformer operations and activation functions. The IP delivers up to 3,500 TOPS performance and exceptional power efficiency of up to 30 TOPS/Watt. Design teams can also accelerate their application software development with the Synopsys ARC MetaWare MX Development Toolkit. The toolkit provides a comprehensive software programming environment that includes a neural network software development kit and support for virtual models.

To learn more, visit the product page.

Summary

The surprising rise of Transformers in computer vision spotlights a significant shift in the field’s landscape. Their unique capabilities, including the attention mechanism, parallel processing, and scalability, have challenged the dominance of CNNs and opened up exciting possibilities for computer vision applications. They offer unparalleled versatility and performance across a wide range of tasks, transforming how we interact with visual data. As researchers continue to refine and adapt Transformer models for vision tasks, we can expect further breakthroughs that will lead to smarter, more capable vision systems with broader real-world applications.

Also Read:

Power Analysis from Software to Architecture to Signoff

WEBINAR: Why Rigorous Testing is So Important for PCI Express 6.0

Synopsys Expands Synopsys.ai EDA Suite with Full-Stack Big Data Analytics Solution


Lowering the DFT Cost for Large SoCs with a Novel Test Point Exploration & Implementation Methodology

Lowering the DFT Cost for Large SoCs with a Novel Test Point Exploration & Implementation Methodology
by Daniel Nenni on 10-03-2023 at 6:00 am

blog sept pic1

With the increasing on-chip integration capabilities, large scale electronic systems can be integrated into a single System-on-Chip or SoC. New manufacturing test challenges are raised for more advanced technology nodes where both quality and cost during testing are affected. A typical parameter is test coverage which impacts directly yield.

Test point exploration is becoming a key for large system on chip designs especially for automotive & security applications where test coverage figures are expected to reach 99% and more. To reach such high coverage figures, area overhead is usually quite high. EDA tools in general are still conservative and any analysis of “test coverage vs. test logic implementation” requires tedious manual work especially when realized post-synthesis.

In summary, Test Point Exploration & Implementation (TPI&E) is nowadays a key problem for DFT engineers.

Beyond the exploration of different test point figures, the implementation impact of thousands of test points is an important problem to consider the earliest in the design flow.  As most of the test logic today such as test compression, self-test, IEEE 1500, etc., it is expected the implementation of test points to occur pre-synthesis at RTL level.

Another important aspect to consider is related to design constraints and design collaterals which should be taken into consideration during the test point exploration and implementation design steps.  Typical related questions are: test points should belong to which power domain, to which clock domain, and to which physical partition? Managing design collaterals usually means automated management of the related design data such as UPF, SDC, LEF/DEF, etc.

Finally, beyond the TPI &E process, once test points are implemented at RTL, the impact on the design verification process is key. This includes RTL simulation, netlist elaboration, etc.

Defacto Technologies has been providing EDA DFT solutions for more than 20 years and has recently developed a new methodology to make this test point exploration and implementation process easy and straightforward. The proposed EDA TPI&E solution is structured into four steps:

Step 1: Capture user requirements and constraints

The idea here is to provide DFT engineers with the ability to introduce the expected test coverage and the afforded cost (area overhead) with different design constraints. Typical examples of constraints can be for test points which need to be excluded from certain scan chains or those which should not be part of timing critical paths., etc.

Step 2: Explore ATPG test points configuration as soon as at RTL!

Knowing that the exploration and insertion run pre-synthesis, Defacto tools fully support an automated ATPG-based RTL analysis.  For mainstream ATPGs, here the goal is to benefit from the ATPG-based list of test points and help explore their efficiency as soon as at RTL. Design constraints from SDC, UPF, LEF/DEF or similar formats, are easily considered as part of the test points exploration process.

Step 3: for the list of TPI configurations that are suggested by the ATPG, measure the quality of the list of test points and the related cost through the generated coverage/area reports.

At a glance, the most optimal test point configuration with the best trade-off is obtained.

Step 4: Once the most optimal configuration is selected, inserted test points are implemented at RTL and the final SoC top level RTL files are generated, ready for both logic synthesis and design verification processes.
Step 5: Run DFT verification tasks at RTL including the RTL simulation of ATPG vectors, testability design rule checks, linting, etc. in full compliance with design collaterals.

The above process and steps with fully automated test point exploration, implementation, and verification capabilities are part of Defacto’s SoC Compiler V10. This flow was shown to be efficient in checking and fixing test point related problems for large IPs, subsystems and SoCs. It has been used by several major semiconductor companies to quickly obtain a significant coverage improvement with a moderate area increase.

Worth mentioning that this solution is vendor agnostic and fully interoperates with mainstream DFT implementation flows. As a result, the overall DFT throughput is drastically improved as soon as at RTL. The obtained experiments clearly show the potential of this unique DFT flow to help face the key DFT challenges.

Defacto Team will be attending the International Test Conference in Anaheim on October 9th to present this Test Point Exploration & Implementation Solution. Feel free to contact them to request a meeting, a demo, or an evaluation: info_req@defactotech.com.

Also Read:

Defacto Celebrates 20th Anniversary @ DAC 2023!

WEBINAR: Design Cost Reduction – How to track and predict server resources for complex chip design project?

Defacto’s SoC Compiler 10.0 is Making the SoC Building Process So Easy


Cyber-Physical Security from Chip to Cloud with Post-Quantum Cryptography

Cyber-Physical Security from Chip to Cloud with Post-Quantum Cryptography
by Kalar Rajendiran on 10-02-2023 at 10:00 am

Secure IC Product Tree

In our interconnected world, systems ranging from smart cities and autonomous vehicles to industrial control systems and healthcare devices have become everyday components of our lives. This fusion of physical and digital systems has led to a term called cyber-physical system (CPS). Ubiquitous connectivity is exposing the systems to a wide range of cyber-threats and robust security measures are needed to safeguard the systems.

Securing the Chip, the Cloud and the Communications

At the heart of cyber-physical systems are the chips that control various functions. Securing these chips is crucial because compromised hardware can lead to vulnerabilities that are nearly impossible to detect. Cryptography plays a role at this level by ensuring that the communication between different components of a chip is secure and the data is protected. One of the exciting developments in chip-level security is the integration of hardware-based security features that work in tandem with cryptographic protocols. These features can include physically unclonable functions (PUFs), secure enclaves, and tamper-resistant designs. Such measures not only protect data at rest but also help prevent attacks on the chip’s operation. In the context of CPS, secure communication between devices and the cloud is paramount. Whether it’s transmitting data from sensors in an industrial setting or updating the software on an autonomous vehicle, the integrity of this communication is imperative. And, the cloud is where the data from CPS is often processed, stored, and analyzed and is a prime target for cyberattacks. Leveraging cryptography in cloud security protocols is vital to safeguarding the data and services hosted on the cloud. This ensures that even if bad actors gain access to the cloud infrastructure, they won’t be able to decipher sensitive information.

The field of cryptography is quite advanced and time-tested encryption algorithms such as RSA and ECC have been widely-deployed to ensure cyber-security of connected systems. But dedicated hardware support is very important as secure processing and management cannot be accomplished solely with software.

But the onset of quantum computing poses a significant threat to current cryptographic methods.

Post-Quantum Cryptography (PQC)

To counter the quantum threat, researchers are developing post-quantum cryptography, a new generation of cryptographic techniques that are designed to withstand attacks from quantum computers. These cryptographic methods are being designed to be quantum-resistant, ensuring that the confidentiality and integrity of data remain intact in a quantum-powered world. Post-quantum cryptographic algorithms can be employed to secure the communication channels, ensuring that data remains confidential and protected from quantum eavesdropping. Techniques like lattice-based cryptography, code-based cryptography, and hash-based cryptography offer robust security even against quantum adversaries. While PQC is in various stages of standardization currently, what customers need now are solutions that can be easily upgraded to incorporate PQC.

The ease of upgrading CPS to incorporate PQC protection is essential in order to expect rapid adoption of cyber-threat safeguards across a very wide base of systems. This means deploying embedded security systems that are PQC ready. Secure-IC offers solutions that fit this criterion.

Secure-IC’s Securyzr: Ultimate Solution for Embedded Security

Securyzr delivers state-of-the-art hardware and software security solutions, designed to meet the demands of a wide range of applications, from IoT devices and automotive systems to critical infrastructure and smart cards. With a focus on adaptability, scalability, and efficiency, Securyzr seamlessly integrates into existing systems while ensuring they remain impervious to attacks. Securyzr’s quantum-resistant cryptographic algorithms, ensure data remains safe and confidential even in the era of quantum computing. Its hardware-based Root of Trust, protects against unauthorized access and tampering and its secure boot and firmware update mechanisms prevent malicious code injection. Evolving threats can be handled with ease by employing dynamic security policies that can be updated remotely, ensuring that devices can stay secure throughout their lifecycle. Embedded systems can meet evolving industry-specific security standards and certifications easily.

Secure-IC’s Laboryzr: Unlock the Power of Security Testing

Laboryzr is a comprehensive security testing platform that enables thorough evaluation of the robustness of integrated circuits (ICs), embedded systems, and software applications. With a powerful suite of testing modules and an intuitive user interface, Laboryzr simplifies the complex process of security assessment. Laboryzr provides in-depth security analysis and identifies vulnerabilities and weaknesses in your products, allowing you to address them proactively. By simulating real-world cyberattacks, Secure-IC performs penetration testing to evaluate a system’s resistance to external threats. It performs side-channel analysis to detect potential information leakage through side-channel attacks and allowing to mitigate them, securing sensitive data from unauthorized access. Laboryzr also provides detailed, actionable reports that help you understand the security posture of your systems and make informed decisions to enhance protection.

Secure-IC’s Expertyzr: Elevate Your Expertise in Embedded Security

Expertyzr is a cutting-edge educational platform, crafted to empower professionals, engineers, and security enthusiasts with the expertise needed to navigate the complex landscape of embedded security. With a wealth of resources, hands-on labs, and expert insights, Expertyzr is a gateway to mastering the art of secure embedded systems. The educational platform covers a wide scope from standardization to design principles, evaluation, and certification schemes among many other topics of interest.

Summary

As we continue to embrace cyber-physical systems in our daily lives, the security of these interconnected systems becomes paramount. While quantum computing poses a significant threat to current cryptographic methods, PQC offers a promising solution to protect CPS, from the hardware level in chips to the cloud.

To learn more about solutions for implementing secure CPS systems for the post-quantum era, visit www.secure-ic.com.

Also Read:

How Do You Future-Proof Security?

Points teams should consider about securing embedded systems


Extension of DUV Multipatterning Toward 3nm

Extension of DUV Multipatterning Toward 3nm
by Fred Chen on 10-02-2023 at 8:00 am

Extension of DUV Multipatterning Toward 3nm

China’s recent achievement of a 7nm-class foundry node using only DUV lithography [1] raises the question of how far DUV lithography can be extended by multipatterning. A recent publication at CSTIC 2023 indicates that Chinese groups are currently looking at extension of DUV-based multipatterning to 5nm, going so far as to consider use 6 masks for one layer [2]. Comparing the DUV-based and EUV-based approaches going towards 3nm leads to an interesting conclusion.

LELE Patterning

The most basic form of multipatterning is the so-called “Litho-Etch-Litho-Etch” (LELE) approach, which is essentially doing the basic lithography followed by etching twice. This enables a halving of pitch, as a second feature is inserted between two printed first features. By extension, LE3 (3xLE) and LE4 (4xLE) may follow. However, using these approaches for getting to less than half the original pitch is no longer favored, with the arrival of self-aligned spacer patterning.

Self-Aligned Spacer Patterning

Self-aligned spacer patterning has the advantage over LELE of not requiring an extra lithography step, thereby saving the extra cost. Spacer deposition and subsequent etchback, followed by gapfill and subsequent etchback, replace the coat, bake, expose, bake, develop lithography sequence. While much cheaper, precise process control is still required, such as spacer thickness and etch rate selectivity. A one-time spacer application leads to feature doubling within a given pitch. Hence this is often referred to as self-aligned double patterning (SADP). Re-application leads to self-aligned quadruple patterning (SAQP), as may be expected.

Subtractive Patterning

While LELE and SADP both naturally add features to a pattern, it is sometimes necessary to remove parts of those features for the final layout. Cut masks indicated areas where line segments are to be removed. These are also called block locations when the line-forming etch is blocked. The inverse mask is called a keep mask. Restricting a line break to a single line width has placement issues if the adjacent line can also be etched. When alternate lines can be arranged to be made from different materials to be etched, line breaks can be made with better tolerances (Figure 1).

Figure 1. Self-aligned block/cut only removes sections of alternate lines.

For a given interconnect line, the distance between breaks is expected to be at least two metal pitches. Thus, two masks per line are expected when the metal pitch is from 1/4 to 1/2 of the resolution limit.

Figure 2. Two sets of block/cut masks are required for the two sets of etch.

Alternate Line Arrangement

Arranging the alternate lines is natural by LELE, SADP, SAQP or a hybrid of LELE and SADP known as SALELE (self-aligned LELE) [3]. SALELE has already been considered the default use for EUV for the tightest metal pitches [2, 4].

DUV vs. EUV Cost Assessment

One of the expectations for multipatterning with DUV has been burgeoning cost, relative to EUV. It is time for an updated re-assessment. First, we use the latest (2021) normalized patterning cost estimates [5] (Figure 3).

Figure. 3 Normalized costs for patterning, from Reference 5.

Next, we use representative patterning styles for DUV and EUV for the various nodes (Figure 4).

Figure 4. DUV vs. EUV patterning costs vs. node

Several comments are in order:

  1. For 7nm DUV, 40 nm pitch is at a point where the only features that can be resolved are lines, so these lines have to be cut in a separate exposure.
  2. For 7nm EUV, a separate line cut is used since at 40 nm pitch, the required resolution (~20 nm) is less than the point spread function of the EUV system (~25 nm). A High-NA EUV system is also not advantageous for this pitch, because of depth of focus and pupil fill limitations [6].
  3. For 3/5nm DUV, LELE SADP is more flexible than SAQP for sub-40 nm pitch [7].
  4. For 3/5nm EUV, the driving force of using LELE is the stochastic behavior at <17 nm half-pitch and <20 nm isolated linewidth [8,9]. As we approach 10 nm dimensions, the electron scattering dose-dependent blur [10-12] will also become prohibitive. The optical resolution of the system, i.e., NA, is no longer relevant.
  5. Pattern shaping is not considered as a way to eliminate cuts, as it would make the pre-shaping lithography much more difficult (Figure 5). Also, angled ion beam etching has generally been used to flatten pre-existing topography, reducing the etch mask height [13].

Figure 5. For pattern shaping the pattern before shaping is very litho-unfriendly.

For the most part, we can make the direct judgment that DUV LELE is much cheaper than EUV single exposure (SE). Also, DUV LE4 is cheaper than EUV double patterning. Although LELE requires extra steps over SE, there is also the consideration of EUV system maintenance vs. DUV system maintenance, as well as energy consumption. DUV LELE uses half as much energy as EUV SE, DUV SADP about 2/3, and even DUV LE4 uses just under 85% of the energy for EUV SE [14].

All this serves to highlight that moving to advanced nodes requires facing growing cost, regardless of DUV or EUV choice.

References

[1] https://www.techinsights.com/blog/techinsights-finds-smic-7nm-n2-huawei-mate-60-pro

[2] Q. Wu et al., CSTIC 2023.

[3] Y. Drissi et al., Proc. SPIE 10962, 109620V (2019).

[4] R. Venkatesan et al., Proc. SPIE 12292, 1229202 (2022).

[5] S. Snyder et al., 2021 EUVL Workshop, https://www.euvlitho.com/2021/P2.pdf

[6] F. Chen, When High NA is Not Better Than Low NA in EUV Lithography, 2023, https://www.youtube.com/watch?v=10K5i4QdLBU

[7] S. Sakhare et al., Proc. SPIE 9427, 94270O (2015).

[8] L. Meli et al., J. Micro/Nanolith. MEMS MOEMS 18, 011006 (2019).

[9] D. De Simone and G. Vandenberghe, Proc. SPIE 10957, 109570Q (2019).

[10] A. Narasimhan et al., Proc. SPIE 9422, 942208 (2015).

[11] I. Bespalov et al., ACS Appl. Mater. Interfaces 12, 9881 (2020).

[12] F. Chen, Modeling EUV Stochastic Defects With Secondary Electron Blur, https://www.linkedin.com/pulse/modeling-euv-stochastic-defects-secondary-electron-blur-chen

[13] M. Ulitschka et al., J. Europ. Opt. Soc. – Rapid Pub. 17:1 (2021).

[14] L-A. Ragnarsson et al., 2022 Electron Dev. Tech. Manuf., 82 (2022).

This article first appeared in LinkedIn Pulse: Extension of DUV Multipatterning Toward 3nm

Also Read:

Stochastic Model for Acid Diffusion in DUV Chemically Amplified Resists

Advancing Semiconductor Processes with Novel Extreme UV Photoresist Materials

Modeling EUV Stochastic Defects with Secondary Electron Blur


The True Power of the TSMC Ecosystem!

The True Power of the TSMC Ecosystem!
by Daniel Nenni on 10-02-2023 at 6:00 am

logo chart 092623

The 15th TSMC Open Innovation Platform® (OIP) was held last week. In preparation we did a podcast with one of the original members of the TSMC OIP team Dan Kochpatcharin. Dan and I talked about the early days before OIP when we did reference flows together. Around 20 years ago I did a career pivot and focused on Strategic Foundry Relationships. The importance of the foundries was clear to me and I wanted to be an integral part of that ecosystem. As it turns out it was a great career move, absolutely.

Before I get to the importance of the early TSMC reference flow days let’s talk about the recent OIP event. It was held at the Santa Clara Convention Center and it was a full house. For those other semiconductor event coordinators, if you want full semiconductor attendance use the Santa Clara Convention Center. Local hotels or the San Jose Convention Center are not convenient and convenience means attendance. TSMC switched to the Santa Clara Convention Center from San Jose a few years back and the rest as they say is history, TSMC hosts the best semiconductor networking events.

This year OIP was all about packaging and rightly so. It is the next foundry battleground and TSMC is once again building a massive ecosystem appropriately named the 3D Fabric Alliance:

TSMC Announces Breakthrough Set to Redefine the Future of 3D IC New 3Dblox 2.0 and 3DFabric Alliance Achievements Detailed at 2023 OIP Ecosystem Forum

“As the industry shifted toward embracing 3D IC and system-level innovation, the need for industry-wide collaboration has become even more essential than it was when we launched OIP 15 years ago,” said Dr. L.C. Lu, TSMC fellow and vice president of Design and Technology Platform. “As our sustained collaboration with OIP ecosystem partners continues to flourish, we’re enabling customers to harness TSMC’s leading process and 3DFabric technologies to reach an entirely new level of performance and power efficiency for the next-generation artificial intelligence (AI), high-performance computing (HPC), and mobile applications.”

L.C. Lu has been part of the TSMC OIP since the beginning, he worked for Dr. Cliff Hou. From 1997 to 2007 Cliff established the TSMC PDK and reference flow development organizations which then led to the OIP. Cliff Hou is now TSMC Senior Vice President, Europe & Asia Sales and Research & Development / Corporate Research.

L.C. updated us on the progress of the 3D Alliance and 3D Blox which is an incredible piece of technology that is open to all customers, partners and competitors alike. It is an industry standard in the making for sure. We covered 3D Blox HERE and TSMC gave us this update:

Introduced last year, the 3Dblox open standard aims to modularize and streamline 3D IC design solutions for the semiconductor industry. With contribution from the largest ecosystem of companies, 3Dblox has emerged as a critical design enabler of future 3D IC advancement.

The new 3Dblox 2.0, launched today, enables 3D architecture exploration with an innovative early design solution for power and thermal feasibility studiesThe designer can now, for the first time in the industry, put together power domain specifications and 3D physical constructs in a holistic environment and simulate power and thermal for the whole 3D system. 3Dblox 2.0 also supports chiplet design reuse features such as chiplet mirroring to further improve design productivity.

3Dblox 2.0 has won support from key EDA partners to develop design solutions that fully support all TSMC 3DFabric offerings. Those comprehensive design solutions provide designers with key insights to make early design decisions, accelerating design turnaround time from architecture to final implementation.

TSMC also launched the 3Dblox Committee, organized as an independent standard group, with the goal to create an industry-wide specification that enables system design with chiplets from any vendors. Working with key members including Ansys, Cadence, Siemens, and Synopsys, the committee has ten technical groups of different subjects and proposes enhancements to the specs and maintain the interoperability of EDA tools. Designers can now download the latest 3Dblox specifications from the 3dblox.org website and find more information about 3Dblox and its tool implementation by EDA partners.

Back to the reference flows, I was the Strategic Foundry Relationship Advisor for Solido Design Automation out of Saskatoon Canada and Berkeley Design Automation (BDA) in Silicon Valley at the time. Back then EDA included a lot of point tools inside the design flow since no one company could do it all. So all of the point tool companies looked to TSMC for guidance on how to interoperate inside a customer’s design flow. This was not only valuable experience, it provided much needed exposure for EDA start-ups to the TSMC customer base. In the case of Solido and BDA, it not only led to rapid adoption by TSMC’s top customers, TSMC itself licensed the tools for internal use which is the ultimate seal of approval. Solido and BDA were both acquired by Seimens EDA and their close relationships with TSMC was a big part of that transaction, believe it.

A similar process was developed for silicon proven IP. I am also a Foundry Relationships Advisor for IP companies and not only do we get access to TSMC’s top customers, TSMC allows access to PDKs and taught us how to silicon prove our products. Notice on the TSMC OIP partner list the biggest market segment is IP companies for these exact reasons. IP is a critical enabler for the foundry business and getting silicon right the first time is what OIP is all about.

Bottom line:  In the foundry business it’s all about collaboration and TSMC built this massive ecosystem from the ground up. Not only does it reduce customer risk of designing to new processes, the close collaboration between TSMC and the ecosystem partners multiplies the total annual ecosystem R&D investments exponentially.

Also Read:

TSMC’s First US Fab

The TSMC OIP Backstory

The TSMC Pivot that Changed the Semiconductor Industry!


Micron Chip & Memory Down Cycle – It Ain’t Over Til it’s Over Maybe Longer and Deeper

Micron Chip & Memory Down Cycle – It Ain’t Over Til it’s Over Maybe Longer and Deeper
by Robert Maire on 10-01-2023 at 6:00 pm

china 800 pound gorilla
  • The memory down cycle is longer/deeper than many thought
  • The recovery will be slower than past cycles- a “U” rather than “V”
  • AI & new apps don’t make up for macro weakness
  •  Negative for overall semis & equip- Could China extend downcycle?
Micron report suggests a longer deeper down cycle than expected

The current memory downcycle started in the spring of 2022, over a year ago with Micron first reporting weakness. We had suggested that the current memory downturn would be longer & deeper than previous downturns given the unique circumstances and was roundly criticized as too pessimistic.

It now looks like the memory downturn will last at least two years (if not longer) and its clearly worse and longer than most prior cycles. It seems fairly clear that there will be no recovery in 2023, as we are already past the peak season for memory sales, and at best maybe sometime in 2024.

Typically memory peaks in the summer prior to the fall, busy selling season of all things electronic. We then go through a slow Q1 due to post partum depression after the holiday sales coupled with Chinese holidays in Q1. Thus it looks like summer 2024 is our next opportunity for better pricing.

The problem is that “analysts” always kick the can down the road in 6 month increments saying that things will get better in H1 or better in H2 etc;. So don’t listen to someone who now says an H1 recovery in 2024 as its just another kick of the can, without hard facts to back it up.

A “Thud” rather than a “Boing”- sounds of the cycle

The last memory downcycle several years ago seemed more like a “one quarter wonder” with things quickly bouncing back to normal after a short spending stop by Samsung.

This leads investors to believe that we were in a “V” shaped bottom when its obviously a “U” or worse yet “L” shaped bottom.

The down turn this time is not just over supply created by over spend but it is also coupled with reduced demand due to macro issues.

We have cut back on supply by holding product off market in inventory, slowing down fabs and cutting capex none of which can fix the demand issue. Perhaps the bigger problem is that product held off market needs to be eventually sold and factories running at less than full capacity beg to be turned back up to full capacity to increase utilization and profitability so any near term uptick in demand will quickly be offset by the existing excess capacity thus slowing a recovery.

We haven’t even started talking about all the potential increase in capacity related to Moore’s law density increases that increases the number of bits per wafer produced due to just ongoing technology improvements.

Bottom line:  There is a ton of excess memory capacity with weak demand to sop it all up, it’s gonna take a while.

China can and will likely stifle a memory recovery

The other 800lb gorilla problem that most in the industry haven’t spoken about is China’s entry into the memory market and what that will do to the current down cycle and the resulting market share impacts.

Most in the industry look at the supply/demand balance in memory chips as a static market share model. But its not.

China has been spending tons of money, way more than everyone else, on semiconductor equipment. Not just for foundry and trailing edge but for memory as well. While China is not a big player in memory right now they are spending their way into a much bigger role.

All that equipment shipped into China over the last few years will eventually come on line and further increase the already existing oversupply in memory chips.

Many would argue that China is not competitive in memory due to higher cost less efficient technology but we would argue that China is not a semi- rational player like Samsung or Micron and will price its product at whatever money losing price they need to to gain market share and crush competition. Kind of like what Samsung has done in the memory market but only with state sponsored infinite money behind it.

China is a “wild card” in the memory market that could easily slow or ruin any recovery in the memory market and take share from more rational players or weaker players, such as Micron, who don’t have the financial resources to lose as much money to survive.

In short, China can screw up any potential memory chip recovery and delay it further.

AI and other new apps are not enough to offset weakness & oversupply

High bandwidth memory needed for AI applications is obviously both hot and under supplied. Capacity will shift to high bandwidth memory but not enough to reduce the currently very oversupplied market. The somewhat limited supply of AI processors will also limit high bandwidth memory demand because there aren’t enough processors available and you are not going to buy memory if you can’t get processors.

$7B in capex keeps Micron treading water

Micron talked about $7B in capex for 2024 which likely is just enough to keep their existing fabs at “maintenance” levels.

With the current excess capacity in the memory market coupled with technology based capacity improvements and the threat of China, building new fabs in Boise or New York is a distant dream as it would be throwing gasoline on an already raging bonfire of excess capacity.

We don’t see a significant change in capex on the horizon and most will continue to be maintenance spend.

Both Huawei/SMIC and Micron go “EUV-less” into next gen chips

Further proof of the ability to continue on the Moore’s Law path without EUV has recently been provided by Micron.

It would appear that the latest and greatest memory chip, the LPDDR5 16GB D1b device, which made its debut in the IPhone 15 was made without $150M EUV tools just like the 7NM Huawei/SMIC chip.

Where there’s a will there’s a way…….Micron has always been a bunch of very cheap and very resourceful people who think outside the box and they have done so with this latest generation device without EUV that others are using.

In this case, doing it without EUV at Micron likely means producing it at lower cost

Link to article on EUV-less 16GB D1b chip from Micron

This just underscores our recent article about China’s ability to skirt around the semiconductor sanctions that ban EUV. They will be able to do it in memory as well.

The Stocks

Obviously this is not great news for the stock of Micron. We were even somewhat surprised that there wasn’t a worse reaction and the broader semiconductor market was positive today.

Memory oversupply/demand weakness is coincident with broader semiconductor malaise. The weak capex predictions are certainly a negative for the chip equipment providers.

For Micron specifically we remain concerned about continued losses and what that does to their balance sheet and ability to recover when the time comes. They are certainly burning through a lot of cash and if we do the math, aren’t going to have a lot left at the end of the downcycle assuming we get an end to the downcycle soon (which is not clear)

There is an old joke about Micron that if you totaled up all the profits and losses over the life of the company it would be a negative number. We haven’t revisited that exercise of late but wonder where we are…..and getting worse.

We don’t see any reasonable reason to own the shares of Micron especially at current levels. The stock is well off the bottom yet business is not and we don’t have a definitive recovery in sight.

Risks remain quite high, China is a risk to Micron in several ways and their financial strength, which is important in the chip business, is dwindling fast.

At this point there are less risky semiconductor investments, even at higher valuations, that seem more comfortable.

But then again, Micron stock has never been for the faint of heart…for a reason

Also Read:

Has U.S. already lost Chip war to China? Is Taiwan’s silicon shield a liability?

ASML-Strong Results & Guide Prove China Concerns Overblown-Chips Slow to Recover

SEMICON West 2023 Summary – No recovery in sight – Next Year?