Beyond 10 nm at TSMC: 7 nm DUV and 7 nm EUV

As noted previously, TSMC’s 7 nm node will be used by tens of companies for hundreds of chips targeting different applications. Initially, the company plans to offer two versions of the manufacturing technology: one for high-performance, and one for mobile applications, both of which will use immersion lithography and DUV. Moreover, eventually TSMC intends to introduce a more advanced 7nm fabrication process that will use EUV for critical layers, taking a page from GlobalFoundries’ book (which is set tp start 7 nm with DUV and then introduces second-gen 7 nm with EUV).

TSMC’s first-generation CLN7FF will enter risk production in Q2 2017 and will be used for over a dozen of tape outs this year. It is expected that high-volume manufacturing (HVM) using the CLN7FF will commence in ~Q2 2018, so, the first “7-nm” ICs will show up in commercial products in the second half of next year. When compared to the CLN16FF+, the CLN7FF will enable chip developers to shrink their die sizes by 70% (at the same transistor count), drop power consumption by 60% or increase frequency by 30% (at the same complexity).

The second-generation 7 nm from TSMC (CLN7FF+) will use EUV for select layers and will require developers to redesign EUV layers according to more aggressive rules. The improved routing density is expected to provide ~10-15-20% area reduction and enable higher performance and/or lower power consumption. In addition, production cycle of such chips will get shorter when compared to ICs made entirely using DUV tools. TSMC plans to start risk production of products using its CLN7FF+ in Q2 2018 and therefore expect HVM to begin in H2 2019.

Advertised PPA Improvements of TSMC's CLN7FF Nodes
Data announced by TSMC during conference calls, press briefings and in press releases
Power 60% <40% 10% lower
Performance 30% ? lower higher
Area Reduction 70% >37% ~10-15-20% tangible
HVM Start ~Q2 2018 - ~H2 2019 ~H2 2020

As it turns out, all three leading foundries (GlobalFoundries, Samsung Foundry and TSMC) all intend to start using EUV for select layers with their 7 nm nodes. While ASML and other EUV vendors need to solve a number of issues with the technology, it looks like it will be two years down the road before it will be used for commercial ICs. Of course, certain slips are possible, but looks like 2019 will be the year when EUV will be here. In fact, keeping in mind that both TSMC and Samsung are already talking about their second-gen EUV technologies (which they call 5 and 6 nm) that will use more EUV layers, it looks like the foundries are confident of the ASML TwinScan NXE manufacturing tools (as well as of the Cymer light source, pellicles, photoresists, etc.) they are going to use.

10 nm: Samsung Is Shipping, TSMC Is Steady Beyond 10 nm at Samsung: 8 nm and 6 nm
Comments Locked


View All Comments

  • Hulk - Friday, May 5, 2017 - link

    Yeah it's called "Assembly." We'll have come full circle. In the beginning it was assembly because processors were so slow. And it appears the end it will also be Assembly as processor power stalls. Kind of fitting. I used to program in Assembly on my Atari 800 back in 1982.
  • vladx - Friday, May 5, 2017 - link

    Not sure if serious, Assembly can work for small to medium projects, but not really big ones.
  • patrickjp93 - Friday, May 5, 2017 - link

    Roller Coaster Tycoon was programmed 100% in assembly, and that is not a medium-sized project.
  • vladx - Friday, May 5, 2017 - link

    Only the first 2 RCT games were wwritten in assembly and both had only 2d graphics so it was mostly game logic which doesn't take much code. So yes, I would call that a mid-sized project.
  • mapesdhs - Saturday, May 6, 2017 - link

    I once wrote an entire word processor in 68K, it worked very well (students ended up using it instead of the Uni-supplied program). People make false assumptions about coding in assembly. Beyond a certain point in complexity, its use becomes more like a high level language, ie. setting parameters and calling procedures & functions. Just the natural way one solves problems in a structured manner brings this about. Assembler doesn't inherantly lend itself to structured programming, but it doesn't have to; it's not hard to use it in a way that makes up for such issues, ie. a long as the design process itself is structured. I found it to be the best of both worlds, getting at the raw metal but also being able to focus on higher level design issues. Easily the most fun project I ever worked on, and the largest printed listing the uni in question had ever received at the time. :D (took 2.5 hours to print out)
  • prisonerX - Sunday, May 7, 2017 - link

    Yeah, Roller Coaster Tycoon was written in 1999, nearly 20 years ago.

    Welcome to the 21st century, you might want to look around, some things have changed.
  • prisonerX - Sunday, May 7, 2017 - link

    Uh, no. A compiler like GCC or LLVM will beat hand coded assembly every time on modern processors, without fail, unless you're talking about tiny or specialized code (say, bootloaders).

    The mistake you're making could be characterised as "premature optimisation" on a grand scale. You think if you tweak every bit of code and write it in assembly you'll get something more efficient. Sorry to break it to you, but you won't. Good structure (this includes choice of data structures and algorithms) is a greater influence on code than tweaking, if you're talking about anything of a reasonable and practical size.
  • Kevin G - Sunday, May 7, 2017 - link

    The general rule of thumb is that hand coded assembly will be used in critical loops to accelerate portions of code that compilers like GCC or LLVM produce.

    You're not wrong about data structures and algorithm choice but in the light of smart decisions there, assembly is the next level of optimization. Assembler can't fix GIGO.
  • amosbatto - Monday, May 21, 2018 - link

    I doubt that assembly will come into vogue, but a whole new generation of compiled languages are appearing which are designed for speed and low resource consumption: Rust, Julia, Swift, Go and NIM. These languages have performance which is slightly slower than C, but without its security problems, so I expect them to be widely used in the future as the hardware stops getting faster.
  • Meteor2 - Friday, May 5, 2017 - link

    More to come from ISA developments, too. Maybe not huge amounts but definitely some -- SVE for example.

Log in

Don't have an account? Sign up now