Semiwiki EDA Webinar 800x100
Semiconductor Expert Forum

Posted on

CEO Interview: Tamas Olaszi of Jade Design Automation

CEO Interview: Tamas Olaszi of Jade Design Automation
by Daniel Nenni on 02-25-2022 at 6:00 am
Categories: CEO Interviews, EDA, Jade Design Automation

Tamas Olaszi
rpt

Why does the industry need another register management tool? This is a question that Tamas Olaszi, the founder of Jade Design Automation hears from time to time since Jade-DA brought Register Manager, their EDA tool, to market. So why?

There is a genuine answer to this question but first let me use this interview to give some helpful information to the Semiwiki audience. Some people will come here while looking for a new register management solution for a startup or replace an existing solution that has some issues. I would like to give them an overview of this space so they can make an informed decision. What commercial register management tools are out there? How to manage the HW/SW interface? How to generate Verilog from CSRs? Is there an open source SystemRDL tool? Can we use IP-XACT for capturing our register descriptions?

Ok, so who are the commercial tool vendors in this space?

At the time of this interview, in alphabetical order they are Agnisys, Jade Design Automation, Magillem (acquired by Arteris now) and Semifore. However, the history here is quite interesting. Commercial tools for register management started to appear around 2006-2008. Jade-DA was not around at that time but the other three started roughly at the same time. There was a fourth player though, called Duolog Technologies and I was working there as a Hardware Design Engineer when Duolog launched its Bitwise product. I transitioned into an FAE role supporting Duolog’s register management tool and lived and worked in India, France, US and Ireland as well in the subsequent years. I had the chance to see the adoption of these tools by various semiconductor companies around the globe and gather first hand customer feedback. Duolog was doing quite well with its EDA tools and the company was acquired by Arm in 2014 which stirred up things a little bit.

At Arm, I first was responsible for an internal tooling team and we were developing and customizing register management and SoC assembly tools for Arm’s specific needs. I then moved on to manage an open source embedded software team responsible for writing the SW for the IoT test chips of Arm. This was also very educational to me as I now have been involved in the last piece of the HW/SW interface jigsaw puzzle – I have experienced the full workflow from the first time when the System Architect drafts up the top level memory map to the last bit when the SW engineers checks in the last driver code for the Board Support Package to bring up the chip. I thought my tooling days were behind me at this stage but then on a sunny Tuesday morning Arm announced that it would discontinue the Duolog EDA product line.

This was an understandable move from an IP company that acquired an EDA company – they repurposed the tools they needed to do IP configuration and discontinued the ones that were not related to the core business. This proved to be a seminal moment for me and this led eventually to the founding of Jade Design Automation.

You mentioned that you were leading an internal tooling team. Shouldn’t internal tools be right choice for register management?

They can be. Really, the main advantages of the internal solution is that it is tailored to the company’s needs and that the support is that nice person sitting two seats away from you. This kind of flexibility has a very real value and it is a cliche in our industry that our biggest competitor is the internal solution. Many great people came up with many great solutions at different companies.

The risk here is maintenance. Those aforementioned great people may get promoted, would like to take their career in a different direction or change jobs. There is also a cost which is invisible because it is not monetary but opportunity cost. Usually the person maintaining the internal solution is a very capable HW design or verification engineer who could work on the core business of the company.

Then there are other free alternatives like various open source solutions. What do you think about those?

Again, those could be a viable alternative as well. There are many of them and I am going to list the few here that I know of in order to help people evaluate their options. At various stages I came across airhdl, pyrift, a register tool in the Open Titan project and systemrdl-compiler. Out of these, SystemRDL Compiler is the project I followed more closely and I greatly admire the work of the guy who is behind the project.

What I have heard from talking to people is that these open source projects tend to become the basis of an internal tool. They are great for jump starting the deployment of a register management solution but they usually need to be tailored to the company’s needs so they kind of get forked internally and built upon.

So with these, how would a company select a register management solution?

I suppose the factors they need to take into account are the following:

  • Data model – should it be a standard like IP-XACT or SystemRDL or proprietary that offers more flexibility
  • Features – what kind of generators they need, how big their designs, what are their performance requirements, do they need a GUI, etc.
  • Flexibility – it is very likely that every solution out there will need some level of customization so it is important to know how easy it is to custom fit the solution
  • Support – I suppose the turnaround time matters here the most, whether getting a fix to a problem takes two days or two months
  • Cost – which is self explanatory

The commercial vendors all made their decisions regarding the data model, the tool architecture and the business model. The open source solutions can also be evaluated along these criteria and of course the internal solution leaves all these open.

Can we get an answer now to the original question? Why does the industry need another register management tool?

At that moment when it was announced that Arm would discontinue the Duolog EDA line, I felt that this could be a great opportunity. The team there built up a lot of experience in the domain of register management both with a small EDA company supporting customers worldwide and as part of an internal tooling team of a major semiconductor company. There was the chance to build something new that would incorporate all these experiences into a tool built on a modern data model with modern technologies.

The fact that there is still a plethora of different solutions out there, commercial, internal and open source alike shows that this problem is still not convincingly solved. Most solutions stop at about 80% where it is “good enough” for that particular company or individual – but not necessarily for everyone else. In my vision, it is possible to have the holy grail of data models that cover almost all of the required constructs across the industry and leave only the last mile to a flexible customization framework. With that, we could reach a de-facto standard for register management which would also enable seamless transfer of register data within the ecosystem.

With this interview, I didn’t want to pretend that we exist in a vacuum. Our potential customers have a variety of options to choose from. There are all these factors of data model, feature set, flexibility, support and cost that they need to take into account and each company puts different weight on them. I am happy to lay all the cards on the table because I am quite confident that Jade Design Automation’s Register Manager can compete head-on with any of the alternatives.

https://jade-da.com/

Tamas Olaszi, the founder of Jade Design Automation, started his career as a HW design and verification engineer at an Irish design service company. Along with the company, he pivoted into the world of EDA working as a Field Application Engineer while living and working in India, France, Ireland and the US for several years. Along these years he worked closely with companies like Texas Instruments, Qualcomm, Western Digital and Nokia among others. After the company’s acquisition, he worked at Arm for five years where he was responsible for building up and managing an open source embedded SW team with a remit of building a secure SW foundation for the IoT test chips of Arm. Since founding Jade Design Automation in 2019 he is working towards a vision of a register management tool that outperforms all of the alternatives in all the relevant metrics.

Also read:

CEO Interview: John Mortensen of Comcores

CEO Interviews: Kurt Busch, CEO of Syntiant

CEO Interview: Mo Faisal of Movellus

Posted on

Integrated 2D NoC vs a Soft Implemented 2D NoC

Integrated 2D NoC vs a Soft Implemented 2D NoC
by Kalar Rajendiran on 02-24-2022 at 10:00 am
Categories: Achronix, eFPGA, FPGA

Routing of cnv2d design using Speedster7t 2D NoC

We are living in the age of big data and the future is going to be even more data centric. Today’s major market drivers all have one thing in common: efficient management of data. Whether it is 5G, hyperscale computing, artificial intelligence, autonomous vehicles, or IoT, there is data creation, processing, transmission, and storage all around us. All of these aspects of data management need to happen very fast.  Data center operators cannot afford to tolerate data traffic jams anywhere in the data path. They need to process incoming data efficiently and move the data to its destination rapidly. The underlying system hardware architecture design is a critical factor in allowing rapid data transfer.  Therefore, the selecting of the right processing architecture will have a major impact on performance.

SemiWiki has covered the Achronix Speedster7t FPGA devices and their various features in several posts because of their innovative 2D NoC features.  For rapidly moving data throughout a chip, there is little contention that a Network-on-Chip (NoC) is an excellent approach. A NoC architecture is better at moving data than a conventional bus architecture and a crossbar architecture. But should you implement your own 2D NoC on an FPGA fabric or leverage a pre-built 2D NoC? Is one 2D NoC implementation better than another? This is the question that Achronix answers in a recently published whitepaper titled “The Achronix Integrated 2D NoC Enables High-Bandwidth Designs.” Of course, the comparison study is between Achronix’s own 2D NoC and a soft implemented 2D NoC on their Speedster7t family of FPGAs. This post is a synthesis of what I gathered from the whitepaper.

The Contender 2D-NoC

The soft 2D NoC chosen for the comparison project is from Milan Polytechnic (https://github.com/agalimberti/NoCRouter, 2017) based on peer reviews and ease of portability to an FPGA fabric. It implements a wormhole lookahead predictive switching in a unidirectional mesh.

Benchmark Design

To quantify the differences between the Speedster7t 2D NoC and the soft implementation using FPGA fabric resources, a two dimensional convolution (Conv2d) design was created. This design performs AlexNet 2D convolution on an input image and contains 19 instances the Conv2d design.

The Metrics Used for Comparison

The metrics that are picked for comparison of any two solutions should be relevant and important to the solutions’ users. In the context of what is being compared, the following metrics were chosen:

  • How many resources are needed for each of the two solutions?
  • What is the performance of the design using each solution?
  • How long does it take to design and compile the design?

Results from Achronix’s 2D NoC Comparison Study

Performance

The use of the integrated 2D NoC produces an elegant, repeatable structure to place and route the design that results in regular routing with less congestion. Refer to Figure below. Using the Achronix’s integrated 2D NoC achieves a maximum frequency of 565MHz for the Conv2d design.

Routing of the Conv2 Design Using the Achronix Integrated 2D NoC

Compare the above with the complex, irregular and congested routing when using the soft implemented 2D NoC. Refer to Figure below. Timing is also compromised as deep LUT logic is needed to select the appropriate paths in the soft implemented 2D NoC.

Routing of the Conv2d Design Using the Soft Implemented 2D NoC

Design and Compile Time

The full-featured implementation of the Achronix integrated 2D NoC eliminates a large amount of design work for the users. For example, built-in features such as clock-domain crossing logic, transaction flow control, and decoding of addresses. This allows designers to concentrate just on the value added user logic connecting to the 2D NoC. Along with reduced design time, a design that utilizes the Achronix integrated 2D NoC uses fewer resources than one that uses a soft implemented 2D NoC. The result is less logic to place and route, and results in faster compile time through the tools.

Summary

The Speedster7t architecture significantly improves design productivity while making the Achronix FPGAs very effective for high-bandwidth applications. The designs benefit from reduced logic utilization, reduced memory requirements and increased performance. You can download the whitepaper here. Refer to the table below for the results from the comparative study.

Conv2d Design and Comparison of the 2D NoCs

Also read:

2D NoC Based FPGAs Valuable for SmartNIC Implementation

Five Reasons Why a High Performance Reconfigurable SmartNIC Demands a 2D NoC

Take the Achronix Speedster7t FPGA for a Test Drive in the Lab

 

Posted on

Scalable Verification Solutions at Siemens EDA

Scalable Verification Solutions at Siemens EDA
by Daniel Nenni on 02-24-2022 at 6:00 am
Categories: EDA, RISC-V, Siemens EDA

Andy Meier 2

Lauro Rizzatti recently interviewed Andy Meier, product manager in the Scalable Verification Solutions Division at Siemens EDA. Andy is a product manager in the Scalable Verification Solutions Division at Siemens EDA. Andy has held positions in the electronics and high-tech fields during his 20-year career including: Sr. Product Marketing manager at Siemens EDA, Product Marketing manager at Mentor Graphics, Solution Product manager at Hitachi Data Systems, Director of Application engineering at Carbon Design Systems, and Sr. Verification Engineer at SiCortex. He holds a Bachelor of Science degree in Engineering and Computer Engineering from Worcester Polytechnic Institute in Worcester, Mass.

Thank you for meeting with me, Andy. It is a pleasure to talk with you. One of the major challenges SoC verification and validation teams has is ensuring correct system operation with real workloads. What is at the core of this challenge?

The core of this challenge comes down to the fact that hardware and software teams have different perspectives and different debug needs when tasked with ensuring correct system operation. Often hardware and RTL design teams rely on waveforms to debug while software developers need a full-functioning software debugger. The problem is when there is an issue that they both need to be involved in, such as debug, each set of users is speaking a different debug language. They need a way to speak a common debug language and correlate between both the hardware teams and the software teams.

How is it possible for them to so call, speak a common language?

In our Codelink product, we have a correlation engine that allows our customers to do just that. It is one of the greatest strengths of Codelink. As I said the SW team is looking for a full functioning SW debugger. Being able to single step the SW execution while looking at a source code view, CPU registers and memory views of what is happening in the SoC is invaluable. To then be able to correlate that to exactly what is happening at the RTL level by looking at the waves is extremely powerful. This is what truly enables the HW/SW co-verification use case.

Can you share a real-world customer example of the HW/SW co-verification use case?

Recently, a customer came to us with a unique challenge. This customer had a six-stage boot process that jumped from CPU to CPU through the ‘power on’ sequence where the CPUs came from different vendors. Ultimately, they were tasked with integrating the IP as well as validating the multi-stage boot process of their SoC. The customers existing verification and validation methodologies didn’t have a unified way to debug this scenario. They would look at waveforms from one simulation or emulation run at a specific stage, and then use different tool sets from different CPU vendors to debug the following stage. There was no common unified debug. To make matters more challenging, the team involved in this verification and validation effort was the SoC integration team. This team didn’t have domain expertise of the hardware design, and they didn’t have the software expertise on what individual blocks were responsible for what. Still, they were tasked with validating and making sure that the SoC booted properly. They were interested in using a new solution to address their needs.

Using standard features from Codelink, like the source code view, the register view, and the correlation engine  as well as RTL Waves from an emulation run, the customer created and adopted a new methodology focused on unifying their debug. Using this new methodology, they were able to look at the multi-core capabilities of their SoC and debug the software execution as it jumped through the various stages to ensure things were operating as expected.

That’s quite interesting. Beyond what you just described, what are some current industry trends that present other challenges?

In terms of trends, we see the use cases expanding beyond just traditional SW debug and HW/SW co-validation. Customers have expanding SoC requirements, and these requirements are driving new opportunities for expansion of SW-enabled verification.

For example, customers are trying to understand how their software is performing. They are trying to understand the behavior of different event handlers execution, and if those event handlers are executing within the budgeted amount of time. To address this additional use case in an emulation environment, we have added into our Codelink tool software performance profiling. This allows customers to identify where the time is being spent, and the functions that are called most frequently. This is key for customers that are working on hardware and software partitioning or customers trying to tune their SoC performance. One can imagine a case where an event handler is supposed to execute within a certain amount of time, but for one reason or another, it doesn’t. The customer can now isolate where the time is being spent from a software perspective, and then tune the performance.

We’ve also recently seen from both simulation and emulation customers, where providing SW code coverage helped aid in the SW verification and validation. An example where this was used, was when the customer’s SW-enabled verification methodology had randomly generated SW in it. The randomly generated SW acted like test vectors for their SoC. Due to its random nature, the customer needed to know exactly what SW test scenarios had been covered and executed. We’ve added SW code coverage to Codelink to address this need. All that was needed from the customer was the software executable and debug symbols, which they already needed to execute the workload. The validation team can now look at the SW Code coverage report and see what statements, functions, conditions, or branches were covered during the execution.

What other industry trends are you seeing?

With different SoC market verticals, such as automotive, IoT, 5G, Enterprise Data Centers, etc., we have seen a need to increase our collaboration with our CPU IP partners. Over time, we’ve built strong partnerships in collaboration with different IP suppliers to provide Codelink debug capabilities for those CPU IPs. Recently we have seen a significant increase in requests for RISC-V CPU support from the RISC-V community. In collaboration with SiFive, we have been able to add Codelink support for several SiFive CPUs. This is just one example. By being CPU IP vendor agnostic, it allows us to work with all the IP vendors to meet the customers needs.

There is some interesting work going on in this space, Andy. Thank you again for your time. Maybe we can catch up in a year and look at your continued progress.

Also read:

Power Analysis in Advanced SoCs. A Siemens EDA Perspective

Faster Time to RTL Simulation Using Incremental Build Flows

SIP Modules Solve Numerous Scaling Problems – But Introduce New Issues

Posted on

Working with the Unified Power Format

Working with the Unified Power Format
by Daniel Payne on 02-23-2022 at 10:00 am
Categories: Defacto Technologies, EDA

UPF design flow min

The Accellera organization created the concept of a Unified Power Format (UPF) back in 2006, and by 2007 they shared version 1.0 so that chip designers would have a standard way to communicate the power intentions of IP blocks and full chips. By 2009 the IEEE received the Accellera donation on UPF , reviewed multiple drafts and published IEEE Std 1801-2009, also known as UPF 2.0. In 2013 the IEEE updated it to 1801-2013, or UPF 2.1. Updates to UPF continued into 2015 and 2018 as well.

Why do we even need UPF? 

RTL languages like VHDL and SystemVerilog don’t include the notion of power intent, just logic functionality, so something needed to be added for power intent. Here’s an EDA tool flow showing where power intent files are used during design, verification and even implementation:

Source: IEEE

What’s Inside a UPF File?

Power intent is defined using an extension of the Tool Command Language (Tcl) and has the following components:

  • Power Domains
  • Power Supply Network
  • Power State Table
  • Isolation Strategies
  • Retention Strategies
  • Level Shifter Strategies
  • Repeater Strategies

Who Creates UPF Files?

Your IP vendors supply RTL code, and constraint UPF file, then your design team adds a  configuration UPF file for the specific context. Implementation-specific UPF files are also added along the way, so the EDA tool flow becomes:

UPF files and tool flow

How about using Hierarchy?

UPF supports both flat and hierarchical descriptions, and in general it’s recommended to align power domains with your logic hierarchy to keep life simple. If you choose to implement your design from the bottom-up, then ports need to be added in your UPF descriptions.

In a traditional bottom-up methodology an engineer would read all of the UPF files, then start manually editing each UPF file to ready them for merging into a top file. The UPF top-level file would be manually created, with care made to verify that proper syntax was typed. The power rules would also be verified before and after promotion.

Here’s a diagram showing a simple chip design example with four instances, named A, B, C, D; and at the top-level you can describe this with either hierarchy (left side), or as a flat design (right side):

UPF hierarchy or flat

With the hierarchy example on the left, we have five UPF files, while in the flat example on the right only one UPF file. Switching between using UPF hierarchy or flat is called promotion or demotion, and as you can imagine involves some detailed Tcl editing. Sure, you could manually do these operations and hope that you got all of the edits correct, or you could use an EDA tool designed for this purpose.

Going from a single, flat UPF file to a hierarchical collection of UPF files is called demotion, and once again, there is manual editing required. If any RTL code is modified during this process, then that adds more UPF file editing.

Thanks to EDA vendor Defacto Technologies we now have such an EDA tool to manage jointly UPF and RTL pre-synthesis through SoC Compiler. During the front-end SoC build process a design team has many files to manage, and SoC Compiler enables an engineer to quickly work with RTL, IP-XACT, UPF and SDC files.

With SoC Compiler an engineer can easily manage power-intent hierarchy, out of the box, with two simple APIs: promote_power_intent, demote_power_intent. Typical applications where UPF promotion and demotion are used in a project include:

  • When exporting an IP block from an SoC for reuse
  • Integrating multiple IPs into an SoC
  • Using hierarchical synthesis

Summary

They say that necessity is the mother of invention, and the development team at Defacto has taken a look at how the UPF standard came about, and noted that processes like promotion and demotion to work with hierarchy has required far too many manual, error-prone editing steps. Their UPF automation embodied in the SoC Compiler tool provides much-needed relief to SoC teams by quickly using UPF promotion or demotion.

Webinar

There’s a March 10th webinar from 10AM to 11AM PST all about SoC Compiler from the team at Defacto Technologies, so sign up here.

Related Blogs

Posted on

Power Analysis in Advanced SoCs. A Siemens EDA Perspective

Power Analysis in Advanced SoCs. A Siemens EDA Perspective
by Bernard Murphy on 02-23-2022 at 6:00 am
Categories: Chiplet, EDA, Siemens EDA

Power verification methods min

The success of modern battery-powered products depends as much on useful operating time between charges as on functionality. FinFET process technologies overtook earlier planar CMOS in part because they significantly reduce leakage power. But they exacerbate dynamic power consumption thanks to increased pin capacitances. SoC designers must invest considerable effort in sophisticated strategies to reduce dynamic power across expected use-cases. The complexity of these strategies makes early power analysis in such advanced SoCs essential.

Two challenges in power estimation

Power estimation in a gate-level model, the traditional method of choice, is quite accurate but far too late in the design cycle to guide meaningful optimization. Designers need estimation during RTL design. This level of estimation is less accurate than gate-level but allows for much faster iteration on power improvements earlier in the development cycle.

A second challenge is to accurately model use-cases. Dynamic power management strategies build on turning off pieces of functionality whenever possible, sometimes down to a quite granular level of functionality. How effective this will be in reducing overall power is heavily dependent on how the SoC is exercised by the application. You can only assess meaningful options against realistic use cases such as a video game or a realistic object recognition task in a video stream. Simulation-based estimation cannot handle tasks of this complexity. These are only practical in emulation-based modeling.

Must the whole circuit be emulated?

Not at all. It is very practical to run in a hybrid mode, where some parts of the circuit run in C/C++ or Fast models on a host and others run on the emulator, with tightly managed coupling between these two. I see several needs for this approach. First, it can be valuable in early modeling where much of the circuitry may only be available in architectural models.

Second, some aspects of bring up, such as Linux boot, may not be very relevant to power estimation. This part can run on the host at near real-time speeds, not needing the detailed visibility required for power estimation. The critical part of the use-case for power estimation is where the game or object recognition starts running. This is where designers are most likely to find power bugs. Places where power spikes above an expected level. Or you expect it to drop but it doesn’t. This aspect of the use case will run on dedicated functionality in the design – GPUs, AI accelerators, and other related hardware. You can model these in the emulator, gaining fine-grained visibility into signal toggles.

Getting more ambitious

A third reason I sometimes see for hybrid modeling is to efficiently model very large designs. If an SoC contains a cluster of cores, maybe you only need to model one in RTL for early analysis purposes. You can handle the others  as software models on the host. This can speed finding and fixing many power bugs, leaving your signoff cleanup for full circuit emulation.

This approach becomes very interesting when you consider emerging chiplet-based design. In one way this is simply a scaled-up version of this third reason, although in practice there are added complexities – coherent link interfaces between chiplets and added latency in those interfaces.

Clearly the direction for pre-silicon power estimation in modern SoCs depends on emulation. Learn more about how Siemens EDA sees this domain.

Also Read:

Faster Time to RTL Simulation Using Incremental Build Flows

SIP Modules Solve Numerous Scaling Problems – But Introduce New Issues

MBIST Power Creates Lurking Danger for SOCs

Posted on

The Clash Between 5G and Airline Safety

The Clash Between 5G and Airline Safety
by Tom Simon on 02-22-2022 at 10:00 am
Categories: 5G, Ansys, Inc., EDA

5G and Airline Safety

For 5G to really deliver on its promise of high bandwidth and good coverage, it needs to use an RF band known as C-Band (3.7 to 4.4 GHz). This band is ideal because its frequency is high enough to offer 100MHz wide channels and also low enough that signal attenuation, especially in urban areas, is minimal.  In 2020 the FCC auctioned off the portion of the GHz C-Band from 3.7 to 3.98 GHz to 5G service providers. However, it is important to note that in the C-Band the range from 4.2 – 4.4 GHz, with a guard band down to 4.0 GHz, is still reserved for Aircraft Safety and Radar Systems. The segment that was auctioned off had previously been used for ground links for satellites, which posed no risk of interference with radar altimeters.

5G and Airline Safety

Unlike the previous use for satellite links, the new 5G application calls for transmitters near airports aiming signals at near ground level – the exact locations where the adjacent Radar Altimeter Band is used to assist commercial aircraft in category 3 automatic landings during restricted visibility. While the bands do not overlap there can be significant issues due to out of band transmission from the powerful 5G base stations causing receiver interference in the altitude radar equipment. In a perfect world the base stations would only produce electromagnetic radiation in their licensed band, and the radar altimeter would be able to reject any signals out of its band. However, the radar altimeter equipment was designed and approved before the new 5G interference could have been foreseen.

I had a chance to speak with Shawn Carpenter, Program Director at Ansys for 5G & Space, about this issue which has blown up in the last month or two because 5G carriers are now in the process of turning on 5G service in base stations near airport approaches. The carriers have spent billions of dollars on these band allocations, but the FAA is extremely concerned that stray emissions could leave aircraft blind on approach. We have all seen the news about the conflict between the cell carriers and the airlines. It seems that some accommodation has been reached for now, but a long-term solution is needed.

Redesigning certified aviation equipment is a complex and time-consuming process. The total power for the radar altimeter is around 1 watt. The maximum height it is used at is around 2500 feet. At this height the signal loss on return is approaching 90 db. Thus, you can see that the receiver needs to be fairly sensitive. The addition of filters is an option but there will be limitations on them due to sensitivity requirements.

Changing 5G antenna characteristics or redesigning 5G base station circuitry may provide a quicker path. No matter how the problem is mitigated there will be simulation work to assess the effectiveness based on the radar altimeter design, base station design or location. Shawn showed me how Ansys has been able to model antenna patterns for 5G AP and the radar altimeter antenna on a 777. This can be set up for specific airports to provide insight into the potential severity at each site. They also have looked at scenarios where filters are put either on the 5G base station or the Altimeter Radar input stage.

This problem will not be going away anytime soon, there are two more C-Band segments that are even closer to the Radar Altimeter band that will be auctioned off for use in the future. While there have been some missteps, there is a lot of money and potentially people’s lives at stake. So, a long-term solution will have to be worked out. Regardless of whether the radar altimeters or the base station equipment is redesigned, extensive simulation and validation of electromagnetic signal issues will be required. Full modeling of the special effects including antennas, terrain, equipment locations, etc., will need to be performed. Ansys has a series of interesting articles on their website that have more information on this issue and the techniques that can be used to ensure airline safety while meeting the needs of the 5G carriers. The first article is 5G and Aircraft Safety: How Simulation Can Help to Ensure Passenger Safety and the second one is 5G and Aircraft Safety Part 2: Simulating Altimeter Antenna Interference.

Also Read

The Hitchhiker’s Guide to HFSS Meshing

The 5G Rollout Safety Controversy

Can you Simulate me now? Ansys and Keysight Prototype in 5G

Posted on

Six Essential Steps For Optimizing EDA Productivity

Six Essential Steps For Optimizing EDA Productivity
by Kalar Rajendiran on 02-22-2022 at 6:00 am
Categories: Altair, EDA

Semiconductor Design Phases and Needs

Altair® Accelerator™ was the focus of a couple of SemiWiki posts last year. The most recent post covers the enterprise-grade job scheduler’s latest updates and an earlier one discussed its patented Rapid Scaling feature. You can refer to these blogs here. While these posts provide insight into how Accelerator can help increase EDA productivity, it is just one piece of a total solution. The Semiconductor industry is among the most technologically advanced industries. It pushes the edge on multiple fronts in all phases starting from product concept through production silicon and beyond. The complexity and variety of EDA tools required for each phase makes the task of optimizing productivity challenging.

Altair has analyzed the EDA productivity topic ‘Six ways to Sunday’ and come up with a comprehensive approach for a total solution. Altair shares the details in a recently published whitepaper titled “Six Smarter Scheduling Techniques For Optimizing EDA Productivity.” This post provides a summary of the salient points from that whitepaper.

EDA Requirements For Different Design Phases

The following table describes the functional tasks and the EDA tools used at different phases of a design cycle.

Some of the functional tasks are more compute-intensive and time-consuming than others. For example, RTL simulations on some designs can take hours or even days to execute. But gate-level simulations can be even slower, taking days or even weeks to complete. While most of the functional tasks utilize software EDA tools, some leverage hardware emulation platforms. EDA productivity initiatives are about meeting time-to-market goals by running EDA jobs as quickly and efficiently as possible. This translates to achieving high-throughput, high resource utilization, effective use of software licenses and maximizing use of on-prem and cloud-based infrastructure.

The following are the six steps involved in optimizing EDA productivity at an enterprise level.

Monitor and Measure: The Pre-requisites for Optimizing EDA Productivity

Have you ever driven over a cable that runs across one or more lanes of a road and heard a beep or two? It is the Transportation Department in action, monitoring and measuring traffic count and patterns. The data collected is analyzed to help make decisions on infrastructure projects aimed at managing and streamlining traffic flow.

Similarly, optimizing EDA productivity starts with “monitoring and measuring” as the first step. It is critical to be aware of issues such as jobs queueing for excessive periods. Or, for example, if an application requests 4GB of memory and two cores from the scheduler but only uses 1GB and one core, it is important to measure that. Additionally, with EDA licenses being as expensive as they are, ensuring they are sufficiently allocated to the most critical projects without being in costly surplus is essential.

Tools like Altair® Monitor™, a real-time license monitoring and optimization solution, and , Altair® Mistral and Altair® Breeze™, which provide live system telemetry and I/O monitoring, are available for this step. Based on information gathered through these tools, administrators can tune scheduling policies to maximize utilization and improve productivity. For example, Breeze can provide detailed analysis of all I/O activity of an application, based on which the optimal place for storing files can be established.

Job Scheduling for High-Throughput

Job schedulers need to consider job dependencies, time window policies, and relative priorities of jobs among other things. Schedulers should also be capable of job preemption and resource reservations to support urgent jobs. The number of demands on the scheduler plays a direct role in the throughput that can be achieved. And the internal design of the scheduler can also affect the throughput. The Figure below shows the difference between a cycle-based scheduler and an event-based scheduler.

Altair Accelerator is an event-based enterprise-grade job scheduler that delivers high-throughput for even the most demanding EDA requirements. For environments needing an even higher throughput, Altair’s customers can deploy the Altair® Accelerator™ Plus, a hierarchical scheduler architected to offload the base scheduler. Accelerator Plus can help customers realize a 6-10x throughput improvement without changes to the workloads themselves.

License Matching for High-Throughput

A job scheduler needs to take license availability before dispatching EDA jobs. There are a number of common strategies for handling license resources. However, even the most sophisticated strategies can fall short under certain circumstances. For example, periodically checking for license availability with a configurable linger period should work in theory,  but optimally configuring this linger period is difficult in practice. Consequently, jobs may fail due to unavailable licenses or wait in the queue pending license availability when licenses are actually available.

To overcome these complexities, Altair employs license matching to achieve better utilization. Accelerator maintains an internal table that matches license checkouts reported by the license manager to jobs known to the scheduler. License matching, together with an event-based scheduler, can deliver higher throughput and utilization than other approaches. And that is what Accelerator delivers, high throughput. With further optimizations possible through Accelerator (stated but not discussed in the whitepaper), Altair claims that companies can reach utilization as high as 85%-97%.

Benefits of Flow Tracing

Many functional tasks are performed repetitively and involve multiple steps that are dependent on the outcome of the prior step. While it is always a good thing to avoid redundant and/or unnecessary computations, it is critical on long-running regression tests.

Altair® FlowTracer™ is an advanced design flow development and execution platform that offers flow visualization and troubleshooting capabilities. Using this tool, designers can visualize complex EDA workflows and employ conditional execution of some steps or run experiments in parallel.

Job Scheduling on Emulation Hardware

The benefits are well-understood for leveraging platforms such as the Cadence® Palladium® Z1 and Z2 emulation, Mentor Graphics® Veloce®, and Synopsys® ZeBu®. Traditionally, these hardware resources have been manually managed as per the workloads. But the sharing of hardware emulators among design teams brings forth its own set of challenges. Ideally, their allocation should be automated just as the EDA software tools are.

Altair® Hero™ comes to the rescue. Hero stands for Hardware Emulation Resource Optimizer and is an end-to-end enterprise job scheduler designed for hardware emulation environments. It is a vendor-agnostic solution capable of managing job scheduling requirements for the above mentioned product families of emulation hardware. Through this tool, companies can maximize the use of expensive emulators, dramatically reduce regression testing times and improve time-to-market.

Cloud or Not, Altair is There

While many companies still operate on-prem server farms, they increasingly augment their design capacity with cloud computing resources. Whether a company operates fully on-prem, occasionally cloud-bursting, fully on cloud or a regular hybrid, Altair Accelerator can help. Accelerator’s Rapid Scaling feature can shut down instances after a pre-configured period of idle time. It can judiciously use both On-Demand and Spot cloud pricing to reduce costs. You can refer to an earlier SemiWiki post to learn how Amazon (Annapurna Labs) benefited from Accelerator’s Rapid Scaling feature.

Another valuable offering from is their Altair® NavOps® tool. This tool allows easy deployment and management of hybrid cloud environments across multiple clouds. NavOps has a track record of dynamically provisioning cloud environments at extreme scales. One such example is an environment that comprised of more than one million vCPUs for accelerating engineering simulations.

Summary

By implementing the six steps discussed above, companies can achieve a higher level of EDA productivity. Altair offers tools and solutions for each of the six steps. For more details, you can download the whitepaper here.

Also Read

Latest Updates to Altair Accelerator, the Industry’s Fastest Enterprise Job Scheduler

Chip Design in the Cloud – Annapurna Labs and Altair

Webinar: Annapurna Labs and Altair Team up for Rapid Chip Design in the Cloud

Posted on

Automated Documentation of Space-Borne FPGA Designs

Automated Documentation of Space-Borne FPGA Designs
by Daniel Nenni on 02-21-2022 at 10:00 am
Categories: AMIQ EDA, EDA
1 Comment

Kepler Schem

Over the past three years, I’ve spoken frequently with Cristian Amitroaie, CEO and co-founder of AMIQ EDA, to understand how the company is helping engineers cope with the challenges of chip design and verification. With their broad customer base and many years of experience in the EDA business, the folks at AMIQ really seem to understand what their users need and how they can help.

As I was thinking that it was about time to touch base with them again, it occurred to me that I had never had the chance to interview one of their users. As soon as I asked, Cristian introduced me to three engineers from Kepler Communications Inc. Alexander Smith is an FPGA designer, Eric Murphy Zaremba is a member of the software team, and Francisco Morales is a project manager. They kindly agreed to spend some time with me to talk about the challenges they face in their chip projects and how AMIQ EDA has been able to help. Here’s a summary of our discussion.

Q: Let’s start with the company. I see from your website URL Kepler.space that you appear to be developing space-based applications. Is this accurate?

A: Very much so. Our mission is to build the Internet in space. We design and build satellites that are launched into low-earth orbit.

Q: It seems that a bunch of companies are providing satellite-based Internet connectivity; what makes Kepler unique?

A: Good question. We are very different. All those other companies are trying to use satellites to provide Internet access to Earth-based users. Our goal is to provide Internet access to space-borne asserts, including satellites, space stations, launch vehicles, and habitats.

Q: But those applications already talk to Earth and can access the Internet that way. Where does Kepler come in?

A: Satellite communication requires line of sight, so there are many times when space-borne assets are out of contact with the ground. A typical customer of ours has only a few ground stations, so connectivity is highly intermittent. It is expensive and logistically difficult to license ground stations all around the world. With our full constellation of satellites, we will always be in contact with the ground and able to connect any space-borne asset with the Internet 24×7. Our Internet in space provides universal access with speed and reliability comparable to what’s available on Earth.

Q: Doesn’t that require a lot of satellites?

A: Yes, it does. When fully built out, we will have 100-200 satellites in our constellation. We have 19 in operation already, so at this point we can provide space-based store-and-forward data services. With every additional group of satellites deployed, we move closer to universal real-time Internet connectivity in space.

Q: That is fascinating. Do you develop the satellites yourselves?

A: Yes, we design and assemble the payloads in house. We use FPGAs to implement what is essentially a software-defined radio to provide the connectivity both to other space assets and to ground stations on Earth.

Q: Can you give me a sense of the complexity of your designs and your design flow?

A: We use a Xilinx FPGA that has around 270K look-up tables (LUTs), so it’s significant in size. We have more than 450 Kepler-written RTL modules and almost 300 additional modules from other library and IP sources. The design includes an Arm processor, so software plays a key role in system operation. Our design flow is fairly standard: we write SystemVerilog RTL code and feed it into Xilinx logic synthesis and place-and-route tools. The design itself is quite complex and challenging, but we haven’t had any major issues in design implementation.

Q: What issues did you have in your development process?

A: Well, documentation turned out to be a big challenge. Given that we’re developing a whole new type of application, our design is quite novel, and it evolved a lot over the course of the project as we learned new things and added more functionality. Every time this happened, it was vital that the design documentation be updated correctly to match the design changes. Of course, when a module changes, designers of the adjoining modules need to know. Many hardware changes also require updates to the embedded software running on the Arm processor, and the documentation is the official way to communicate between the two teams.

Q: How did you address this issue?

A: Several members of the team had experience with Python’s built-in documentation capabilities and with Doxygen, which automatically generates documentation from annotated C/C++ code. We thought that there might be a similar open-source solution for SystemVerilog, but we uncovered none that supported all the constructs we used. When we investigated commercial solutions, we quickly found that only Specador Documentation Generator from AMIQ EDA had the features we needed.

Q: How do you use Specador to generate your documentation?

A: Because it’s built on the same technology that AMIQ uses for all its tools, it fully comprehends the SystemVerilog design. It automatically documents the design hierarchy by reading the modules and ports from the RTL code. It generates usage lists for submodules, including the conditions from generate statements. We were particularly impressed by this; it’s a good example of how Specador really “understands” the code.

The generation includes the contents of comment blocks, so we can add text to be incorporated in the documentation. We can create tables more easily than with other methods we’ve used in the past. Specador also generates nice diagrams for finite state machines (FSMs) and timing diagrams as specified with the popular Wavedrom format.

Q: That sounds like a lot of functionality. Is there more?

A: We should also mention the generation of register maps, since the application programming interface (API) for the registers is the main point of interaction between the software and the hardware. We write up register maps in code comments, which Specador includes in the documentation. The automatic regeneration of documents whenever registers change ensures that the software and hardware stay in sync. In fact, the programmers include permalinks to the relevant documentation pages right in their embedded source code.

Q: Who uses the generated documentation? Internal teams only, or customers as well?

A: As mentioned earlier, the documentation is critical for hardware and software engineers to stay in sync. We use our boards only for our own systems, so there’s no need for end customer documentation. However, we have used subcontractors to help with our projects, and we used to have to update their documentation by hand. We can now keep them in sync as well.

Q: How is Specador run in your development flow?

A: We use a continuous integration (CI) methodology, in which builds and tests are automatically triggered whenever RTL or software is checked in. Specador is run at least once a day on the whole design automatically as part of the nightly build process, and sometimes more frequently by individual users.

Q: Is there anything you don’t like about Specador?

A: The generated documentation is sparse, but it serves our needs for internal communication. Specador can be a bit “overzealous” in doing certain types of formatting. We just go back and tweak our code, but perhaps a bit more control would be nice. We’ve also requested a more intuitive way to specify register maps since the hardware/software API is so important to us. AMIQ has been responsive to our suggestions, and we haven’t found any serious problems with the tool.

Q: Can you quantify the benefits of using Specador for your FPGA designs?

A: Clearly, we save minutes or hours manually editing the documentation whenever something changes in the design, and that adds up over time. Since the documentation remains in sync, it serves as the communication mechanism it should be. This saves multiple email messages and voice calls among team members each day as the design evolves. This has been even more valuable during the pandemic, with many engineers working from home on varying schedules. We can’t just stick our heads into nearby cubicles to ask quick questions.

Perhaps the biggest saving comes from not having to debug tricky problems that occur when the hardware and software get out of sync. It’s hard to quantify, but surely that saves weeks of effort throughout the course of the project.

Q: Do you have any changes planned for the future?

A: We have every intention of continuing to use Specador on all our designs. It’s been a real benefit for us.

Q: Thank you for sharing all this great information!

A: It was a pleasure.

Also read:

Continuous Integration of RISC-V Testbenches

Continuous Integration of UVM Testbenches

What’s New with UVM and UVM Checking?

Posted on

Intel 2022 Investor Meeting

Intel 2022 Investor Meeting
by Scotten Jones on 02-21-2022 at 6:00 am
Categories: Events, Foundries, Intel Foundry, Semiconductor Services, TechInsights
13 Comments

Figure 1 Process Innovations

Last Thursday Intel held their investors meeting, in this write up I wanted to focus on my areas of coverage/expertise, process technology and manufacturing.

Technology Development presented by Ann Kelleher

Last year Intel presented their Intel Accelerated plan and, in this meeting, we got a review of where Intel stands on that roadmap.

Intel is targeting performance per watt parity with the foundries in 2024 and leadership in 2025. This is something I am following very closely, I was due to present “Logic Leadership 2025” at the ISS conference in January but the conference is now delayed to the beginning of April. I am doing a deep dive comparison of Intel, Samsung and TSMC process technology through 2025 in that presentation, not wanting to preempt myself I am not going to cover that material here other than to say if Intel hits these goals, they will be competitive.

Figure 1 presents a slide from the presentation talking about Intel’s history of innovation. Intel claims that every major transistor innovation for 20 years has been delivered by Intel. I would agree that has been true until recently but at 5nm TSMC introduced SiGe FinFET fin and at 3nm Samsung is currently ramping the first Horizontal Nanosheet (HNS) devices. When Intel introduces their RibbonFET HNS they will be at one to two years behind Samsung. Intel does appear to be leading the backside power delivery race.

Figure 1. Process Technology Innovations.

It was interesting to hear that they are putting a focus on predictable execution and modular development. They are working more with equipment suppliers and adopting industry best known methods. In my opinion these are all good moves on Intel’s part. For too long Intel has missed out on developments done outside of the company that were readily available to others from the equipment suppliers.

Figure 2 presents Intel’s EUV roadmap.

Figure 2. EUV Roadmap.

Two comments on this figure, originally the 18A process node was due in 2025 and I expected it would be the first High-NA EUV node, but it is now planned for the second half of 2024 and will be manufactured with 0.33NA EUV.

My second comment is that Intel is making a lot of the fact that they are due to get the first High-NA EUV tool and they are presenting this as a competitive advantage. What I have heard is that Intel gets the first High-NA tool but TSMC gets the second roughly a month later, that doesn’t strike me as a significant advantage.

Figure 3 presents the future process progression from 4 to 3 to 20A to 18A. I thought it was funny to see the graphic is of FinFETs for 20A and 18A when they are HNS processes. Its not really important as it is just for illustration purposes but I noticed it.

Figure 3. Future Nodes.

Intel is targeting five “nodes” in 4 years, a pace that is faster than we have seen from anyone in the industry in the past and a huge acceleration for a company that took 3 years for the 14nm node and 5 years for the 10nm node.

  • 7nm – Intel’s original 10nm process ramped in 2019, they then developed the 10+ or super fin node and now have the enhanced Super Fin node they have renamed 7nm. I agree this is an appropriate renaming as the density and performance are similar to the foundry 7nm nodes. 7nm delivers a 10% performance per watt boost over the 10 Super Fin through more strain and lower resistance for faster channels and better routing. 7 entered production in early 2022.
  • 4nm – originally referred to as 7nm, I pointed out some time ago that based on the 2x density improvement Intel was expecting it would be like a foundry 4nm process and they have now renamed it 4nm. It is interesting to me that they are no longer talking about a specific number for the density change making me wonder if it will be less dense than originally expected. The current quote is “significant density jump”. The process will deliver a 20% performance per watt improvement versus 7nm and be Intel’s first use of EUV and is due in the second half of 2022.
  • 3nm – I view this as kind of a half-node such as the foundries often do, it will have denser libraries, an optimized metal stack with less via resistance, more EUV use and provide an 18% performance per watt improvement. It is due in the second half of 2023.
  • 20A (A for angstrom, this is equivalent to 2nm) will be a HNS (Intel calls this RibbonFET) and Backside Power Delivery (Intel calls this PowerVia). This process is expected to provide a 15% performance per watt improvement and is due in the first half of 2024. I am surprised that the performance doesn’t take a bigger jump with the new transistor type and BPD, Samsung is claiming a 35% jump for their FinFET to HNS transition (although Samsung’s 5nm process wasn’t a very strong offering so 3nm being a lot better is less impressive than it might otherwise be).
  • 18A – I view this as another half-node, it will offer a 10% performance per watt improvement, smaller linewidths and is due in the second half of 2024. This was originally expected in early 2025 and Dr. Kelleher said they have already delivered an 18A test chip to a customer, they expect 2 tape outs in 2022 and 4 test chips in the first half of 2023. It surprises me that they have silicon they are showing customers this early.

This is an incredibly aggressive roadmap and from everything presented it sounds like Intel is on or ahead of schedule, that is a great achievement.

I am not going to discuss Intel’s packaging technology here but they do have an impressive portfolio in that area.

Manufacturing was presented by Keyvan Esfarjani

Intel is investing to accelerate new nodes and grow scale. They are leveraging their advanced packaging and “world class supply chain”.

Figure 4 illustrates Intel’s planned five nodes in four years on the left side, scale in the middle, and global footprint on the right.

Figure 4. Intel Manufacturing Strategy.

In the talk it was mentioned that Intel would roughly double their “manufacturing footprint” by 2026. I am not sure what that means exactly, the middle of figure doesn’t show a doubling of wafers starts so they presumably mean the number of transistors produced that is a product of additional wafer starts and node shrinks.

On the right side of the figure both fabs and packaging facilities are shown, a few comments on the fabs:

  • Oregon is home to Intel’s R&D facilities and also some production. Fabs RP1, DC1 + Fab 15 expansion, D1D, D1X, D1X phase 2 and phase 3 are all there. D1C/15 and D1D are former development fabs used for production now. The various phases of D1X lead the latest generation logic process development and RP1 is research path finding.
  • Ireland is home to Fab 24, Fab 24 phase 2 and the new Fab 34. Ireland is a production site.
  • New Mexico is transitioning to packaging and is also where 3D XPoint memory is developed. Fabs 11x, 11x phase 2 and 11x 3D are there.
  • Arizona is home to Fabs 12C, 32 and 42 and the under construction Fabs 52 and 62. Arizona is a production site.
  • Israel is home to Fabs 28, 28 phase 2 and the under construction Fab 38.
  • Ohio will be home to two planned new fabs initially with additional fabs in the futures.
  • New EU site is under discussion for a multi fab complex.
  • Dalian China – not shown, sold to SK Hynix.

Figure 5 illustrates Intel’s “Smart Capital” plan.

Figure 5. Smart Capital.

The left side of the figure shows the time versus investment of the various parts of building a fab. The plan is to build big shells in advance since they are a smaller segment of the cost and take the longest to build, and then fill them with equipment as needed. This has been standard practice at TSMC for a long time and is a good practice to adopt. I should also mention that my data is that it takes Intel significantly more capital to build a fab shell per square meter than anyone else and hopefully they are addressing that as well.

They are also planning to use both internal and external capacity and are seeking government support and customer prepays to help offset capital costs.

Figure 6 illustrates the idea that getting into the foundry business will allow Intel to use their assets longer. From the start I have questioned why Intel wants to get into the foundry business. Intel’s gross margins are over 50%, in the foundry business TSMC as the market leader gets 50% gross margins but everyone else is closer to 25%. As a foundry start up I would expect Intel to have margins around 25% for a very long time. The only thing that made sense to me was getting longer life out of their assets and here they discuss that.

Intel and TSMC both started bringing 300mm fabs on-line for the 130nm node around 2001/2002, Intel’s 130nm, 90nm, 65nm and 45nm capability are long gone, converted to 32nm and smaller nodes. TSMC on the other hand is still running 130nm, 90nm, 65nm and 40nm fabs.

Figure 6. New Operational Model.

Conclusion

A lot of what Intel is doing is adopting best practices from others. The big take away to me is that they appear to have gotten back on track on development and are executing on a roadmap that has the potential to get them back at or near process leadership.

Also read:

Tower Semi Buyout Tips Intel’s Hand

Intel buys Tower – Best way to become foundry is to buy one

The Intel Foundry Ecosystem Explained

 

Posted on

Semiconductor Earnings Roundup

Semiconductor Earnings Roundup
by Doug O'Laughlin on 02-20-2022 at 10:00 am
Categories: Events, Semiconductor Services
2 Comments

img 620a8b3699985

ON, ACLS, RMBS, AOSL, CAMT, ICHR, ONTO, SUMCO, and more!

SUMCO was the best call I read this quarter. There were many great bits of information but I want to start with the stat that really shocked me.

First of all, with regard to the LTAs out to 2026 and whether we did make progress in the last 3 months, that is correct. In the last 3 months, we were ultimately able to fully lock in LTAs for all of the capacity.

Additionally, both SUMCO and Global Wafers were extremely adamant that supply couldn’t be brought on immediately as they are missing key tools to add capacity and they believe that output won’t start ramping until 2023. They will continue to ramp their new factory until 2025, but that won’t be enough to satisfy wafer demand.

Until then the thing that will continue for wafer companies is price raises. These price rises are yet another part of why semiconductor costs are rising everywhere. SUMCO’s price raises are 10% annually until 2024, mostly to offset the increasing rise of deprecation for their capacity ramp.

The thing that was so confusing is if they are raising prices 10% a year, adding capacity, and most of their operating profit growth was primarily from price raises, why aren’t they pushing more capacity ASAP? Part of it seems to be an oligopoly decision from Shin-Etsu, Global Wafers, and SUMCO, but another part is it truly seems like they cannot. They are having the same lead time problem as the rest of the fabs.

Sadly, there are many individual processes to fabricating a wafer at SUMCO. So regardless of the price of the equipment, the absence of even a single piece of equipment will prevent us from completing the wafer fabrication process.

The next part that gave me pause was they believe that their demand model is booked out to 2026, inclusive of industry capacity additions. Given there really are only 3 wafer suppliers, I candidly have to ask what the hell is going on? Will we be talking about wafer shortages 2 years from now?

Part of the problem is that ramping greenfield investment is something that SUMCO said was extremely challenging for them in 2017, and this will be challenging to ramp greenfield again.

Unfortunately, the lack of experience meant that we really struggled in 2017 and 2018. We have since focused on learning from our mistakes, and mistakes often create the biggest opportunity for learnings. As a result, this time around, our workforce is much more experienced and prepared.

And as an organization, because of our previous struggles, we now have a deeper bench of experienced workers. This is why we believe we can undertake this kind of large-scale expansion. That is my view.

I would also say that equipment operators require significant accumulated experience. These are not the kind of jobs, where you can pick up the skills very easily over a short period of time.

Another part of the wafer shortage story that made me ask “WTF” out loud once again was the 200mm wafers. SUMCO said that they would never add 200mm wafers and that there is no way to increase 200mm wafers. All of their supply improvements have been brownfield expansion and according to SUMCO, the 2021 capacity additions are the end of their brownfield ability to expand. The equipment no longer exists.

It is possible that 200-millimeter prices could continue to rise over time. Equally, you could see a pause in the rise in prices. There is no way to increase 200-millimeter volume. The equipment is no longer available and older facilities that have been idled, are obsolete. So increasing volume is not possible.


As good as it’s going to get

The trailing edge looks like it will be the worst impacted by price raises, especially 150mm and 200mm wafers. Price raises will likely continue as long as there are mission-critical and qualified products that are unlikely to swap over. Think of automotive analog and other products. Meanwhile, 200mm wafers will never see additions of capacity. This is a bit reminiscent of the Fortran programming shortage.

Anyways I want to talk about the other slides they had in their deck, particularly their demand graphs and their customer inventory graphs.

First, let’s talk about their demand builds. They expect Smartphone units to increase at a 4.9% CAGR from 1.3 billion units to 1.65 billion units, but starting points matter. From 2019 at 1.48 billion units this is only a 1.9% unit CAGR. So the real differential is content increases, they expect approximately 4.5% annual content increases in smartphones. That sounds correct to me.

Next, they talk about HPC demand, and I really liked this unit analysis because I have never seen anyone take a crack at it before.

They believe that HPC will be approximately a ~14.7% CAGR in unit growth, and given its the largest incremental growth market I believe that this is correct. I believe that value will likely outgrow this, but something like a mid-double-digit value CAGR plus ~15% unit CAGR will net us to a 20%+ growth market.

On to DRAM and NAND. They expect DRAM bit growth rate to be approximately 20% and scaling to be 10%, so wafer volume growth will be the differential at 10%.

NAND’s bit growth has essentially kept in line with the demand rate, with a slight differential that shows up in wafer demand (1%). But going forward bit growth will start to decelerate and one of the ways to solve this is to bond wafers together, and this will be a new incremental wafer demand.

Last but not least I want to talk about their inventory graphs. I really don’t know how to read the graphs, and I interrupted this as colored as their estimates and the trailing as historical quarterly inventory builds. Are the forward estimates monthly or quarterly? The number scheming implies monthly.

They believe that wafer inventories are falling massively right now, as depletion is starting to take customers below 1 month of inventory.

This chart shows estimated customer inventory for 300-millimeter wafers. You can clearly see the sharp decline in customer inventories. This is for 300-millimeter wafers as a whole. We believe that customer inventory has dropped to 1 month. If inventories drop below the 1-month level, it creates a precarious situation for the customers.

If we then look at the next slide, Slide 11, which breaks out customer 300-millimeter wafer inventory between logic and memory, you can see that logic is already at 0.7 months, while memory is around 1.2 months. So as you can see, the shortages are particularly acute for logic.

I am unsure what to make of this, but they essentially believe that memory customer inventory spiked during the 2019 cycle, remained high until 2021, but now are going to systematically decrease. I thought the inventory charts in general brought more questions up than answered. Inventories are clearly down at Logic (makes sense) but up in memory and rising (that is bearish!) but should come down soon (good!).

Maybe the context of their entire capacity being booked until 2026 paired with falling inventories is the point they were trying to make. There is information for both the bears and bulls in this chart.

The rest of the earning update is behind a paywall, I just thought everyone should read the SUMCO update.

Subscribe

Also read:

The Rising Tide of Semiconductor Cost

How France’s Largest Semiconductor Company Got Stolen in Plain Sight

TSMC Earnings – The Handoff from Mobile to HPC