IBM: Chip Making is Hitting Its Limits, But Our Techniques Could Solve That (zdnet.com) 50
IBM has devised materials and processes that could help improve the efficiency of chip production at the 7nm node and beyond. From a report: The company's researchers are working on challenges in the emerging field of 'area-selective deposition', a technology that could help overcome limitations on lithographic techniques to create patterns on silicon in 7nm processes. Semi Engineering has a neat account of lithographic patterning and why at 7nm there's growing interest in area-selective deposition. Techniques such as 'multiple patterning' helped ensure integrated circuits kept scaling, but as chips have shrunk from 28nm to 7nm processes, chipmakers have needed to process more layers with ever-smaller features that need more precise placement on patterns. Those features need to align between layers. When they don't, it leads to 'edge placement error' (EPE), a challenge that Intel lithography expert Yan Borodovsky believed lithography couldn't solve and which would ultimately impede Moore's Law.
Uh... Wrong Problem IBM (Score:5, Interesting)
Re: (Score:2)
Why are you wasting your technical ability posting to Slashdot when you could be leading IBM's chip division?
Maybe rfengineer does both!
Re: (Score:2)
Heat prevents a 3D chip? Lay down a thick layer of heat conductive material, before the next layer of logic. Ok, you won't get 80.000 layers that way, perhaps only 800.
You will not get any layers that way; any thin heat conductive layers between chips just does not support the needed increase in thermal conductivity needed to help significantly.
High performance chips have been thermal limited for many process generations now. Anything which increases the junction to surface thermal resistance will just make them more thermal limited. About the only thing which would help for a single chip is a better heat spreader made of something with a better thermal conductivity tha
Re: (Score:2)
Really? My impression is that problems like those of shot noise inherent in the optical lithographic process are significant for continued scaling.
Leakage due to quantum tunneling can't be solved anyway except by increasing the gate dielectric thickness.
Re: (Score:2)
Re: (Score:1)
Uh... translation: "I have no clue what they're talking about so I will spout about this thing I heard about years ago."
Lithography has got plenty of show stoppers. Maybe you haven't heard about the transition from transmissive to reflective optics, to name one gigantic issue. Ever heard the word "pellicle?"
Re: (Score:3)
For example, TSMC's 7nm process yields 83 million transistors per mm^2 [wikipedia.org]. Meanwhile, the 10nm process Intel was working on yielded 100 million transistors per mm^2 [wikipedia.org], indicating its average component size was smaller despite having a larger nm name. In fact, TSMC's 7nm process yields only twice the transistor density of Intel's 14nm process [wikipedia.org], not 4x as you'd expect if the nm were refer
This is one of those articles... (Score:5, Funny)
They want to work at a very small scale, using very big words.
Re: (Score:2)
"Chip making has hit it's limits"
Oh no! What am I going to do now?!
"Our techniques could solve that"
Oh thank goodness! Do you take Bitcoin?
Re: (Score:3)
What did you do there AC? Empty trashcans or get coffee for people with a clue?
Basic R&D is what got us the cool toys we have today. Companies doing research for the sake of research that may not be immediately profitable. This is what brought us wonderful things like the UNIX operating system and the microprocessor.
Perhaps improve software first (Score:5, Insightful)
Instead of using lots of scripting languages and VM with frameworks that suck up huge volumes of memory and are so poorly written they require large amounts of CPU time to do very little, perhaps there should be a return to an emphasis on more effcient compiled languages that only use what resources they need at any given time.
Yeah I know, get off my lawn etc. But that fact that script kiddy coders don't like being told that their toy language is a bloated CPU hogging mess doesn't change the reality of the situation.
Re: (Score:1)
You aren't wrong. However, a lot of projects have unreasonable time frames for deployment for that optimization part. There's steps to help try to make that optimization more automatic, like tree shaking, VMs that run closer to metal, lighter containers, document parsers that automatically create an index... But yeah, we need better resource management and we need people who make the calls and set the timelines to understand that it's better if we focused on optimization in the long run.
Re:Perhaps improve software first (Score:5, Informative)
One platform at a time (Score:2)
Instead of using lots of scripting languages and VM with frameworks that suck up huge volumes of memory and are so poorly written they require large amounts of CPU time to do very little, perhaps there should be a return to an emphasis on more effcient compiled languages that only use what resources they need at any given time.
With VMs:
Without VMs:
In an environment with "more efficient compiled languages" replacing VMs and big frameworks such as React or Qt, how would you recommend to bridge platform gaps?
Re: (Score:2)
Most *progams* only run on one architecture anyway but perhaps you've not heard of compile time options in code that allow you to use the same source code for multiple platforms.
Do you actually work with computers or did you get lost here on the way to Facebook?
Sharing view code; cross-testing (Score:2)
Most *progams* only run on one architecture anyway but perhaps you've not heard of compile time options in code that allow you to use the same source code for multiple platforms.
If you have designed your application with a model-view-controller paradigm, you can reuse the model layer across multiple platforms. However, you cannot so easily reuse view code across Win32, Cocoa, X11, Android, and Chrome OS DOM platforms without a multi-platform framework such as Qt, and I assume Qt is one of the "frameworks that suck up huge volumes of memory" that you mention. And even if you cross-compile your application to a platform that you don't have, it's a bit harder to cross-test the respons
Re: (Score:2)
Thanks for the heads up on your 1990s design pattern knowledge, but I was talking mainly about backend code on proper computers, not silly little smartphone apps. As for Qt, its one of the better ones out there.
Re: (Score:2)
I was talking mainly about backend code on proper computers
And I was talking about frontend code on proper computers. You'll have trouble building an application using X Athena Widgets for a non-*n?x target, one using Win32 for a non-Windows target, or one using Cocoa for a non-macOS target. If Qt papers over these differences and isn't considered bloat, that's solved. But the difficulty of testing an application for a platform you don't own remains, particularly if you don't yet have enough capital to set up an in-house testing lab.
Re: (Score:1)
I have coded in Qt for years. It's really pleasant to use, and not bloated at all. Yes, on Windows the DLLs take quite a big amount of space, but only on disk, not so much when running the program.
A framework that sucks huge amounts of memory and that runs on top of an scripting language is Electron.
DLL download cost at $10/GB (Score:2)
Yes, on Windows the DLLs take quite a big amount of space, but only on disk
Is this true of macOS as well? This becomes doubly important as Macs switch to SSDs. And for developers who have a lot of users stuck behind satellite Internet or cellular tethering at $5 to $10 per GB, how well do Qt DLLs compress for distribution?
Besides, testing cross-compiled macOS binaries can still prove expensive for a micro-ISV.
Re: (Score:1)
I have never owned a Mac, nor do I plan to do so, so I can't answer your question.
Regarding compression, I just did a test with the first Qt5 program I could find installed on this Windows machine. Uncompressed size 57 MB, compressed size 18 MB. If you build Qt yourself and statically link only what you really need, I think the size would be smaller.
Re: (Score:3, Insightful)
False choice detected.
The beauty of more-efficient hardware is that it will improve the performance of all software -- bloated and non-bloated alike.
In the meantime, there's no need to wait on IBM (or to demand that IBM wait on us) to start writing non-bloated software, we can start doing that today. With or without IBM's magic beans, anyone who does so gains a competitive advantage over those who do not.
Re: (Score:3)
Reversible moon shot (Score:2)
IBM: We're still relevant, honest! (Score:1)
Why won't anyone belieeeeeve us?