|SoC | 1999 | 2000 | 2001 | 2002 | 2003 | 2004 | 2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015|
Lodging / Travel
Panel Discussion Summary
Chairman: Prof. Jari Nurmi, Tampere University of Technology Participants: Prof. Ahmed Jerraya, TIMA Laboratory Prof. Rainer Leupers, RWTH Aachen Prof. Diederik Verkest, IMEC Dr. Satnam Singh, Xilinx Mr. Günter Zeisel, PACT XPP Technologies
The panel session was initiated by each participant with a short presentation on a subject they considered important under the topic.
Diederik Verkest stated that existing platforms are hard to scale and hard to compile. Therefore, more regular, configurable, and simple platforms are required. Verkest presented the idea that the future platforms will be composed of a regular network of configurable tiles clocked at low frequency. The proposed network will contain a processing element, a memory block, some communication logic and logic dedicated to system level tasks including power management, test, and reconfiguration. In addition, the life cycle of the chip will be extended using remote reconfiguration and incremental software techniques. Verkest emphasized that a platform is both a hardware and a software system, together with the adequate programming environment. He also stated that there is a need for architecture exploration in which different solutions are evaluated at the level of high-level languages. The problem is that design exploration is heavily dependent on the application domain and the current tools and methodologies are not covering this level well enough.
Finally, Verkest stated that methods and skilled engineers are more important in the design process than tools. The first priority for the SoC designing is to fill cultural gabs between different engineering communities including software, hardware, communications, system design etc.
Ahmed Jerraya introduced parameters for the SoC design flow. According to Jerraya, the design could be characterized with the following aspects: application domain, added value, and usage. The application domain includes two parameters: scope (refinement, co-simulation, abstraction level) and underlying model (multi-tasking, multi-processing). Design teams need to choose the domain to target to and they have to find the scope, i.e., what they are planning to do in the application domain. They also need to come up with methods how to implement their designs. Added value class, in turn, contains design flow and flexibility. The design flow can be automatic, manual, interactive etc. and the flexibility of a design contains communication protocols, processors, interfaces and memory structures. Usage of the design sets some constraints and requirements to the design. The inputs and outputs have to fulfill the specifications and the user interface has to be easy to apply. Also the employed algorithms set some constraints for the design.
Lastly Jerraya presented an example from a real case considering design flows used in different teams inside the same company during the year 2000. He discovered that these design flows were completely heterogeneous and were highly dependent on the software tools each team was using. Jerraya concluded that none of the current design flows are fully automatic and none of the flows can be used to go through the design flow from up to bottom.
Satnam Singh particularly stressed the importance of verification. Research in module verification has been done, but at system level there are no solutions yet. The key point is how to verify the interaction between components. According to Singh, the main thing that is needed for the design flow for SoCs is a proper design verification environment that can cover the entire design consisting of several modules, e.g., processor, reconfigurable hardware, memory. Besides module level verification, verification implies communication verification and safety property checking. Verification for supporting IP in reconfigurable platforms, SW verification, and language/HDL verification support are fundamental for the design of reconfigurable platforms.
Rainer Leupers started his presentation by stating that there is a large gap between the current silicon technology and productivity of the current design tools. Current design methods are not adequate efficient to manage the system complexity of large systems. As a consequence, new design methodologies are required. System level design methods will close the gap between the productivity of a designer and technology development. System level design involves a trade off between efficiency and flexibility.
Leupers determined SoC design flow constraints being flexibility, efficiency and IP reuse. This can be fulfilled with heterogeneous HW/SW systems, with increasing amount of ASIPs and memory as well as with platform-based designs. The corresponding design flow would then go from functional model to abstract architecture, which would then be realized on a virtual platform prototype. The prototype would then be debugged to obtain profiling information for following design iterations. This kind of design flow puts some new EDA tool challenges including system level simulation speed, system level debugging and component observability. Leupers concluded that the design exploration can be done at two levels: system architecture and processor architecture.
At first, Günter Zeisel shortly admitted that he had noticed same kind of problems in SoC design than all the other speakers. He said that, in PACT XPP Technologies, they have done their own design flow and tools, because they did not succeed in using standard tools available on the markets. According to Zeisel, the complexity of SoC designs is increasing and the number of potential customers is decreasing. He stated that customers want personalized chips. This makes the design costs and the mask set costs to increase. While the manufacturing costs, including the masks, are growing steadily, the design costs grow at an uncontrollably high rate.
As a possible answer to these problems, he proposed new SoC standard called ReSoc (Reconfigurable SoC). ReSoC platform is a generic development platform and ReSoC would consist of data arrays of configurable hardware. ReSoC will help controlling costs including manufacturing costs, mask fabrication costs, design costs, etc. The key parameter in ReSoC is time-to-market, which importance will increase in the future. To handle shorter times-to-market, ReSoC requires soft (=reconfigurable) IP's and new design tools. ReSoC design methodology is based on algorithm libraries, which are required to be ready for customers. Zeisel concluded that in future the reconfigurable chip would be more “software on a chip” than system on chip.
The discussion itself consisted of answering the questions from the audience and commenting the claims of the participants.
Multiprocessor systems on SoC
The panelists were asked if the aim of System-on-Chip (SoC) designs is to speed-up the execution of a single application or have multiple applications operating in parallel on the same chip, i.e., multiprocessors on SoCs. This question was mainly answered by Ahmed Jerraya, who claimed that multiprocessor systems are not that difficult to design. He also predicted that in the future, processors will be considered as basic building blocks of SoCs and considered processors to be tomorrow’s of transistors. This claim was quite strongly opposed by Stamatis Vassiliadis from the audience by claiming that because not many current multiprocessor systems have succeeded, how could they succeed in SoCs. He also claimed that because it is already difficult to utilize only a few processors on the same platform, so how could 10’s or even 100’s of processors be utilized efficiently. And, who would make the software for them. Jerraya claimed that previous multiprocessor systems did not succeed because they were designed to be general-purpose systems. He said that current multiprocessor systems do not need to be general-purpose. Instead, each processor would just perform a single application, which would make the management of the system easier.
Platform based design
The audience wondered if platform-based design is the best approach for SoC design. The general opinion between the panelists was that platform-based design is very attractive method being extremely cost-efficient, being able to manage the complexity of the designs, and allowing reusability of the platform. However, it was stated that platform-based designs should be application-specific, i.e., architecture exploration is needed in order to fine-tune the platform in order to obtain an efficient design. Thus, a successful general-purpose platform is not possible; the platform needs to be tailored for the application.
The problems in the verification of software and hardware occupied the audience. One comment was that verification of both software and hardware is easy when they are verified separately. Problems occur when they need to be verified together. However, the general opinion was that the verification of both software and hardware is difficult. A remark was made that the difficulty depends on the level of verification. It was claimed that the platform, i.e., the hardware, needs to be verified at first. After the platform has been verified the software running on the platform can be verified. Comparing hardware and software verification, it was stated that there is some evidence of successful hardware verification but with software the mathematical verification is impossible. It was declared that critical parts of the software can be verified accurately but full coverage cannot be reached.
Discussion of verification problems brought up the issue of new problems introduced by adoption of new technologies including smaller line widths, operation voltages etc. Due to these problems, new, more accurate models are needed, for example on leakage power consumption, which is not taken seriously into account in current models. Furthermore, it was stressed that currently there is not enough knowledge to develop more accurate models. The common opinion between the panelists was that current EDA tool vendors will not develop tools for system level design of SoCs due to high development costs and small demand for the tools. Panelists saw that each design team will develop their own system level design tools. SystemC was seen as one promising approach to be used for system level design and to increase the abstraction level. However, currently SystemC is not ready for production.
Commercial future of SoCs
The audience inquired what is the commercial future of SoCs. Panelists claimed that platform-based design method is very tempting; it was seen as a sophisticated way to mix hardware and software. However, more flexibility has to be embedded in current platforms. Reconfigurable platform was seen as one possible solution to fulfill the flexibility requirements. Furthermore, platforms were considered especially useful to implement new products. In the next design iteration, more careful application-specific integrated circuit (ASIC) with better performance and lower cost can be designed. Thus, ASIC are not going to vanish; there are always markets for them. Instead, general-purpose microprocessors were seen to be doomed due to their poor performance and high power consumption. Once application-specific processors can be implemented efficiently, the traditional microprocessors will disappear.
Education of SoC engineers
It was also discussed, how to teach good SoC engineers. The common understanding was that students need to be taught to cover many different areas including hardware and software aspects and also their integration. The most important issue is to teach students to work in groups of people from different fields. Close contacts to industrial companies were also stressed. Furthermore, more practical experience is needed, which can be obtained through practical laboratory exercises.