International Symposium on System-on-Chip

International Symposium on System-on-Chip 2004

SoC 2004 Panel Discussion Summary

Processors for SoC - What, Why and How?

Chairman:
Dr Mika Kuulusa, Nokia

Participants:
Mr. Steve Leibson, Tensilica
Mr. Stefan Rusu, Intel
Mr. Petri Solanti, CoWare
Mr. Stefano Angioni, StarCore
Dr. Pasi Kolinummi, Nokia
Dr. Jo Ebergen, Sun Microsystems

Introductions

The panel session was initiated by each participant with a short presentation on a subject they considered important under the topic.

Steve Leibson

According to Steve Leibson, many things we know about processors are wrong. People think that processors are too slow when implementing a SoC having many tasks. This is wrong, processors are not too slow. People also think that everything that can be done with software running on a processor should be done with software and then the rest with hardware. A right way goes different. Everything that can be implemented with software should be done and then more processors should be added to exploit parallelism and to reduce clock rate requirements. Processors do not burn more power or energy than RTL, actually they burn less. RTL should not be implemented to create tailored processors and processors need not to be designed, they should be exploited. As a system-level design issue, topologies should be matched to the problem, not vice versa. Tensilica's approach to SoCs is that only necessary processes should be clocked while other parts are powered down.

Stefan Rusu

Moore's law is what SoC is about, says Stefan Rusu. Even if Moore's law is not slowing down, reducing the amount of components on a chip is a good thing to do. The goal in processor design is a system with low operating voltage. Processors are used for instance in mobile phones, in SoCs and in personal digital systems, so processors should need only low power. Nowadays SoCs have large memories and memory access leads to a high power consumption. Essential thing in processor design is to find a vendor with a suitable architecture and to have all necessary supporting software tools for processor design. Having appropriate software tools, the time to market time can be reduced.

Petri Solanti

Petri Solanti has the opinion that the trend of today in firms is that they are designing very complex products. Product costs can be reduced by using same silicon for several products. Therefore, flexibility into silicon is needed. Everything cannot be done in software, but only timing critical parts should be designed to run on hardware accelerators. Adding more processors, for instance ASIC processors and high performance designs, to a platform leads to a hundreds of watts power dissipation. Debugging software tools are also needed for each type of processors and debugging is a problematic thing in processor design. Also the network on the platform needs debuggers.

Stefano Angioni

Stefano Angioni thinks that a future SoC will have high complexity. For instance, already their security sets high requirements. Future processors need to be scalable (with multi core capability), need to have low power dissipation through energy saving schemes and optimized instruction sets. Their architecture needs to be open and development tools standardized. Many things have to be fitted in future needs, like optimal granularity of systems, battery lifetimes (reduce leakage problems), algorithm driven instruction sets and cost driven system definitions. Processor design should be team work with shared investments and have usage of state-of-the-art knowledge, co-operation with universities and research institutes. Systems should be adaptive (tile-based architectures), for instance multiprocessor systems having flexible interconnections (like OCP), they must be fully programmable having no fixed functional limitations and having high level of abstraction in system simulation tools and high level programming languages.

Pasi Kolinummi

According to Pasi Kolinummi processors for a SoC need to be simple because complex control is difficult to implement with state machine. Processors need to be flexible as well. Fixed algorithms can be implemented with hardware, but they might be outdated when a new standard comes out. Also time-to-market is an important issue, as well as the openness. How are the demands achieved? CPUs should be developed separately from SoCs because SoC developers might want to concentrate on their system design instead of the CPU-development. CPUs should also have standard interfaces and full maintenance.

Jo Ebergen

A lot of overall costs goes to the wiring, states Jo Ebergen. Wires also cause delay (caused by latency and cycle time), consumes energy and needs area. 20 years ago most of the energy was used by transistors. Nowadays cost function could be reduced by increasing locality and by putting the data as close to its computation location as possible. Most IP blocks are clocked, but Jo Ebergen prefers non clocked. GALS (Globally Asynchronous, Locally Synchronous) approach could be replaced with GALA (Globally Asynchronous, Locally Asynchronous) approach, which would be totally clockless. The replacement could happen in a couple of years.

Discussion

The discussion itself consisted of answering the questions of the chairman and audience and commenting the claims of the participants.

What kind of an approach is needed for processor for SoC design?

Stefano Angioni prefers a multiprocessor approach for SoCs. Therefore ASICs and HW blocks (with low power consumption) are needed. Steve Leibson thinks, that that kind of an approach is wrong. Many CPUs are not the answer, if they are controlled from just one place. Everything cannot be put on one standard because the standard might change next year. It should be customers' choice to select what properties they want. The customers should have the freedom to add or remove what they want. For instance, general purpose processors' single instructions could be removed or added, but an instruction set in its entirety cannot be changed. Also Stefan Rusu pointed out, that flexibility is needed and it is achieved by programmability in system design. Asynchronous approach is still a challenge but it can be done. Some problems exist, mostly caused by lack of CAD tools (which doesn't exist yet at all). When having CAD tools for asynchronous design, there will be better chances for asynchronous designs to succeed. Also lack of education is a big obstacle considering asynchronous design.

Asynchronous systems

Jo Ebergen has a strong opinion about asynchronous design. He says, that people tend to think that testing an asynchronous design is very difficult and complex. But if one knows what he or she is doing, testing should not be any big problem. It is just the case of lack of education. If a clock is removed, everything is going to happen at the same time. The problem is the same than in parallel programming, it is not known where all the bits are and when. Therefore, a determined timing analysis cannot be achieved, only probabilistic, which is hard to scale, states Stefan Rusu. If a design is asynchronous, all units will run in their maximum speed because clock cycle is not a limiting factor. A key to asynchronous design is handshaking. If obstacles like testing and verification can be beaten, an asynchronous mainstream is just about to come. Many people are oriented to think in a synchronous way and the question is, why would they start thinking in an asynchronous way? The answer is to have more education and more knowledge about asynchronous design. There are no good books, but there are asynchronous conferences and workshops instead. Also one good asynchronous success story would help the situation. An asynchronous ARM core is coming, it will have very low power dissipation, lower than synchronous cores have. If it works, it could be a sufficient success story to start a bigger asynchronous design trend.

Open source CPUs

Open source CPUs have a lot of possibilities. Some open source CPUs already exists, for instance 8051 and ARM clone, mentioned Steve Leibson. Open source CPUs have academic importance, but commercially they are lacking official technical support and maintenance.