Wondering if industry would take the scenario of 10 nm space between gate stacks seriously. Trying to plan some work there...
Industry is trying to survive where they are now (40 nm?).
10 nm between gates is not a lot of room, though. The oxide and nitride thicknesses are also scaling down as well.
10 nm between gates is not a lot of room, though. The oxide and nitride thicknesses are also scaling down as well.
My guess is that 10nm is too far away from now so no industry wants to make any plan for it.
Chip makers have plans for the next generation. I doubt they think much at the overnext one.
Anyway, we're moving ever slower.
Features shrink at a slower pace now, and this requires more and more investment. Even worse, shrinking doesn't mean faster clocks any more. Cpu makers try to convince computer users that multiple cores without faster clocks will improve speed, but that's not the case for most software, especially existing software.
So I'd really prefer chip makers to work in other directions. Not on smaller features (expensive and with little results) but on faster communications within chips, so that clock speeds can increase again.
That is, metal lines, whose voltage diffusion time get worse as features shrink, should be replaced by "other means"... Solitons? Photons? Anyway, we need them to run fast and we need the data lines to be narrow, as a single bus with 500 bits won't be enough eternally - so photons might better take no guide, spread to the whole chip and be multiplexed by wavelength for instance, or fly through air and be guided by a mirror.
We'll know soon... Because if clock speeds don't improve quickly, then processors and related software derived from graphics chips will eradicate CPUs and traditional software, as massive parallelism will be the only way.
Chip makers have plans for the next generation. I doubt they think much at the overnext one.
Anyway, we're moving ever slower.
Features shrink at a slower pace now, and this requires more and more investment. Even worse, shrinking doesn't mean faster clocks any more. Cpu makers try to convince computer users that multiple cores without faster clocks will improve speed, but that's not the case for most software, especially existing software.
So I'd really prefer chip makers to work in other directions. Not on smaller features (expensive and with little results) but on faster communications within chips, so that clock speeds can increase again.
That is, metal lines, whose voltage diffusion time get worse as features shrink, should be replaced by "other means"... Solitons? Photons? Anyway, we need them to run fast and we need the data lines to be narrow, as a single bus with 500 bits won't be enough eternally - so photons might better take no guide, spread to the whole chip and be multiplexed by wavelength for instance, or fly through air and be guided by a mirror.
We'll know soon... Because if clock speeds don't improve quickly, then processors and related software derived from graphics chips will eradicate CPUs and traditional software, as massive parallelism will be the only way.
Thanks E that is a good thought.
I would generalize my question though, to a ~10 nm gap between any two connecting nodes. Should the ideal gap be larger (so that current lithography is overkill)? For optical interconnects, that would clearly be the case.
I would generalize my question though, to a ~10 nm gap between any two connecting nodes. Should the ideal gap be larger (so that current lithography is overkill)? For optical interconnects, that would clearly be the case.
True, optical interconnects can't be that small, because the evanescent wave reaches much farther. And since we want dense circuit as well, it means that local connections will remain in conductor wires. If we get optical connections within chips someday (optical chip-to-chip isn't as important, as wires are nearly as good), then their width will limit their use to a few busses across the chip. Or these communications won't use and guide, spread to the whole chip, and be multiplexed another way - by wavelength for instance.
Solitons? To be seen.
Time is running out. i386 and x64 -compatible processors need to progress quickly, and not just by the number of cores, because
- My applications are single-task
- Graphics processors do better than x64 on multitasked applications
Solitons? To be seen.
Time is running out. i386 and x64 -compatible processors need to progress quickly, and not just by the number of cores, because
- My applications are single-task
- Graphics processors do better than x64 on multitasked applications
Well, would it help making chips, if you had perfect lenses? Something like +-1 atomic layer thickness precision, over a lens of few mm diameter?
Maybe this can be made, and then semiconductor processing is rich enough to let produce such lenses. They would be made of single-crystal (quartz? Nice for UV, isn't it?) so that a tunnel microscope or an atomic force microscope could measure their form to one atom precision, and semiconductor manufacturing processes would fine-trim the form of the lens.
More details there:
http://saposjoint.net/Forum/viewtopic.php?f=66&t=1820
Drawings begin there
http://saposjoint.net/Forum/viewtopic.php?f=66&t=1820#p20885
Vague indications for manufacturing
http://saposjoint.net/Forum/viewtopic.php?f=66&t=1820#p20891
Marc Schaefer, aka Enthalpy
Maybe this can be made, and then semiconductor processing is rich enough to let produce such lenses. They would be made of single-crystal (quartz? Nice for UV, isn't it?) so that a tunnel microscope or an atomic force microscope could measure their form to one atom precision, and semiconductor manufacturing processes would fine-trim the form of the lens.
More details there:
http://saposjoint.net/Forum/viewtopic.php?f=66&t=1820
Drawings begin there
http://saposjoint.net/Forum/viewtopic.php?f=66&t=1820#p20885
Vague indications for manufacturing
http://saposjoint.net/Forum/viewtopic.php?f=66&t=1820#p20891
Marc Schaefer, aka Enthalpy
only 10Nm? this shouldn't be a problem for an r2 unit
Are we already heading in the wall?
Playstations / Wii / XBox / etc won't improve in the near future:
http://business.blogs.cnn.com/2009/09/07/w...-playstation-4/
seemingly because technology improvement has gotten too expensive.
That's sort of annoying. Customers have kept buying electronic toys every third year because the new one was more capable. I doubt they will keep this pace just because pink is out-fashioned this year.
Shall we say adios - byebye - arrivederci to 2/3 of the incomes of the consumer electronics industry?
Playstations / Wii / XBox / etc won't improve in the near future:
http://business.blogs.cnn.com/2009/09/07/w...-playstation-4/
seemingly because technology improvement has gotten too expensive.
That's sort of annoying. Customers have kept buying electronic toys every third year because the new one was more capable. I doubt they will keep this pace just because pink is out-fashioned this year.
Shall we say adios - byebye - arrivederci to 2/3 of the incomes of the consumer electronics industry?
Signal diffusion time in resistive lines can be improved though.
As I was involved in semiconductors, that is at 6µm channel length (trenches cut with flintstone, implantation through reindeer bones then), signal diffusion time was already a limit in DRAM chips. A proposed turnaround was to put amplifiers at many places on these lines. Then, propagation time got proportional to the line's length instead of the length squared.
Specifically for DRAM, proposed amplifiers were bistable flipflops in parallel with the line, forced at 1/2 equilibrium, but released to go to 0 or 1 as the signal from the previous amplifier on the line was supposed to have arrived.
On a processor bus, I'd prefer classical, bidirectional amplifiers.
In both cases, you need an extra pair of lines telling the amplifiers that the signal has arrived, or in which direction it flows. These (monodirectional) lines must have (permanent) amplifiers as well.
Is this generalized nowadays on processor bus? Probably yes, as the idea is old and obvious.
As I was involved in semiconductors, that is at 6µm channel length (trenches cut with flintstone, implantation through reindeer bones then), signal diffusion time was already a limit in DRAM chips. A proposed turnaround was to put amplifiers at many places on these lines. Then, propagation time got proportional to the line's length instead of the length squared.
Specifically for DRAM, proposed amplifiers were bistable flipflops in parallel with the line, forced at 1/2 equilibrium, but released to go to 0 or 1 as the signal from the previous amplifier on the line was supposed to have arrived.
On a processor bus, I'd prefer classical, bidirectional amplifiers.
In both cases, you need an extra pair of lines telling the amplifiers that the signal has arrived, or in which direction it flows. These (monodirectional) lines must have (permanent) amplifiers as well.
Is this generalized nowadays on processor bus? Probably yes, as the idea is old and obvious.
Those are some very interesting thoughts Enthalpy.
I found nanogaps (~10 nm scale in fact) between metal electrodes can behave as resistance switches - sometimes they conduct, sometimes not, it can be controlled to some degree.
Something about ion motion controlling tunneling distance.
I found nanogaps (~10 nm scale in fact) between metal electrodes can behave as resistance switches - sometimes they conduct, sometimes not, it can be controlled to some degree.
Something about ion motion controlling tunneling distance.
Well, if you can repeatably control a tunnel effect, it could be an interesting device.
To check if ion movement is the cause of the varying tunnel current, a possibility (you already did it, probably) is to observe the response time at different temperatures and look if it is nicely related to an activation energy, and then whether this energy is compatible with an ion movement.
At somewhat bigger scales, and then with higher voltages, people already build gate-controlled spike emitters, which is indeed a controlled tunnel effect. In an other thread here I put some figures on the use of such valves for high frequencies (THz) with a photoelectric anode or a resonating one.
Could it be interesting for logic gates at small scales and voltages? I haven't checked it. It depends just on achievable currents and charges. Don't be discouraged if it needs Jfet-like polarizations: when I designed GaAs circuitry (a long long time ago), we coped with such inconvenient polarizations to exploit the then better speed of Mesfet.
To check if ion movement is the cause of the varying tunnel current, a possibility (you already did it, probably) is to observe the response time at different temperatures and look if it is nicely related to an activation energy, and then whether this energy is compatible with an ion movement.
At somewhat bigger scales, and then with higher voltages, people already build gate-controlled spike emitters, which is indeed a controlled tunnel effect. In an other thread here I put some figures on the use of such valves for high frequencies (THz) with a photoelectric anode or a resonating one.
Could it be interesting for logic gates at small scales and voltages? I haven't checked it. It depends just on achievable currents and charges. Don't be discouraged if it needs Jfet-like polarizations: when I designed GaAs circuitry (a long long time ago), we coped with such inconvenient polarizations to exploit the then better speed of Mesfet.
After Intel unveiled at IDF future projects, my own comments, half a penny worth. On architecture, not processes.
- Nice that they plan a dual-core processor with a faster clock. That's what I expect.
- Future vector hardware and instruction set: I'd ilke them to work on vectors of variable length and much longer than the computing unit, so that the instruction set doesn't change at all when future processors integrate wider computing units.
- Functional parallelism: maybe each unit (addresses computation, Load/Store, integer, float... May have several of each type) can have its own L1 cache holding only the instruction of the corresponding type, and tell the sequencer "I have everything to go to cycle number thatmuch" or "to loop count thatmuch", and the sequencer would only decide "Then, everybody goes to cycle thatmuch". Still compatible with i86, with a more parallel decision path and more instruction bandwidth.
- High parallelism in loops would be easier with instructions that configure the hardware, in a remnant way, before ticking just a loop counter. Like "This address will increment by 4" and "the accumulator must take its input from the multiplier" and "The counter must decrement and compare to zero". We can still define several kinds of ticks that command different groups of recently defined actions, for flexibility.
[No more compatible with i86, sorry. I think OpenGL works like this.]
- There, I propose to compress executable code a bit in order to accept less throughput and capacity from hard disks, Ram, maybe L2:
http://www.msfn.org/board/index.php?showtopic=129474
The code would be moderately compact but very easy to expand so that on-chip additional hardware would decode it at full speed with no added latency. If the corresponding hardware works for instance at L2 speed, then only L1 stores expanded code.
Compressing at 3:2 only the code (not the data) would save up to one Ram access bus, maybe 1/5th of L3 and L2's size, and 1/5th of hard disk slowness.
- Nice that they plan a dual-core processor with a faster clock. That's what I expect.
- Future vector hardware and instruction set: I'd ilke them to work on vectors of variable length and much longer than the computing unit, so that the instruction set doesn't change at all when future processors integrate wider computing units.
- Functional parallelism: maybe each unit (addresses computation, Load/Store, integer, float... May have several of each type) can have its own L1 cache holding only the instruction of the corresponding type, and tell the sequencer "I have everything to go to cycle number thatmuch" or "to loop count thatmuch", and the sequencer would only decide "Then, everybody goes to cycle thatmuch". Still compatible with i86, with a more parallel decision path and more instruction bandwidth.
- High parallelism in loops would be easier with instructions that configure the hardware, in a remnant way, before ticking just a loop counter. Like "This address will increment by 4" and "the accumulator must take its input from the multiplier" and "The counter must decrement and compare to zero". We can still define several kinds of ticks that command different groups of recently defined actions, for flexibility.
[No more compatible with i86, sorry. I think OpenGL works like this.]
- There, I propose to compress executable code a bit in order to accept less throughput and capacity from hard disks, Ram, maybe L2:
http://www.msfn.org/board/index.php?showtopic=129474
The code would be moderately compact but very easy to expand so that on-chip additional hardware would decode it at full speed with no added latency. If the corresponding hardware works for instance at L2 speed, then only L1 stores expanded code.
Compressing at 3:2 only the code (not the data) would save up to one Ram access bus, maybe 1/5th of L3 and L2's size, and 1/5th of hard disk slowness.
The point of them being itsy bitsy is to save room. The only way to make it go faster now is by changing the material used in it or just refering back to the good old light-speed processors. Mirrors would be good for this. This would make it insanely fast and hey, we already have it small, what more could we want? Unlimited speed and capacity. Fun. Programming capabilities have also sky-rocketed lately. Even more fun. Pretty soon, all of this will be old news. Get ready to embrace the future. 
Dude, no offense, but that was the dumbest post i have ever seen.
(Even dumber than some of mine, and that's an accomplishment.)
(Even dumber than some of mine, and that's an accomplishment.)
With a 10 nm gate length, and only 10 uA current, we have maybe two electrons crossing in the channel at 1 V at any given instant?
10 nm space is pretty tight - if you want to squeeze a 7 nm contact in between, only 1.5 nm distance to gate on each side. Leakage gonna be crazy.
Very interesting thoughts, all, have to ponder a bit more...
Back to optical interconnects within a chip. Not with light guides, but in free space and with filters to multiplex wavelengths.
A first application could be Ram.
Take Gddr5 for instance, its data is 32 bits wide, and both raw and column addresses are narrower than 32 bits. It's a nice candidate because
- Signal diffusion is slow in the long metal lines of Ram;
- The same data (row and column address) must be broadcast to many subarrays;
- Little data must be gathered from many possible subarrays.
- Each point can transmit or receive a single wavelength.
So with optical interconnects, you can divide the Ram in many smaller areas, which are fast, and quickly scatter-gather addresses and data to all subarrays using few wavelengths.
What it needs is light emitters (hot research topic on silicon) at about 32 different wavelengths, one set for each subarray plus the chip's I/O, and optical filters (maybe an oval or a strip of waveguide can already do the trick as a tuned antenna, if wavelengths are spread enough).
What it doesn't need are numerous waveguides all over the chip. A reflective cap, or a single broad flat waveguide, are enough.
Marc Schaefer, aka Enthalpy
A first application could be Ram.
Take Gddr5 for instance, its data is 32 bits wide, and both raw and column addresses are narrower than 32 bits. It's a nice candidate because
- Signal diffusion is slow in the long metal lines of Ram;
- The same data (row and column address) must be broadcast to many subarrays;
- Little data must be gathered from many possible subarrays.
- Each point can transmit or receive a single wavelength.
So with optical interconnects, you can divide the Ram in many smaller areas, which are fast, and quickly scatter-gather addresses and data to all subarrays using few wavelengths.
What it needs is light emitters (hot research topic on silicon) at about 32 different wavelengths, one set for each subarray plus the chip's I/O, and optical filters (maybe an oval or a strip of waveguide can already do the trick as a tuned antenna, if wavelengths are spread enough).
What it doesn't need are numerous waveguides all over the chip. A reflective cap, or a single broad flat waveguide, are enough.
Marc Schaefer, aka Enthalpy