By: slacker (s.delete@this.lack.er), March 17, 2008 10:04 am
Room: Moderated Discussions
Howard Chu (hyc@symas.com) on 3/17/08 wrote:
---------------------------
>That's a non-sequitur. Nobody said it had to be CMOS-based. E.g. graphene...
You were talking about CMOS whether or not you were aware of it. Let us go back to the statement which spawned this dialogue:
The only sort of news you hear about terahertz transistors falls under one of the following four categories:
1. Theoretical models for the f_t or f_max of NMOS devices
2. Theoretical models for the f_t or f_max of GaAs BJTs or InP HBTs
3. Theoretical models for the f_t or f_max of some kind of HEMT or pHEMT
4. A supercooled, one-off version of one of the above
Now, no one cares about GaAs, InP, BJTs, HEMTs, or pHEMTs for any sort of digital logic. This is because all of those circuits consume incredible amounts of static power, which is simply not viable. If it were viable, we'd just use ECL, but we don't. Thus, the only viable THz-transistor technology you could have been talking about are NMOS devices on a CMOS process.
You might be angry at this point and want to scream out, "no one said it has to be CMOS technology!!" Well, the problem here is that there simply isn't any news about THz graphene/ballstic transistors. To the best of my knowledge, there aren't any papers which report f_t or f_max figures for graphene/ballistic transistors. There are papers which report theoretical electron mobility values of 15 000cm^2/(V*s) for graphene, but nothing about actual transistor performance. There are the researchers at Rochester who seem to think they can build single-electron, ballistic transistors, but I haven't seen any results.
I would love to be proven wrong here and shown high-performance carbon transistors, because then I can have more optimism towards alternate transistor materials and structures. I believe that a change of materials/structures is fundamentally necessary towards the continued frequency scaling of large-scale, digital integrated circuits. However, until someone can actually make these devices in more than single-unit quantities, I will remain pessimistic towards the future of digital VLSI.
---------------------------
>That's a non-sequitur. Nobody said it had to be CMOS-based. E.g. graphene...
You were talking about CMOS whether or not you were aware of it. Let us go back to the statement which spawned this dialogue:
- "Considering all the news articles about terahertz transistors recently,
it's probably premature to say we've hit a permanent clock speed limit."
The only sort of news you hear about terahertz transistors falls under one of the following four categories:
1. Theoretical models for the f_t or f_max of NMOS devices
2. Theoretical models for the f_t or f_max of GaAs BJTs or InP HBTs
3. Theoretical models for the f_t or f_max of some kind of HEMT or pHEMT
4. A supercooled, one-off version of one of the above
Now, no one cares about GaAs, InP, BJTs, HEMTs, or pHEMTs for any sort of digital logic. This is because all of those circuits consume incredible amounts of static power, which is simply not viable. If it were viable, we'd just use ECL, but we don't. Thus, the only viable THz-transistor technology you could have been talking about are NMOS devices on a CMOS process.
You might be angry at this point and want to scream out, "no one said it has to be CMOS technology!!" Well, the problem here is that there simply isn't any news about THz graphene/ballstic transistors. To the best of my knowledge, there aren't any papers which report f_t or f_max figures for graphene/ballistic transistors. There are papers which report theoretical electron mobility values of 15 000cm^2/(V*s) for graphene, but nothing about actual transistor performance. There are the researchers at Rochester who seem to think they can build single-electron, ballistic transistors, but I haven't seen any results.
I would love to be proven wrong here and shown high-performance carbon transistors, because then I can have more optimism towards alternate transistor materials and structures. I believe that a change of materials/structures is fundamentally necessary towards the continued frequency scaling of large-scale, digital integrated circuits. However, until someone can actually make these devices in more than single-unit quantities, I will remain pessimistic towards the future of digital VLSI.
Topic | Posted By | Date |
---|---|---|
Multicore is unlikely to be the ideal answer. | Anders Jensen | 2008/02/14 04:24 AM |
And the links.. | Anders Jensen | 2008/02/14 04:25 AM |
Disappointing.. | Linus Torvalds | 2008/02/14 10:17 AM |
Disappointing.. | Mark Roulo | 2008/02/14 11:03 AM |
LOL (NT) | Linus Torvalds | 2008/02/14 05:43 PM |
Disappointing.. | David Patterson | 2008/02/15 11:53 AM |
Disappointing.. | Linus Torvalds | 2008/02/15 05:01 PM |
Disappointing.. | anon | 2008/02/15 08:54 PM |
Disappointing.. | JasonB | 2008/02/19 07:45 PM |
Disappointing.. | Ilya Lipovsky | 2008/02/22 06:27 PM |
Disappointing.. | Scott Bolt | 2008/03/16 11:36 AM |
Need for new programming languages | Vincent Diepeveen | 2008/02/19 06:18 AM |
Need for new programming languages | Pete Wilson | 2008/02/24 11:41 AM |
Disappointing.. | Zan | 2008/02/25 10:52 PM |
Disappointing.. | Robert Myers | 2008/02/19 09:47 PM |
Disappointing.. | Fred Bosick | 2008/02/22 06:38 PM |
Disappointing.. | Robert Myers | 2008/03/01 01:17 PM |
The limits of single CPU speed are here. | John Nagle | 2008/03/14 10:55 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/15 01:02 AM |
The limits of single CPU speed are here. | slacker | 2008/03/15 08:08 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/17 01:47 AM |
The limits of single CPU speed are here. | slacker | 2008/03/17 10:04 AM |
And the links.. | Howard Chu | 2008/02/14 12:58 PM |
I take some of that back | Howard Chu | 2008/02/14 01:55 PM |
And the links.. | Jesper Frimann | 2008/02/14 02:02 PM |
And the links.. | Ilya Lipovsky | 2008/02/15 02:24 PM |
And the links.. | iz | 2008/02/17 10:55 AM |
And the links.. | JasonB | 2008/02/17 07:09 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 01:54 PM |
And the links.. | JasonB | 2008/02/18 10:34 PM |
And the links.. | Thiago Kurovski | 2008/02/19 07:01 PM |
And the links.. | iz | 2008/02/20 10:36 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 03:37 PM |
And the links.. | JasonB | 2008/02/20 06:28 PM |
And the links.. | JasonB | 2008/02/17 06:47 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 02:27 PM |
And the links.. | JasonB | 2008/02/18 10:00 PM |
And the links.. | JasonB | 2008/02/19 03:14 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 04:29 PM |
And the links.. | JasonB | 2008/02/20 06:14 PM |
And the links.. | Ilya Lipovsky | 2008/02/21 11:07 AM |
And the links.. | Howard Chu | 2008/02/14 01:16 PM |
And the links.. | Jukka Larja | 2008/02/15 03:00 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 11:41 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/15 12:49 PM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 03:48 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/17 05:42 PM |
Berkeley View on Parallelism | nick | 2008/02/17 09:15 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/18 04:23 PM |
Berkeley View on Parallelism | nick | 2008/02/18 10:03 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 01:39 AM |
Berkeley View on Parallelism | rcf | 2008/02/19 12:44 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 03:25 PM |
Average programmers | anon | 2008/02/18 12:40 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 08:02 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 08:02 PM |
Berkeley View on Parallelism | Dean Kent | 2008/02/15 08:07 PM |
Berkeley View on Parallelism | Ray | 2008/02/20 03:20 PM |
Berkeley View on Parallelism | JasonB | 2008/02/20 06:11 PM |
Berkeley View on Parallelism | FritzR | 2008/02/24 03:08 PM |
rubyinline, etc. | nordsieck | 2008/02/22 03:38 PM |
rubyinline, etc. | JasonB | 2008/02/23 05:53 AM |
rubyinline, etc. | nordsieck | 2008/03/02 01:40 AM |
rubyinline, etc. | Michael S | 2008/03/02 02:49 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 07:41 AM |
rubyinline, etc. | Michael S | 2008/03/02 08:19 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 08:30 AM |
rubyinline, etc. | JasonB | 2008/03/02 05:26 PM |
rubyinline, etc. | JasonB | 2008/03/02 06:01 PM |
rubyinline, etc. | Anonymous | 2008/03/03 02:11 AM |
rubyinline, etc. | JasonB | 2008/03/03 09:40 AM |
rubyinline, etc. | Foo_ | 2008/03/09 09:59 AM |
rubyinline, etc. | JasonB | 2008/03/10 01:12 AM |
rubyinline, etc. | Gabriele Svelto | 2008/03/10 02:22 AM |
rubyinline, etc. | JasonB | 2008/03/10 04:35 AM |
C++ for beginners | Michael S | 2008/03/10 05:16 AM |
C++ for beginners | JasonB | 2008/03/10 06:35 AM |
C++ | Michael S | 2008/03/10 04:55 AM |
rubyinline, etc. | Linus Torvalds | 2008/03/03 11:35 AM |
rubyinline, etc. | Dean Kent | 2008/03/03 02:35 PM |
rubyinline, etc. | JasonB | 2008/03/03 03:57 PM |
rubyinline, etc. | Dean Kent | 2008/03/03 08:10 PM |
rubyinline, etc. | Michael S | 2008/03/04 01:53 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 07:51 AM |
rubyinline, etc. | Michael S | 2008/03/04 08:29 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 08:53 AM |
rubyinline, etc. | Michael S | 2008/03/04 11:20 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 02:13 PM |
read it. thanks (NT) | Michael S | 2008/03/04 04:31 PM |
efficient HLL's | Patrik Hägglund | 2008/03/04 03:34 PM |
efficient HLL's | Wes Felter | 2008/03/04 09:33 PM |
efficient HLL's | Patrik Hägglund | 2008/03/05 01:23 AM |
efficient HLL's | Michael S | 2008/03/05 02:45 AM |
efficient HLL's | Wilco | 2008/03/05 05:34 PM |
efficient HLL's | Howard Chu | 2008/03/05 07:11 PM |
efficient HLL's | Wilco | 2008/03/06 02:27 PM |
efficient HLL's | anon | 2008/03/05 08:20 AM |
And the links.. | Groo | 2008/02/17 04:28 PM |
And the links.. | Vincent Diepeveen | 2008/02/18 02:33 AM |