Bronco Webinar 800x100 1

How Taiwan Saved the Semiconductor Industry

How Taiwan Saved the Semiconductor Industry
by Daniel Nenni on 08-07-2023 at 6:00 am

Taiwan USA

Now that semiconductors are front page news and a political football, I would like to write more about how we got to where we are today to better understand where semiconductors will go tomorrow. I will start this article with a provocative quote that really made me laugh and will put some context to what I am trying to accomplish here:

Trump accuses Taiwan of taking away America’s semiconductor business “Taiwan, they took our business away. We should have stopped them. We should have taxed them. We should have tariffed them,” said Donald Trump, Fox News, July 2023.

I know, American politics is an acquired taste but it is funny just the same. We already covered the fabless transformation in our book “Fabless: The Transformation of the Semiconductor Industry” so let’s start with a quick look at the history of the semiconductor industry in Taiwan (GPT 4.0):

The semiconductor industry in Taiwan has a rich history that spans several decades, starting from the 1970s to the present day. The industry has played a crucial role in Taiwan’s economic transformation from an agrarian economy to one of the world’s top high-tech industrialized nations.

Here are some of the key milestones:

“Formation of Electronics Research and Service Organization (ERSO): In 1973, the Taiwanese government established ERSO under the Industrial Technology Research Institute (ITRI). Its aim was to develop the electronics industry in Taiwan and provide a platform for semiconductor research and development.

Birth of Taiwan Semiconductor Manufacturing Company (TSMC): In 1987, TSMC, the world’s first dedicated semiconductor foundry, was founded by Dr. Morris Chang. The establishment of TSMC initiated the foundry model in the global semiconductor industry, which separated the manufacturing and design aspects of chip production. This allowed fabless companies to focus on designing innovative chip solutions without the need for significant capital investments in manufacturing facilities.

Hsinchu Science and Industrial Park: The Taiwanese government established this park in 1980 to serve as a hub for high-tech companies. It now houses numerous semiconductor companies and has played a significant role in the growth of Taiwan’s semiconductor industry.

Expansion of other major semiconductor companies: Over the years, several other Taiwanese companies have become key players in the global semiconductor industry. These include United Microelectronics Corporation (UMC), the world’s second-largest pure-play semiconductor foundry, MediaTek, a leading fabless semiconductor company, and ASE Technology Holding Co., the world’s largest provider of independent semiconductor manufacturing services in assembly and test.

Leadership in Advanced Process Technology: In recent years, TSMC, in particular, has emerged as a global leader in advanced process technologies, successfully achieving mass production at ever smaller node sizes (7nm, 5nm, 3nm and planning for 2nm and beyond). This has placed Taiwan at the forefront of the global semiconductor industry.

While this summary provides a brief overview, the history of Taiwan’s semiconductor industry is rich and complex, driven by strategic government initiatives, visionary leadership, strong educational programs, and the rise of the global digital economy. As of 2023, Taiwan is one of the world’s largest and most important centers for semiconductor manufacturing.”

Great summary, here is a little color on what happened. When I joined the semiconductor industry in the 1980s it was a challenging decade. Mini computer companies such as IBM, Hewlet-Packard, Digital Equipment, Data General, Prime Computer, and Wang all had their own fabs all over the United States. Unfortunately, due to over regulation (especially here in California) and the inability to hire skilled workers (sound familiar?), manufacturing of all types left the US for more friendly countries.

Additionally, in the 1980s, there were quite a few economic ups and downs including the crash of 1985. Keeping these very expensive fabs running was difficult which spawned the IDM foundry business where US and Japanese semiconductor companies accepted designs from outside customers for contract manufacturing to fill their fabs.

One of the first big fabless companies to do this was FPGA vendor Xilinx (founded in 1984, now owned by AMD). Sieko Epson (Japan) was Xilinx’s first IDM foundry partner. Xilinx quickly outgrew the relationship and moved to UMC and then TSMC which is where they are today.

Clearly IDM foundries were a stop-gap solution back then since they routinely competed with customers and the foundry business had lower margins than the products they manufactured internally so those products always had priority in the fabs.

Also in the 1980s, the ASIC business model was developed by VLSI Technology (founded in 1979) and LSI Logic (founded in 1980). VLSI and LSI accepted designs from fabless companies and manufactured them using internal fabs. But again the cost of the fabs was prohibitive. The ASIC business model is again thriving but it is now populated by fabless ASIC companies who do the design and manage manufacturing through the foundries.

Bottom line: The early IDM foundries and ASIC companies created the perfect storm for the pure-play foundry business model that fully evolved in the 1990s and that is where Dr. Morris Chang comes in.

To be continued… Morris Chang’s journey to Taiwan.

Also Read:

Morris Chang’s Journey to Taiwan and TSMC

Intel Enables the Multi-Die Revolution with Packaging Innovation

TSMC Redefines Foundry to Enable Next-Generation Products


Podcast EP175: The Complexities of Compliance for a Worldwide Supply Chain with Chris Shrope

Podcast EP175: The Complexities of Compliance for a Worldwide Supply Chain with Chris Shrope
by Daniel Nenni on 08-04-2023 at 10:00 am

Dan is joined by Chris Shrope. Chris leads high tech product marketing at Model N, a compliance leader for high-tech manufacturers. Chris has deep experience defining product market fit and related new product development activities. He received his MBA and holds certifications in Economics, Law, Product Management and Marketing. For any ocean lovers out there, like Dan, Chris is also an advisory board member of the Inland Ocean Coalition.

Dan explores the evolving government rules associated with semiconductor sales with Chris. The impact geopolitical tensions creates is outlined by Chris, along with a discussion of how semiconductor suppliers can ensure compliance. A multi-tier supply chain consisting of distributors and resellers can make it challenging to know exactly where parts are used.

Chris offers several strategies to manage this problem that are based on collaboration and forward visibility, among other approaches.

The views, thoughts, and opinions expressed in these podcasts belong solely to the speaker, and not to the speaker’s employer, organization, committee or any other group or individual.


CEO Interview: Harry Peterson of Siloxit

CEO Interview: Harry Peterson of Siloxit
by Daniel Nenni on 08-04-2023 at 6:00 am

hwp photo

Harry Peterson is a mixed-signal chip designer with a BS in Physics from Caltech.  He managed IC design groups within Fairchild, Kodak, Philips, Northern Telecom, Toshiba and Pixelworks.  During sabbaticals he helped fly experiments on NASA’s orbiting satellite observatory (OSO-8) and build telescopes in the Canary Islands.  He is CEO and a co-founder of Siloxit, a startup that has developed an Industrial IoT (IioT) module that securely monitors and controls operation of the electric grid.  He has produced many publications, patents, presentations, and short courses.  For fun he swims, hikes and thinks about astronomy.

Tell me about your journey to Siloxit.

I co-founded Siloxit which is a startup and a Portfolio Company in the Silicon Catalyst Incubator. Siloxit is in the business of Distributed Online Condition Monitoring (DOCOM) of infrastructure.  The specific infrastructure market we focus on is the energy grid.

Long ago when I was an undergraduate at Caltech, I was lucky enough to get a job building telescopes.  That continued through my grad school days.  Eventually I transitioned into integrated circuit design at the venerable Fairchild Semiconductor, which was a great place to learn device physics and a nice starting point for a lifetime of adventures in mixed signal circuit design.  In 1988 some of my Fairchild colleagues invited me to join them as employee number seven at ACM research, which was the IoT startup founded by Mike Markkula before IoT was a thing.  About three years ago, my friends Nick Tredennick and Eudes Prado Lopes and I decided that IoT for infrastructure was a very compelling concept that nobody had really implemented well, and we seized the opportunity to fix that by founding Siloxit.

Can you talk a little bit more about Fairchild? Because that’s a significant job to have early in your career.

When an opportunity came up to join the team at Fairchild Semiconductor, working at the R&D fab in Palo Alto, I jumped on it. The first assignment that they gave me was working out the device physics of RAM chips to be built in an exotic fabrication process.  IBM loved it, and bought a bunch of the chips.  But the chip consumed too much power to be competitive.

At Siloxit, you are working on technology improvements that can slash the cost of building and operating the grid.  Tell me, what problems are you solving?

The use cases for these kinds of devices come from the challenges with expanding the electric-grid infrastructure.  The grid is not doing so well these days.  The grid needs to run more efficiently and more cost effectively, the distribution network needs to be expanded, reliability and security need to be better.  Also, here in California, we need to get rid of the failure modes that start wildfires and burn down forests. And big technical challenges remain as we develop solutions that have the agility and stability to deal with low-cost sources using dynamic energy resources (DER) such as wind and solar.

The good news is that most of the grid’s problems can be fixed by just using IIoT to properly control and manage the system.  The even better news is that there are some pretty sharp declines in costs on the power-generation side, so the spiraling costs could actually be pushed back down. Going after some of the easy-to-solve problems on the transmission side will likely have a big financial impact.  Technology is going through very fundamental shifts; this is something that has been a hundred years in the making, but now renewable energy and other factors are redefining the grid.

Infrastructure fails way too often. So what do you mean by helping the grid to do its job?

Let’s focus on a key example – power transformers.  At first glance, these are just boring hundred-ton hunks of iron that generally don’t even contain any Silicon.  That’s deceptive.  The physics of effectively monitoring and managing their condition with cost-effective IIoT devices turns out to be a sweet problem that can be solved with IIoT.

Now, why should this matter to you? Well, the cost implications are significant.   Each major transformer failure leads to extensive disruptions and subsequent downstream consequences. The good news is that when we deploy IIoT that does the obvious diagnostic homework, we can easily identify which ones are likely to fail next.

By doing so, we can transform an expensive catastrophe into a more affordable scheduled maintenance event. This is the ultimate goal. How do we achieve this? By detecting the failure of an insulator. Insulators have a service life of up to half a century or more, enduring high levels of stress, particularly in harsh climates like my home state of Arizona. As an insulator approaches failure, it sends warning signs, indicating its impending demise. By leveraging our understanding of plasma physics, we can recognize these signals.

These signals manifest as electrical impulses that can be captured from the associated power lines. It’s not a complex task – the main thing we need is a reliable analog-to-digital converter capable of sampling at around 100 megasamples per second with a precision of approximately 14 bits.  Also required is an IIoT system that will be described below.

In a production run of a few hundred thousand units, the cost per unit can be reduced to about a thousand dollars. Considering the financial consequences of transformer failures, which are estimated at approximately $15 million per incident according to ABB, one of the leading transformer manufacturers, the cumulative impact of one in every 200 transformers failing annually is substantial.

To address this, we propose investing a small fraction of the cost of a single transformer failure on an insurance policy, or rather an Industrial Internet of Things solution. This IIoT solution is capable of detecting the precursors to such failures and relaying this information to a central control center. With this system in place, we can organize a prompt and efficient response.

In conclusion, by leveraging advanced sensor technology and IIoT solutions, we have the potential to significantly mitigate the financial and operational risks associated with power transformer failures. Through proactive monitoring and early detection of failure precursors, we can transform these potential disasters into manageable maintenance events.

This is kind of old school technology, power grids, meet new school, IoT sensors. What tech trends are you leveraging?

Chiplets, energy harvesting, and the cognitive edge are some of the trends that we leverage. Chiplets facilitate cost-effective heterogenous integration of the odd mix of technologies required for the needed IIoT. Energy harvesting is often the only practical solution that meets the cost and longevity constraints of our applications.  Service lifetime of much of the infrastructure that needs to be monitored and managed by our IIoT devices is very long.  Commonly it needs to exceed half a century.  The notion of meeting such requirements with batteries that ‘only’ last a decade is a complete non-starter.  Magnetic-field energy harvesting (MFEH) turns out to be a good solution for many of the use-cases we address.

So what is the cognitive edge and why is this essential to you?

It is essential to process data at the edge. This limitation becomes evident when considering the costs associated with transferring a terabyte of data to a distant data center, which includes significant transportation expenses. Ideally, all calculations should be performed at the sensing point itself, following a hierarchical approach.

You can also think of this as a bio-inspired architecture.  The partition for distributing the processing workload in hardware is quite similar to the body’s partition of processing, which puts, for example, a lot of the processing of vision into biological interconnect between the photoreceptors in your retina and the neurons in your brain. Some processing is done at the sensing point, while additional processing can take place at the gateway and other levels.  Successive layers of processing lead to successive layers of data compression.

Cognitive-edge architecture brings additional benefits.  It allows for better control over communication costs and enhances security. Currently, the security of the grid is a major concern due to frequent hacking attempts. However, existing efforts in this regard have proven inadequate. Therefore, our perspective is that specific applications, such as ensuring the integrity of transformers, would benefit from reevaluating the entire process from scratch. This doesn’t imply discarding the existing infrastructure and legacy grid; rather, it means incorporating new components that are not reliant on the ineffective elements of the old system. For instance, leveraging advanced communication chips or low earth orbit satellites, which are already starting to become available, can greatly enhance the system’s capabilities.

Artificial Intelligence is essential for many of the applications we address.  Most engineers and system architects are starting to realize the huge benefits that accrue when you distribute processing rather than just sending all the data from sensors to some central signal-processing block.

What big infrastructure development projects are affected by these developments?

Let’s begin by emphasizing the significance of these projects, even if they are not big in the sense that they always grab major headlines. An example worth highlighting is the recent press release from Iberdrola, a prominent Spanish company in the grid sector. They announced their commitment to invest half a billion dollars in expanding transmission line capacity in Brazil. While individual projects may not seem monumental, the cumulative effect of such opportunities can be substantial.

These developments involve the installation of thousands of kilometers of wire, alongside various accompanying components. The challenge lies in managing an increasingly complex grid with each new generation. Furthermore, the rise of affordable, renewable energy sources adds another layer of complexity to the business landscape. To achieve cost-efficiency, it is crucial to have an agile grid that can adapt to the fluctuations in power supply from sources like wind, solar, and emerging forms of nuclear energy.

Brazil, in particular, is experiencing substantial growth, constructing thousands of kilometers of new transmission lines. These installations must withstand challenging environmental conditions, ensuring both reliability and cost-effectiveness. Additionally, they need to be safeguarded against potential threats, including acts of vandalism or unintended failures caused by external factors. The key to achieving this lies in implementing more advanced condition monitoring systems. Siloxit aims to specialize in providing highly effective condition monitoring solutions while seamlessly integrating them into the communication networks and management structures of the grid.

Why did you choose to work with Silicon Catalyst?

When we decided to build IIoT that would help the grid do its job, we knew we would have to dance with elephants.  In the early days we were just half a dozen folks in a little startup explaining to billion-dollar customers that they should embrace our out-of-the-box thinking about better solutions for the problems they have been working on for a century.  When you first think about how a dozen folks in a little startup can actually interact with the people and institutions that are driving these big-league developments, the answers are not immediately obvious.  Shortly after we founded Siloxit, we joined Silicon Catalyst.  It has been a wonderful experience to see how Silicon Catalyst has helped us connect the dots, allowing us to partner with TSMC and ST Microelectronics and IMEC and Leti and many others.  The list of partners we’ve had the good fortune to work with thanks to Silicon Catalyst is just overwhelming.

I saw that you have a partnership coming up with YorChip. Is there something there you would like to talk about?

Our partnership with YorChip is very exciting. I have collaborated with Kash Johal, the CEO of YorChip, on various projects for many years. It is clear that chiplets offer significant advantages for specific use cases. Siloxit faces challenges that encompass multiple disciplines, requiring us to bring together various resources like threshold sensors, security widgets, processor widgets, A-to-D conversion solutions, and communication components within a very compact module while ensuring cost-effectiveness.

The contemporary approach is to leverage chiplets, which harness the best attributes of highly efficient technologies but in a size format that avoids unnecessary overprovisioning. For instance, an A-to-D conversion task doesn’t require a square centimeter-sized chip; a millimeter-sized chip may suffice. Furthermore, advancements in packaging technology, particularly in sensor, processor chip, A-to-D converter, and antenna domains, enable seamless integration of these chiplets. It’s not merely about assembling IP components from different catalogs but designing chiplets that effectively harmonize with the entire system.

Security is one critical aspect that demands special attention, requiring careful consideration at the logic design and device design levels.

By successfully integrating these chiplets, while utilizing only a small percentage of the available space, we achieve a significant outcome that is far from trivial but well worth the effort. YorChip’s focus aligns precisely with these objectives, and we anticipate incorporating this technology into more Siloxit products moving forward.

Also Read:

CEO Interview: Rob Gwynne of QPT

CEO Interview: Ashraf Takla of Mixel

CEO Interview: Dr. Sean Wei of Easy-Logic


Alphawave Semi Visit at #60DAC

Alphawave Semi Visit at #60DAC
by Daniel Payne on 08-03-2023 at 10:00 am

Alphawavesemi, DAC 2023 3nm eye diagram

On Wednesday at #60DAC I met Sudhir Mallya, Sr. VP Corporate Marketing at Alphawave Semi to get an update about what’s been happening at their IP company and with industry trends. The tagline for their company is: Accelerating the Connected World; and they have IP for connectivity, offer chiplet solutions, and even provide custom silicon that are optimized per application. The company recently announced a 3nm tape-out on July 10th to prove out chiplets for generative AI applications that use a High Bandwidth Memory 3 (HBM3) PHY and Universal Chiplet Interconnect Express (UCIe) PHY IPs. The UCIe PHY IP supports die-to-die data rates of 24Gbps per lane. There’s been tremendous interest with custom silicon and chiplets, caused by the data explosion from using LLM and ChatGPT applications that require fast connectivity rates.

Alphawave Semi, 3nm Eye Diagram

All of that data generated getting into and out of chiplets requires high-speed, low-power, data connectivity. There have been a couple of chiplet interconnect approaches, with Buch Of Wires (BOW) and UCIe as the two most predominant, and UCIe being more standardized for chiplets. BOW was there at the start in 2020 as a die-to-die interface.

Praveen Vaidyathan, VP at Micron noted that, “The tape-out of Alphawave Semi’s HBM3 solution in TSMC’s most advanced 3nm process is an exciting new milestone. It allows cloud service providers to leverage Alphawave Semi’s HBM3 IP subsystems and custom silicon capabilities to accelerate AI workloads in next-generation data center infrastructure.”

At DAC they were demonstrating four things:

  • Chiplets
  • HBM3
  • 3nm 112GB s XLR, PAM4 SERDES
  • PCIe Gen 6 with PAM 4

On the demo of 112GB Ethernet they were showing their test chip using a loop back test, and the longer length interconnect creates more delays as they wanted to max out the simulated length. A Bit Error Rate (BER) of 2e-8 was measured, while the actual spec is 1e-4, so their results are 4 orders magnitude ahead of the spec. That BER number can even be brought down to 1e-10. The PAM4 eye diagram was prominently displayed in the demo. The test chip is multi-standard, so Ethernet or PCIe are both supported for all generations. Four lanes are possible, although only one was being shown in the demo.

TSMC was the foundry for the 3nm test chip and Alphawave Semi used a DSP-based SerDes, and has a rich history of SerDes IP, where there has been sufficient margins designed in. The PCIe 7.0 specification requires 128 GT/s raw bit rate, but the final spec is targeted for release in 2025.

Generative AI system designs require a complete IP subsystem with connectivity for chiplets, custom silicon and advanced packaging. This is all coming together in the industry now.

Alphawave Semi has about 700 people worldwide now, and just one year ago it was 400 people, so that’s a lot of growth, fueled by connectivity IP demand. The company has sites in Canada, USA, UK, Israel, India, China, Taiwan and South Korea.

Sudhir talked about trends that he sees this year, and chiplets continue to be a big trend, and the ecosystem to support chiplets is really coming together. The IP vendors, foundries, designers and standards groups are actively involved in making chiplets realized. The use of chiplets causes new methodologies to support concurrent design across both electrical and thermal domains.

Summary

The 3nm demo from Alphawave Semi at DAC was pretty impressive, and the 112G PAM4 eye diagram looked open and clean. Most of DAC is filled with EDA vendors, but it’s always refreshing to witness real silicon IP operating in a booth.

Related Blogs


Accellera and Clock Domain Crossing at #60DAC

Accellera and Clock Domain Crossing at #60DAC
by Daniel Payne on 08-02-2023 at 10:00 am

Accellera, clock domain crossing, #60DAC

Accellera sponsored a luncheon panel discussion at #60DAC, so I registered and attended to learn more about one of the newest working groups for Clock Domain Crossing (CDC). An overview of Accellera was provided by Lu Dai, then the panel discussion was moderated by Paul McLellan of Cadence, with the following panel members:

Accellera Panel, Clock Domain Crossing

Panel Opening Remarks

Anupam Bakshi – has been with Agnisys since 2007, and before that with Gateway Design Automation – where Verilog was invented. Agnisys has been offering CDC automation tools, and is a member of the Accellera working group on CDC standards. He recommended to avoid meta-stability by using a spec-driven and synchronization approach, along with correct by construction design automation. This approach uses declarative attributes, and then engineers simply run the tool.

Frank Schirrmeister – he’s the VP of business development at Arteris, and before that at Cadence. Arteris has a Network On Chip (NOC) focus, and they acquired companies like Semifore to gain system IP, and Magillem to add ISO 26262 and IP-XACT expertise. Frank recommends the generation of registers from a higher-level specification along with CDC logic. As IP for an SoC is provided by multiple vendors, it makes sense to have a CDC standard to ensure that all IP that is integrated will work reliably, so there’s a need for a common intent language.

Dammy Olopade – he’s the working group chair for CDC and a principal engineer at Intel. The new working group was proposed in September 2022, then approved in December, and there are now 96 participants from 22 companies so far. The draft LRM for the CDC is due around December 2023.

Ping Yeung – at Nvidia he is a Senior Manager of Formal Verification. Today bringing up IP blocks with proper CDC checks is very tedious, and too time consuming, so a CDC standard with hierarchy is welcomed.  It will allow engineers to focus on CDC at the top level only. They really want to mix internal and external IP blocks easily. Assertions will ensure that models are used correctly, to verify interface properties, constraints and assumptions.

Q&A

Q: Paul – why a CDC standard now?

A: Dammy – at one time all lines of code came from one design team, not now, it’s multiple vendors now. The new model has IP blocks from many different vendors. With so many IP vendors and IP users,  a CDC standard is required.

A: Frank – Systemic complexity has grown too large, so a CDC standard is required to keep issues in control. The implementation details now impact the architecture choices. A common language and vocabulary become more important now.

A: Anupam – customers request more CDC validation in their IP integration challenges so we have to act now.

A: Ping – also internal IP blocks must be checked to see if they are being reused properly. What can we do if the original designer is gone?

A: Frank – Since 2000 we’ve been doing abstraction at the same levels, but now we can abstract register generation automatically from a high-level. We now have virtual platforms for HW and SW design.

Q: Paul – what about asynchronous input signals to a chip?

A: Dammy – there has to be a specification for design intentions. What is the spec? How do we design to meet the spec? The first spec should come along in the September time frame. We need to make sure that our clock never glitches, to keep it a synchronous design.

A: Frank – we know how to handle that challenge. We see different clock domains, and then insert the required logic, however the validation bit is a focus of new WG. If your PLLs start to jitter, then video and audio can drift out of synch.

A: Ping – we know how to handle asynchronous signals with known solutions. EDA tools can find CDC domain crossings. When the interfaces have been verified per IP block, how do we capture that verification at the top level, instead of re-verifying all over again?

Q: Paul – how many clock domains are being used today?

A: Anupam – 3-10 is a typical range.

A: Frank – hundreds have been seen. Even the number of re-used IP blocks can be in the hundreds now. Formal verification can be used at full-chip level, but different tools return different results, so some violations are false-positive. IP integrators and IP vendors need to have the same understanding on clock domains.

Q: Paul – what’s next for IP integration after CDC?

A: Ping – Reset domain crossing needs to be standardized.

A: Anupam – what about correct by design approaches? The specification has not been rigorous enough.

A: Frank – integration issues with IP is still a tough issue. What about CDC and safety issues interacting together? Can we ever go beyond RTL abstractions?

A: Anupam – what about FSM and datapath standards? Standards are only at the interfaces for now.

A: Frank – what about MBSE using SysML? Can we get to that level?

A: Dammy – if we already have a working system, then let’s keep working EDA tools then add innovative new tools. Power and performance challenges cannot be easily solved with today’s tools.

Q: Dennis Brophy – what about manufacturing issues and using chiplets?

A: Frank – I asked at UCIe about PHYs working together. Are there any plugfest possibilities? It’s a new layer of complexity.

A: Dammy – there is no interoperable language for CDC now. So we should follow a more correct by construction approach to enable chiplets.

Summary

This panel discussion was fast-paced and the engineers in the audience were actively asking questions and approaching the panelists after the discussion to get their private questions answered. CDC standardization is moving along, and interested engineers are encouraged to join in the working group discussion sessions. If your company is not already an Accellera member, please visit https://accellera.org/about/join for more information on how to join and participate.

Related Blogs


Application-Specific Lithography: Via Separation for 5nm and Beyond

Application-Specific Lithography: Via Separation for 5nm and Beyond
by Fred Chen on 08-02-2023 at 8:00 am

1689394958554

With metal interconnect pitches shrinking in advanced technology nodes, the center-to-center (C2C) separations between vias are also expected to shrink. For a 5/4nm node minimum metal pitch of 28 nm, we should expect vias separated by 40 nm (Figure 1a). Projecting to 3nm, a metal pitch of 24 nm should lead us to expect vias separated by 34 nm (Figure 1b).

Figure 1. (a) Left: 4nm 28 nm pitch M2 and M3 via connections may be expected to have center-to-center distance of 40 nm. (b) Right: 3nm 24 nm pitch M2 and M3 via connections may be expected to have center-to-center distance of 34 nm.

Is it really straightforward to do this by EUV?

Conventional EUV Patterning

A conventional EUV patterning would use a current 0.33NA EUV system to image spots smaller than 20 nm. However, for such an optical system, the spot is already limited to the image of the point spread function (PSF), which after resist absorption (e.g., 20%), has a highly stochastic cross-section profile (Figure 2).

Figure 2. Cross-section of point spread function in 20% absorbing resist. The stochastic characteristic is very apparent. The red dotted line indicates the classical non-stochastic image.

The real limitations from the point spread function from putting two of them together [1]. At close enough distances, the merging behavior is manifest by image slope reduction (degraded contrast) between the two spots (Figure 3). This is also accompanied by a change in the distance between the expected spot centers in the image, and stochastic printing between the two spots.

Figure 3. (a) Left: Absorbed photon number per sq. nm. for two point spread functions placed 36 nm apart. Note that the actual image C2C distance is 40 nm. (b) Right: Absorbed photon number per sq. nm. for two point spread functions placed 34 nm apart. The red dotted lines indicate the classical, non-stochastic images.

This means basically although two spots will appear, the chance of defects is too high to print them when running a high-throughput exposure. It would be safer to restrict them to be forbidden layout.

Alternative Patterning

Going to 0.55NA EUV worsens the stochastic behavior because of much lower resist absorption (e.g., 10%) due to the requirement for much thinner resist from severely limited depth of focus [2]. Such systems are also not available currently either, so the only remaining alternative is to print the two spots individually in separate exposures, i.e., double patterning [3]. Moreover, given that the EUV point spread function already has a significant stochastic distortion (see Figure 2), it would be better for a wider spot to be printed for each exposure (even by DUV) and post-litho shrink applied [4].

References

[1] F. Chen, Stochastic Behavior of the Point Spread Function in EUV Lithography, https://www.youtube.com/watch?v=2tgojJ0QrM8

[2] D. Xu et al., “Feasibility of logic metal scaling with 0.55NA EUV single patterning,” Proc. SPIE 12494, 124940M (2023).

[3] F. Chen, Lithography Resolution Limits: Paired Features, https://www.linkedin.com/pulse/lithography-resolution-limits-paired-features-frederick-chen/

[4] H. Yaegashi et al., “Enabled Scaling Capability with Self-aligned Multiple patterning process,” J. Photopolym. Sci. Tech. 27, 491 (2014), https://www.jstage.jst.go.jp/article/photopolymer/27/4/27_491/_pdf

This article originally appeared in LinkedIn Pulse: Application-Specific Lithography: Via Separation for 5nm and Beyond

Also Read:

NILS Enhancement with Higher Transmission Phase-Shift Masks

Assessing EUV Wafer Output: 2019-2022

Application-Specific Lithography: 28 nm Pitch Two-Dimensional Routing


Qualitative Shift in RISC-V Targets Raises Verification Bar

Qualitative Shift in RISC-V Targets Raises Verification Bar
by Bernard Murphy on 08-02-2023 at 6:00 am

SVIPs

I had grown comfortable thinking about RISC-V as a cost-saving and more flexible alternative to Intel/AMD or Arm in embedded applications. Where clearly it is already doing very well. But following a discussion with Dave Kelf and Adnan Hamid of Breker, RISC-V goals have become much more ambitious, chasing the same big system applications where the major processor players currently claim dominance. Differentiation may now be the driving factor, in cloud and communications infrastructure for example. Happy to hear the RISC-V users and ecosystem are spreading their wings however these systems inevitably imply a new level of complexity in system and system-level core verification. This is further compounded by the naturally disaggregated nature of RISC-V core and system development.

What changed?

In principle whatever you can do with Arm you should be able to do with RISC-V, right? In the US, Tenstorrent, Esperanto and Condor Computing are active in building many-core CPUs and AI accelerators to serve HPC and more general needs. In processors, SiFive, Codasip and Andes among others are already familiar. In other regions there are active programs both at the regional level and at company level to develop independence from dominant IP/device suppliers, with echoes of recent anxieties around independence in semiconductor manufacturing.

In Europe, the European Processor Initiative wants to establish European independence in HPC and beyond, with end-to-end security. NXP and Infineon are both involved in RISC-V and Open Hardware initiatives though cagey about what they are actually doing. In China, the XiangShan open project provides a China-centric spin on the ISA together with a microarchitecture and implementation and workflow/tools. Alibaba, Tencent, Huawei and ZTE already have active programs in HPC, AI and communications. I would guess all these developers are eager to decouple from embargo risks.

What is common between all these objectives is big, many-core systems applied to big applications in HPC, communications and AI infrastructure. Very understandable goals but there is a high verification hurdle they must all clear in stepping up to that level of RISC-V integration.

What makes big systems different from embedded systems?

The short answer is a mountain of system-level verification. All those tests to verify that multiple cores communicate accurately with each other, that interconnects, cache and I/O honor coherency requirements, that interrupts are handled correctly, that writebacks and address translation services work as expected. As security is progressively standardized for RISC-V applications (critical for servers), implementation won’t be any easier to validate than for other platforms.

Then there’s the OS connection – ability to boot an un-modified target OS (Windows or Linux) without customization. OS and application suppliers have no interest in developing branches for a proliferation of independent hardware platforms. Neither should platform providers want to maintain their own branches.

Arm has estimated that they spend $150M per year on their own system level verification/ validation. I have no idea what comparable numbers would be for Intel and AMD, but I have to believe these would run to billions of dollars for each. Multiply those numbers by the years of accumulated wisdom in their regression suites and it is clear that getting close to a comparable level of signoff quality for RISC-V-based systems will be a heavy lift.

What will it take?

There is already very active collaboration in the RISC-V ecosystem, both generally and within each of the regional organizations. How can that collaboration best coordinate to tackle the mountain of system level testing? There is a growing trend to organizing the task around System VIPs, each providing a baseline for components of a specific system level check through traffic generation, testing and profiling. System VIPs have the same general intent as more conventional VIPs, though are inevitably more configurable around system level parameters and objectives.

The tables at the beginning of this blog show examples of capabilities you would expect system VIPs to support. Accelerating development of all necessary system verification components seems essential to quickly maturing verification quality to the same level as mainstream processor providers yet is beyond the reach of any but the largest verification teams, at least in the near term. The VIP model lends itself to collaborative standardization together with open source and commercial development. It will take a village to build this essential foundation for big RISC-V systems. We’ll all need to pitch in!

Breker tells me they would be happy share their ideas in more detail. Check them out HERE.

Also Read:

Breker’s Maheen Hamid Believes Shared Vision Unifying Factor for Business Success

Scaling the RISC-V Verification Stack

Breker Verification Systems Unleashes the SystemUVM Initiative to Empower UVM Engineering


A Bold View of Future Product Development with Matt Genovese

A Bold View of Future Product Development with Matt Genovese
by Mike Gianfagna on 08-01-2023 at 10:00 am

Matt Genovese

Matt Genovese is the founder of Planorama Design, a software requirements and user experience design professional services company.  The company designs simple and intuitive software and IoT product user interfaces for complex, technical applications and systems.  Its unique and proven approach reduces client development and support costs while accelerating achievement of key delivery timelines.  This new and bold type of company comes from Matt and his seasoned team’s deep experience in both chip design and software development.  Planorama can see many sides of the product development problem.

In his recent podcast interview, AI is Changing Software Development, Matt provided a paradigm-shifting perspective on the interplay of generative AI and future application creation. This innovative foresight presents a world where software is produced at a pace that is unprecedented, both in terms of speed and cost. While this may seem like a futuristic thought, the evidence is gradually emerging in our present reality.  Continue reading for a bold view of future product development with Matt Genovese, for both software and hardware products.

Matt’s Views:  AI-Accelerated Co-Design

Artificial Intelligence is behind a generational disruption in the software development cycles of record.  This is not about chatbots and simple Q&A prevalent in the popular literature and news.  Rather, this is about large language models (LLMs) actually interpreting product requirements and generating code implementation.  A variety of open-source software projects have already sprung up, demonstrating that software generation from product requirements, at least on a small scale, is feasible.  Matt emphasizes,

“Quite suddenly, we’ve seen a shift from software that has been developed purely by human software developers, to developers ‘collaborating’ with tools like Github Copilot and OpenAI’s GPT4 to write code.  Many companies, including my internal R&D team at Planorama are reporting very positive experiences and greatly increased development efficiency.  This trend will continue to shift towards additional AI involvement in this process.”

Now consider that this same type of generative AI can also write RTL in the HDL of your choice, derived from product requirements.  While early and limited in capabilities, HDL generation is possible today.  In recent short videos from Planorama, Matt demonstrates both OpenAI’s GPT4 and Github Copilot generating and supporting creation of behavioral RTL in Verilog, and even supporting testbenches.

Couple these nascent capabilities with a project like OpenROAD and OpenLane that aim for, “no human in the loop” from RTL to GDS2.  We are beginning to see natural points of connection emerge between various technologies that would enable end-to-end acceleration of both software and hardware from unified product specifications.

Matt explains that the original vision of hardware-software co-design manifests a future where the intertwined development processes are not only conceivable but integral to the hardware-software generation landscape. He anticipates powerful, specialized AI technologies will deftly navigate the complexities of partitioning between hardware and software, enablement of dynamic decision-making based on power, performance, cost, area constraints, and other variables to make a type of end-to-end co-design an achievable reality.  The realization of such a system could maximize efficiency and deliver novel solutions.  In this environment, AI tools would scrutinize the intricate trade-offs, optimizing the assignment of each function to either hardware or software.  Matt believes that as technology continues to innovate at a rapid pace, the hardware-software co-design paradigm’s potential is becoming a tangible game-changer for the industry.

To Learn More

You can listen to Matt’s original Futurati podcast here on audio, with a video version of the same podcast here

You can watch Matt’s short video demo using GPT4 to code an ALU and testbench in Verilog.

And here is a video  showing how Github Copilot can be used to write and edit Verilog

About the Company

Planorama Design is a unique company, as their mission is to accelerate time to market for software and IoT products.  How do they do this?  As a strategic partner for their technology business clients, Planorama drives solid product requirements, designing the software visual requirements (user interface designs), and delivering all the assets every product development team member needs to execute efficiently.  The results yield products that are easy to use, require less customer support, are more maintainable, and ensure customers experience the value of the solution.

Matt brings over 25 years of experience in high-tech, spanning semiconductors, hardware, IoT, IT, and software product development.  He has a forward-looking view of how to bring these skills together to accomplish the mission of Planorama Design.  AI plays an important role in his thinking, and that makes for a great podcast.  You can learn more about Planorama Design here.  And that’s a bold view of future product development with Matt Genovese.


Agile Analog Visit at #60DAC

Agile Analog Visit at #60DAC
by Daniel Payne on 07-31-2023 at 10:00 am

agile analog 60dac min

Chris Morrison, Director of Product Marketing at Agile Analog met with me on the Tuesday at DAC this year, and I asked what has changed in the last year for their analog IP business. The short answer is that the company has initially built up foundation IP for Analog Mixed-Signal (AMS) uses, then recently added new IP for data conversion, power management and chip monitoring and health.

I was surprised to learn just how much AMS IP they have to offer:

Data Conversion

  • 8/10 -bit DAC
  • 8/10 bit SAR ADC
  • 12 bit SAR ADC

Security

  • Voltage glitch detector

Power Management

  • Linear Regulator
  • Power-On-Reset
  • General purpose bandgap
  • Power Management (PMU) subsystem
  • Sleep Management (SMU) subsystem

Sensing

  • Temperature sensor
  • Programmable threshold comparator
  • PVT sensor subsystem
  • IR drop detector
  • Sensor interface subsystem

Always-on Domains

  • Digital standard cell library
  • RC oscillator

There are four initial subsystems and they may be combined to build even bigger systems along with RISC-V support. The interface protocols for Arm’s AMBA APB and SiFive’s TileLink are also supported, so that covers two of the most popular ISA choices out there today.

Chris also talked about some of the current IC design issues like mechanical stress, aging and reliability. What sets Agile Analog apart is the use of their Composa methodology, a rapid way to create new IP blocks based upon customer requirements, Agile Analog’s design recipe and the foundry PDK. So, this automates the front-end of the analog design process quite well, and in the works are further automation for the back-end as well, so stay tuned. New, sized schematics are created for IP blocks in under 10 minutes, which is quite a bit faster than the traditional, manual methods which require weeks of engineering effort. Foundry support for these analog IP blocks are from: TSMC, GlobalFoundries, Intel, Samsung, SMIC, and UMC. .

The Composa tool knows how to combine all of the analog transistors and circuits, just like an expert analog designer would. Connecting your Agile Analog IP blocks is made even easier by wrapping digital logic around the AMS portions, making verification a simpler task. About 50 IP blocks have been delivered to customers, so they are scaling up quickly and efficiently to meet demand.

Last year the company headcount was about 30-35 people, and now it’s grown to over 55, so that says something about their success as a company to meet a challenging market. With a HQ in Cambridge in the UK, the company also has sales offices to help with your questions in Asia, and the US.

In March Agile Analog joined the Intel Found Services (IFS) Accelerator IP Alliance Program, they’re part of the Samsung SAFE and they have just joined the TSMC OIP program too. In 2024 you can expect to see the company continue their growth path across the globe, and even more AMS IP blocks being added to the portfolio, ready to be customized to meet your unique requirements.

Summary

Analog IP has traditionally been a limiting factor in getting new SoCs to market on time and within spec, however with the more automated approach used at Agile Analog you can expect to use their AMS IP at your favorite foundry to speed time to market. Both RISC-V and ARM-based designs can quickly add AMS IP by using subsystems that have been digitally wrapped.

New IP blocks in development include: 12-bit DAC, clock monitor, ultra-low power LDO, ultra-low power bandgap, capless LDO, process sensor and free-running clock. I look forward to talking with Agile Analog again  to give you another update.

Related Blogs


Automated Code Review. Innovation in Verification

Automated Code Review. Innovation in Verification
by Bernard Murphy on 07-31-2023 at 6:00 am

Innovation New

A little thinking outside the box this time. Microsoft is adding automation to their (and LinkedIn) code reviews; maybe we should consider this option also? Paul Cunningham (Senior VP/GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, entrepreneur, former Synopsys CTO and now Silvaco CTO) and I continue our series on research ideas. As always, feedback welcome..

The Innovation

This month’s pick is Automating Code Review Activities by Large-Scale Pre-training. The paper published in the 2022 European Software Engineering Conference and Symposium. The authors are from Microsoft, LinkedIn, and Peking University.

This paper is interesting on two counts: first that it is a method to automate code change review and second that it uses a transformer model, very appropriate to text analysis. HuggingFace reports availability of CodeReviewer based on work by the same authors. Training is based on (past) real-world code change fragments, together with reviewer comments where available.

Changes are measured first on quality as judged by reviewer comments. Changes without comments are judged to be minor and of sufficient quality. Changes with comments suggest suspect quality. In training, comments are interpreted through natural language processing, looking for common patterns which can then be used to suggest comments on for new code changes. Finally, they combine this learning together with observed changes from the training set to suggest potential code changes to satisfy review comments.

Paul’s view

Our first blog on generative AI in verification and wow does it pack some punch! A global team of authors from Microsoft/LinkedIn and a few universities in China look at automatically generating code reviews. The paper was published late last year and describes a generative AI model called CodeReviewer that is based on a Transformer Large Language Model of similar complexity to OpenAI’s GPT-1.

Like any AI system, good training data is vital, and quite a bit of the paper is devoted to how the authors mine GitHub to create an impressive dataset covering 9 different programming languages and over 7.9M code review tickets.

I still find the whole process of training a Transformer super cool: you basically teach it different skills to build up to the desired generative capability. The paper eloquently walks us through the training steps used for CodeReviewer, teaching it first to understand the “+” and “-“ line prefix syntax for source code change diffs, then to “understand” code changes, then to “speak” the English language used to write a code review, and then finally to do the actual job of generating a code review in plain English from a code diff.

To benchmark CodeReviewer the authors split their dataset into two buckets: projects with 2.5k or more code reviews are used as training data and the remaining projects for benchmarking. Results are rock solid: 8% more accurate (72-74% vs. 64-66%) than the best of prior works at determining if a code change is good quality (meaning no review comments needed, it can be committed as is). For code review benchmarking the authors ask 6 expert programmers to personally inspect 100 randomly selected reviews and score them 1-5 for both relevance and informativeness. The average score for CodeReviewer is 3.2 compared to 2.5 for the best of prior works. Nice. And for a bit of fun the authors also do some qualitative comparisons of CodeReviewer with GitHub CoPilot, showing a few examples where CodeReviewer generates much better reviews than CoPilot.

Wonderful paper, well written and easy to read. Expect more from us on generative AI in future blogs – it’s going to transform (no pun intended) verification as well as so many other things in our daily lives!

Raúl’s view

This month we review a recent paper on automating code review. The results and the available CodeReviewer model are relevant and useful for anyone writing code in C, C++, C#, Go, Java, JavaScript, PHP, Python, and Ruby (covering much of EDA software).

The code review process as modeled in this paper consists of proposing a code change Code diff to an original code C0 resulting in a code C1, and then (1) estimating the quality of the code change, (2) generating a review comment RNL in natural language, and finally (3) code refinement in which a new version of the code is generated taking as inputs C1 and RNL. The authors construct a model called CodeReviewer for tasks 1, 2 and 3, with an encoder-decoder model based on Transformer, with 12 Transformer encoder layers and 12 decoder layers, 12 attention heads in each layer and the hidden size is 768. The total parameter size of the model is 223M. The paper goes into great detail on how to get the data to pre-train and fine tune the model. The used dataset is collected from GitHub and the pre-training set consists of 1,161 projects with a total of 7,933,000 pull requests.

Results are compared with three baselines, a state-of-the-art (SOTA) model architecture Transformer trained from scratch and two pre-trained models: T5 for code review and CodeT5 [43].  Table 4 shows that CodeReviewer is superior than all 3 networks for quality estimation (1) in terms of precision (true positive / (true + false positive)), recall (true positive / (true positive + false negative)), F1 (weighted average of precision and recall) and accuracy ((true positive + negative) / total). Performance on review generation is also better in terms of BLEU scores (bilingual evaluation understudy which evaluates quality of machine translation on a scale of 0-100) and human evaluations. The BLEU score is still lower than 10, indicating it is a hard task. In terms of code refinement (3) CodeReviewer successfully generates the repaired code exactly as ground truth for more than 30% cases, which is two times as the result of T5 and 25% more than CodeT5 relatively. Interestingly, table 8 gives results for the influence of the multilingual dataset, showing that for Java, C# and Ruby training with all languages improves the accuracy by 2.32% and the F1 score by 1.10% on average.

The presented results are better than the state of the art. They hinge on collecting and organizing a large-scale dataset from GitHub. Unfortunately, to my knowledge, there are no comparable data collections for hardware designs written in Verilog, VHDL, SystemC, etc., so it is an open question whether CodeReviewer can be used for hardware design. Perhaps closer to home, whether a code review of EDA SW would yield similar results than the ones reported, given that CodeReviewer was trained so carefully with different kinds of SW, is an interesting question which EDA companies can try to answer. Given that “multilingual dataset benefits the CodeReviewer for understanding specific languages significantly… It also proves the broad applicability of CodeReviewer in different programming languages” there is reason to speculate for broad applicability for different kinds of SW.