Asynchronous speed variation -> The key is to not rely on it. With the i21 the speed variation was less than 5%. Not enough that you would generally notice the performance difference between two units. Certain I/O related portions of the design were implemented synchronously.
tools/languages -> Chuck relied on OKAD which runs under DOS completely. iTv Corp. (who employed Chuck for the i21) had the usual collection of standard ASIC tools and environment available to back-up/analyze the OKAD based design as well as doing other designs.
prototyping in the Xilinx Virtex FPGAs -> Except for a few drawings on paper, I have only seen Chuck use the OKAD layout in the design process. After the i21, iTv Corp. designed a new processor in the same architectural theme as the i21, but completely new in a traditional design flow. It was prototyped using Xilinx Virtex FPGAs and had very good performance compared to a similar RISC processor.
COT -> Don't know what Chuck is doing currently, but in the past everything was built on his own library model. Sadly, all libraries (vendor supplied or not) have to be validated in the fab.
Production -> Unfortunately the Internet appliance market has not grown as big or as fast as we had hoped it would.
Easy integration -> Yes, if you know how to integrate any other hard core in your design. I set-up a process and design flow to do this with the i21, but ended up not using it.
I think that Giant Hairy Spider makes some very valid comments about this design.
There seems to be a lack of overall architecture (interprocessor & memory), the $1 packaged cost estimate is absurb (how many memory pins is he proposing?), and the performance does seem to be bogoMIPS. With little documentation though I can't really evaluate these things.
Having been the iTv Corp. VP of Engineering where Chuck worked for many years I can speak with some authority on his comments about the underlying technology.
A MISC architecture does has different performance characteristics than most common processors. While in some cases this results in requiring more short instructions I have found that the instruction efficiency is significantly higher than expected and usually code size (in bits) and execution time (in seconds) is significantly better than conventional architectures.
Also to be remembered is that a variety of MISC designs can be created. For example, we made a MISC style processor with a multiply instruction and significantly improved arithmetic capability that we were able to implement an efficient C compiler in. We profiled the cache efficiency of this design and found it to be significantly more efficient than conventional architectures. These tests were performed running assembly and C code (didn't test Forth).
Yes, the base kernel code is pretty small in any system (OS, GUI, network, etc.), but I can say that the code density with all of MISC-style designs that I have worked is very respectful. The value of this improved code density is of course only one design characteristic that the designer needs to consider.
Slashdot Mirror
Asynchronous speed variation -> The key is to not rely on it. With the i21 the speed variation was less than 5%. Not enough that you would generally notice the performance difference between two units. Certain I/O related portions of the design were implemented synchronously.
tools/languages -> Chuck relied on OKAD which runs under DOS completely. iTv Corp. (who employed Chuck for the i21) had the usual collection of standard ASIC tools and environment available to back-up/analyze the OKAD based design as well as doing other designs.
prototyping in the Xilinx Virtex FPGAs -> Except for a few drawings on paper, I have only seen Chuck use the OKAD layout in the design process. After the i21, iTv Corp. designed a new processor in the same architectural theme as the i21, but completely new in a traditional design flow. It was prototyped using Xilinx Virtex FPGAs and had very good performance compared to a similar RISC processor.
COT -> Don't know what Chuck is doing currently, but in the past everything was built on his own library model. Sadly, all libraries (vendor supplied or not) have to be validated in the fab.
Production -> Unfortunately the Internet appliance market has not grown as big or as fast as we had hoped it would.
Easy integration -> Yes, if you know how to integrate any other hard core in your design. I set-up a process and design flow to do this with the i21, but ended up not using it.
I think that Giant Hairy Spider makes some very valid comments about this design.
There seems to be a lack of overall architecture (interprocessor & memory), the $1 packaged cost estimate is absurb (how many memory pins is he proposing?), and the performance does seem to be bogoMIPS. With little documentation though I can't really evaluate these things.
Having been the iTv Corp. VP of Engineering where Chuck worked for many years I can speak with some authority on his comments about the underlying technology.
A MISC architecture does has different performance characteristics than most common processors. While in some cases this results in requiring more short instructions I have found that the instruction efficiency is significantly higher than expected and usually code size (in bits) and execution time (in seconds) is significantly better than conventional architectures.
Also to be remembered is that a variety of MISC designs can be created. For example, we made a MISC style processor with a multiply instruction and significantly improved arithmetic capability that we were able to implement an efficient C compiler in. We profiled the cache efficiency of this design and found it to be significantly more efficient than conventional architectures. These tests were performed running assembly and C code (didn't test Forth).
Yes, the base kernel code is pretty small in any system (OS, GUI, network, etc.), but I can say that the code density with all of MISC-style designs that I have worked is very respectful. The value of this improved code density is of course only one design characteristic that the designer needs to consider.