Processor architectures: Where will we be in 2020?

7/23/2009 10:37 AM EDT

One more thought, Dr. Frantz. There would not be a separate signal processor and FPGA chips anymore. Just a single core in which one section would be DSP, one section would be RF processor, one section would be FPGA. The code will be automatically profiled and implemented on the best suited section.

http://sunnyeves.blogspot.com/

7/23/2009 2:16 PM EDT

Your points about high level language, reuse, programability,etc fit right in with my project. C is pretty well accepted, FPGAs have many embedded memory blocks and object oriented programming has provided reuse in the software world.

The CEngine parser generates memory patterns for a small hardware design that essentially runs the C code.

There are several considerations:

The minimum hardware basically is 4 memory blocks, an adder, a comparator, 3 counters, and 5 multiplexers. Several can be put on a chip so they operate in parallel rather than sharing a single micro.

The application can be written and debugged in a aoftware environment.

The parser has a simulation step so the hardware function can be run without having to design the chip first.

I have running preliminary code and hardware block diagram, but not enough resources to produce a final product.

I think you can get there before 2020.

Thankyou

7/26/2009 9:13 AM EDT

Dear Dr. Frantz
I would like to discuss about Analog and RF
integration.

Hillol Sarkar
hillol.sarkar@gmail.com
ago-inc.com

7/29/2009 4:50 AM EDT

The third dimension will open up the
computer once again ( round two ).

Peter
Individual Bust

7/30/2009 1:54 AM EDT

The concept of interconnected heterogeneous processing elements has been around for quite a while. Several startups worked on the idea but none seem to have been successful. So what gives in 2020?

8/13/2009 11:31 AM EDT

fdgfd

8/14/2009 9:13 AM EDT

Dr. Frantz,
When it comes to ultra-low power applications, such as hearing aids, in some ways the future is now! The custom DSP products available from Sound Design Technologies employ some of the points you have made. High clock speed is not our friend when it comes to low power! So we have adopted a heterogeneous architecture using multiple processors and hardware accelerators while keeping the clock speed under 4 MHz. They are also connected together with a configurable crosspoint switch. A coarse-grained FPGA perhaps? These devices are really specialized audio-centric platforms; it’s the programs running on them that define the function. One program load could define the device as a hearing aid circuits, another program will turn it into an active hearing protection circuit. Finally, due to the size constraints of hearing aids, Sound Design uses 3D packaging to deliver a compact device that contains the audio processor, EEPROM and passives.

10/22/2009 1:44 PM EDT

Gene,

To really do a good job on this, one has to go back to first principles, and rewind the history of computing all the way to the beginning, and then make observations based on the hindsight about decisions that were made along the way and revisit those decisions, basing them on directions that go along with technology trends rather than bucking them.

We are still stuck with the 1950s Von Neumann Architecture (VNA), while all the constraints that made it necessary are gone:

Hardware used to be very expensive, which meant that to make a CPU cost-effective, there had to be a lot of sharing and centralization. Thus we had a CPU, with shared ALU, shared registers and shared muxes, shared memory (between programs): multitasking, shared CPU State machine, shared peripherals and so on.

Since the whole was so expensive and occupied a supermarket-sized room, and required airconditioning and maintenance people going around with shopping carts loaded with tubes to replace the ones that kept burning out, the initial patch panels that were the console of the machine were soon replaced by connections onto which panels that had been patched off-line could be mounted.

Then of course the Von Neumann architecture came along and changed all that, freezing processor design and moving innovation into a completely different dimension - software design. If software is sequencing using the instruction power of some predefined CPU rather than sequencing using the logic power of gates directly, since SEQUENCING is the main function of a processor, software was only really needed because hardware was so inflexible and expensive - both of which are no longer true today, for instance, FPGAs today are very flexible, and even cheap relative to the costs in the 1950s. Also, programmers were cheap in relation to the price of the hardware, which is no longer true in most cases today.

Now if we look at technology trends, we see that it favors simple, regular structures, point-to-point flow through rather than bussed operation, parallel organization, asynchronous rather than synchronous operation, decentralized, or even array-type organization rather than centralized, and so on...if we are to stay with the VNA, we will continue to have our software plagued with bugs, because in some cases we are forcing inherently parallel operations to be done serially or sequentially without realizing the consequences on the accuracy of the implementation, and to be unnaturally coerced to overlay our algorithms' state machines on top of the VNA state machine, often without having any control of its sequencing...such as when we return from system interrupts and such of which the user has no knowledge, so we are polluting the inherent state machines of our algorithms by requiring them to lay over the unreliable state machines of CPUs, making them that much more unpredictable, and software execution buggy.

So we should throw out the CPU - we do not need to have borders defining the extent of a CPU as it is not some huge supermarket full of racks, or even one that needed to fit on the shelves of one aisle. Along with this we should throw out all the band-aids added in computer design over the last few decades - pipelining, branch prediction, translation lookaside buffers, register renaming, cache, and so on - each of them is different, needs testing, and is unsuitable for implementation using modern technology.

There is also an incentive to use base-3 (ternary) logic, so as to need less wires, and to let each wire carry more information...

Anyway, I think that's enough of my putting my foot in my mouth!

9/8/2011 6:03 AM EDT

Hi guys,
Here at Nokia Switzerland we are looking for Sensor Researchers for Switzerland. MEMS, sensor processing, sensor fusion. Good company, good money, good life!
For more details, pls email me at
ext-laura.haufler@nokia.com