I have come to the conclusion that too many of us have no clue where we are going with technology. Rather, we are just busily moving forward and don't know if we are even moving in the right direction. It would seem that with our extensive experience in traveling we would understand a basic concept " to travel to a distant place requires two points:
Where I am
Where I want to end up at
The same goes for technology " we need to know where we are going to move in the right direction. So, I have challenged several of our senior technologists to think about what the state of the art will be in the year 2020. You might say that we need to have 20/20 vision for the year 2020. I have invited a number of technologists to provide their point of view (POV) of what the state of the art in IC technology will be in the year 2020, and I'm interested to hear what you have to say on the topic. But, since this is my blog, I will have the first and last word on what the year 2020 will hold for us.
So, here are my first thoughts on the topic.
Processing elements will be single clock domains. After many years of assuming that Moore's law would give us faster and faster clock speeds, we have finally concluded that clock speed is no longer our friend. In fact, we should have noted that 15 years ago, but as we move forward, processing elements will be of the size that the CPU can communicate with all of its resources in one clock cycle.
Systems will be made up of multiple processing elements. Integrated systems will be made up of many heterogeneous processing elements, each being a "single clock domain" processor.
The processing elements will be arranged in a similar style as FPGAs today.
We will take advantage of the third dimension. Integration using stacked die techniques (SIP) will be just as common as fully integrated SoC.
All will be programmed with a high-level language. The development environment will have the ability to take into account all of the resources in the system. That is the microprocessors, DSPs, accelerators, peripherals, analog signal processors, analog peripherals, RF and other things I have forgotten about.
IC designs will consist of smaller teams (5 to 10 designers) taking a shorter amount of time (6 to 12 months) to do the hardware design. Reuse will be the norm. While I am at it, let me explain that there are two definitions of "Reuse":
1. I'll do such a good job on my design that everyone after me will use it.
2. I don't have time to reinvent the wheel, so I need to find something that is close enough to what I need to meet the schedule.
Unfortunately we use the first definition more than the second. Small design teams with short schedules will require us to use the latter definition. And, yes, there are companies already adopting this concept of reuse.
The bulk of the innovation will be in the software on top of the hardware.
Hardware will become part of the platform on which innovative designers will develop their ideas.
So, this is a sketch of how I see 2020. After a couple of POV papers from others at TI, I will come back with a conclusion. My colleagues will dive into topics such as programmability, tools and SoCs in the next few blogs. If you would like to share your view of 2020 with me, please comment or send me a private note.
Gene Frantzis TI Principal Fellow, Futurist and Business Development Manager, DSP.
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
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!
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.
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.
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.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.