When I was in grad school at Caltech, I worked on software tools in Alain Martin's asynchronous microprocessor group. The group had actually developed and fabricated a processor before I arrived. To quote their web page (www.cs.caltech.edu/~alains/previous/uP.html):
"Above is the layout of the 1.6 micron version of the Caltech Asynchronous Microprocessor, fabricated in 1989. It is a 16-bit RISC machine with 16 general-purpose registers. Its peak performance is 5 MIPS at 2V drawing 5.2mA of current, 18 MIPS at 5V drawing 45mA, and 26 MIPS at 10V drawing 105mA. The chip was designed by Professor Alain Martin and his group at Caltech. You can read about the chip in Caltech CS Tech Reports CS-TR-89-02 and CS-TR-89-07."
Keep in mind that this is a 1.6 micron process. The chip was later fabricated in gallium arsenide with very few design changes. This is because the chip, being completely data driven, will perform computation as fast as the underlying device physics will allow. There are no "timing issues" as these must all be worked out in high-level design (or the chip won't function at all... race conditions in hardware really suck).
Of course, the neatest geek feature is to pour liquid nitrogen on the chip and watch the instruction rate climb.
Since I left the group, they have also fabricated an asynchronous "digital filter" or simple DSP. Details at http://www.cs.caltech.edu/~lines/filter/filter.htm l
The downside of all this stuff is that the design process is very formalized and arduous. Our group designed by writing parallel programs in a special chip-design notation, then transforming the program by hand and by software into a VLSI gate layout. It was a completely different synthesis method than most designers are used to, so it requires completely new software and designer training to be productive. It's sad, really, because the output chips are so very very nifty.
James Cook ex-"cook@vlsi.caltech.edu" now-"cook@alumni.caltech.edu"
Actually, tolerance of manufacturing variability is one of asynchronous design's strengths. Because each "chunk" of gates only performs its computation when all input data is available, it doesn't matter if a piece of data arrives early or late. The computation is data-driven. It runs as fast as the lines can switch. So it does not have to be "more conservative."
Async designs require more silicon area for simple things, like data lines. Rather than having a single "high = 1, low = 0" data line + a clock line, our group used three wires. First wire high = 1, second wire high = 0, third wire high = downstream component got the data, reset please.
The coolest geek feature of async processors is that if you improve the transistor physics (e.g., put an ice cube or some liquid nitrogen on the processor) the instruction rate increases. Whee!
James Cook ex-"cook@vlsi.caltech.edu" now james@cookmd.com
What an awful thing to happen. Best wishes to Cassie -- I hope she can maintain her strength for the long road ahead.
This may not be the right forum, but I was curious if anyone had experience with the interaction of programming and head trauma. Head trauma can leave you with fairly subtle neurocognitive defects, and I had always assumed that this would interfere with your ability to write code after the fact.
Does anyone have news of programmers who either lost or regained their ability to code after an accident?
A few thoughts on "automatic translation" of web page.
1. Web pages could store more than one translation of their text. You could store the default version in your native language and a translated version for someone else. Envision BODY LANGUAGE=ENGLISH-AMERICAN or LANGUAGE=ESPANOL. This would be even easier if you were generating pages out of a back-end database.
2. You could embed a "meta-language" version of each of your web pages. This would allow you to tune the meta-language page for better translation. BODY LANGUAGE=UN-META-LANGUAGE
3. This process would be facilitated if the meta-language was something that people actually spoke, and was easy to learn (eg, Esperanto, or some other designed language).
4. Where the meta-language was not sufficiently specific (implied meaning, context), you could add markup tags around words to indicate meaning. This could extend Esperanto to have useful features for computer translation.
5. You could even mark up English text to indicate meaning.
6. Failing all the above, if web pages consistently had "summary" or "abstract" sections you could at least focus your translation efforts on that chunk of the page.
Ah, for the return of HTML to content markup and not display.
James Cook James@CookMD.com See http://www.useit.com/ about the bolding.
Slashdot Mirror
When I was in grad school at Caltech, I worked on software tools in Alain Martin's asynchronous microprocessor group. The group had actually developed and fabricated a processor before I arrived. To quote their web page (www.cs.caltech.edu/~alains/previous/uP.html):
m l
"Above is the layout of the 1.6 micron version of the Caltech Asynchronous Microprocessor, fabricated in 1989. It is a 16-bit RISC machine with 16 general-purpose registers. Its peak performance is 5 MIPS at 2V drawing 5.2mA of current, 18 MIPS at 5V drawing 45mA, and 26 MIPS at 10V drawing 105mA. The chip was
designed by Professor Alain Martin and his group at Caltech. You can read about the chip in Caltech CS Tech Reports CS-TR-89-02 and CS-TR-89-07."
Keep in mind that this is a 1.6 micron process. The chip was later fabricated in gallium arsenide with very few design changes. This is because the chip, being completely data driven, will perform computation as fast as the underlying device physics will allow. There are no "timing issues" as these must all be worked out in high-level design (or the chip won't function at all... race conditions in hardware really suck).
Of course, the neatest geek feature is to pour liquid nitrogen on the chip and watch the instruction rate climb.
Since I left the group, they have also fabricated an asynchronous "digital filter" or simple DSP. Details at http://www.cs.caltech.edu/~lines/filter/filter.ht
The downside of all this stuff is that the design process is very formalized and arduous. Our group designed by writing parallel programs in a special chip-design notation, then transforming the program by hand and by software into a VLSI gate layout. It was a completely different synthesis method than most designers are used to, so it requires completely new software and designer training to be productive. It's sad, really, because the output chips are so very very nifty.
James Cook
ex-"cook@vlsi.caltech.edu"
now-"cook@alumni.caltech.edu"
Actually, tolerance of manufacturing variability is one of asynchronous design's strengths. Because each "chunk" of gates only performs its computation when all input data is available, it doesn't matter if a piece of data arrives early or late. The computation is data-driven. It runs as fast as the lines can switch. So it does not have to be "more conservative."
Async designs require more silicon area for simple things, like data lines. Rather than having a single "high = 1, low = 0" data line + a clock line, our group used three wires. First wire high = 1, second wire high = 0, third wire high = downstream component got the data, reset please.
The coolest geek feature of async processors is that if you improve the transistor physics (e.g., put an ice cube or some liquid nitrogen on the processor) the instruction rate increases. Whee!
James Cook
ex-"cook@vlsi.caltech.edu"
now james@cookmd.com
What an awful thing to happen. Best wishes to Cassie -- I hope she can maintain her strength for the long road ahead.
This may not be the right forum, but I was curious if anyone had experience with the interaction of programming and head trauma. Head trauma can leave you with fairly subtle neurocognitive defects, and I had always assumed that this would interfere with your ability to write code after the fact.
Does anyone have news of programmers who either lost or regained their ability to code after an accident?
James Cook
A few thoughts on "automatic translation" of web page.
1. Web pages could store more than one translation of their text. You could store the default version in your native language and a translated version for someone else. Envision BODY LANGUAGE=ENGLISH-AMERICAN or LANGUAGE=ESPANOL. This would be even easier if you were generating pages out of a back-end database.
2. You could embed a "meta-language" version of each of your web pages. This would allow you to tune the meta-language page for better translation. BODY LANGUAGE=UN-META-LANGUAGE
3. This process would be facilitated if the meta-language was something that people actually spoke, and was easy to learn (eg, Esperanto, or some other designed language).
4. Where the meta-language was not sufficiently specific (implied meaning, context), you could add markup tags around words to indicate meaning. This could extend Esperanto to have useful features for computer translation.
5. You could even mark up English text to indicate meaning.
6. Failing all the above, if web pages consistently had "summary" or "abstract" sections you could at least focus your translation efforts on that chunk of the page.
Ah, for the return of HTML to content markup and not display.
James Cook
James@CookMD.com
See http://www.useit.com/ about the bolding.