Regarding prototype construction, a chip to chip interface standard would allow mating various chips, e.g. a processor chip to a chip with interfaces. A mechanical assembly would be used to hold the chips together in the mated position, obviating the need for a PCB for interconnecting components. However, a PCB may be needed for mounting external connectors, e.g. a USB connector.
In some cases, a more expensive processor chip, or several of them, could run the Java embedded program in real time, allow user access for debugging, logging events, etc. and provide a display of what the program was doing. This would facilitate prototype construction and checkout.
Hardware software codesign for demanding applications will often require an efficient memory hierarchy.
In many cases, an effective codesign can be implemented as a function added to the arithmetic unit. With this approach, the load string and store string instructions could be used to move operands/results to/from the function added to the arithmetic unit. Often, more than one operand/result could be packed into a string, not necessarily on byte boundaries. The strings could be 1 to 8 bytes in length. This may result in needing less memory.
The strategy of using the Java programming language as the framework for an ASIC has the advantage that much of the complexity resides in the Java program that controls the ASIC. In many cases, the function added to an arithmetic unit would only need to be of modest complexity, yet still provide enough speedup of time critical functions. When this strategy is appropriate, and given a Java computer design, the design required is mainly that of implementing the added function(s).
Note that as clock rates increase, functions that formerly needed a hardware implementation to be fast enough, can be implemented in software.
With a variety of chips using a chip to chip interface standard, many embedded systems could be assembled much like a tinker toy is assembled. Back to Computer Architecture Page