|SoC | 1999 | 2000 | 2001 | 2002 | 2003 | 2004 | 2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015|
Lodging / Travel
SoC 2008 Panel Discussion - Summary
The following is a summary of the proceedings held under the panel discussion on SDR Technologies conducted on the second day (5th November) of the tenth International Symposium on SoC, 2008 in Tampere, Finland, also known as The SoC City.
The theme of this year's SoC symposium was Software-Defined and Cognitive Radio. Industry representatives and research scholars were invited from nineteen different countries to present their respective research creations in the field of SDR.
The topic of the panel discussion was "SDR - Is it a software or hardware issue?" The panelists were:
SoC 2008 Panel discussion - panelists and Prof. Jari Nurmi
The panel discussion was held from 1700 hrs up to 1830 hrs and was chaired by Prof. Jari Nurmi of TUT, who guided the discussion to logical conclusions after every round of comments and presented fresh issues on the table when previous issues were dealt with fully. The audience was allowed to ask questions as well as make comments in support of or contrary to the views of the panelists.
1. Is SDR a software or hardware issue?
Dr. van der Perre felt that SDR was not only a hardware or software issue, but also a system issue. She said the percentage contribution of each is arguable in the overall problem, but while there has been obvious progress in hardware, challenges still lie in developing better and more wideband antenna interfaces and powerful software to process the huge bandwidth of information. Therefore, there is always a need for more professionals in software than hardware. She also said that the right environment for research is needed in terms of market demand and availability of tools. There should also be communication and co-operation in this regard across national boundaries between people and between vendors.
Dr. Mitola believes the real issue lies in systems engineering, especially the end-user part or in ways to bring real benefits to the consumers. Even though he agreed to Dr. van der Perre's commentary that although, over the years there has been advancement in hardware, presently, software tools are evolving faster than optimization in hardware, possibly because of the high performance and flexibility needed in hardware. He believed that a systems engineer shoulders the greatest responsibility in implementing a SDR and that he should therefore be a "jack-of-all-trades" since the nature of problems keeps changing.
Dr. Cummings believes SDR was more of a software issue and wished that there would be greater talent to program or develop software for SDR in a reliable and cost effective manner. To attract more talent, he suggested the development of a common software interface tool that ordinary (non-expert) programmers can program on. He also echoed Dr. Mitola's view that every engineer working on any of the SDR blocks should have at least bare-minimum knowledge of the entire design stack in addition to in-depth knowledge of his own block. He said current systems cannot keep up with evolution during their lifetime, which brings the aspect of system engineering for maintainability into the focus.
Prof. Isoaho felt that the issues are usually man-made and lie in software, hardware and systems engineering and it was the responsibility of the respective engineers to first properly isolate the location of the problem (in hardware or software) and then attempt to resolve it. For this, the engineers should be imparted with thorough education about troubleshooting skills and about how to apply these skills at the right place.
2. Where do we begin designing SDR - In hardware or software?
Dr. van der Perre believes it is the architecture that has to be finalized first (both hardware and software) and then we begin with designing the algorithm structure. Once the algorithm is finalized, we measure and optimize its results. For this we need some sort of an automated tuning tool which allows for high-level iterative system exploration. Probably, we would require a separate computer program to do this. However, there are times when we are required to fix the hardware architecture before hand or keep some parameters fixed. In this case, we should start designing from the software since that is the only module we are allowed to be flexible with. Another aspect for deciding on where to start the SDR construction would be to check if we need to tackle any legal and/or social problems in order to secure permission from regulatory bodies for including certain features in the final SDR product.
Dr. Cummings seconded Dr. van der Perre's views and added that the performance measurement that she mentioned should be done for every subsystem within the entire architecture and not just for the whole. Moreover, established layered system design approaches do not fit anymore due to the rapidly increased system complexity. He also said that after we estimate the relative improvement required must get it clear what we do not want to, what we do not have to and what we will not be able to achieve during this entire exercise so as to concentrate on achieving required and feasible results. To do this we need interdisciplinary teams that would decide which goals are both necessary and achievable in the entire SDR architecture. However, currently available industrial system design flows and EDA tools lack a support for these kinds of interdisciplinary requirements.
Dr. Mitola stressed the need to get a clear vision and definition of the problem and target. Clear and simple value propositions, tradeoffs, use-cases, focus, targets and a unified vision augmented by strong co-operation among the team. This includes measurable objectives enabling a quantitative analysis, which makes then a complete system optimization from algorithms to device physics possible.
Prof. Isoaho commented on the importance of getting the technology ready before its application is designed and marketed. Because, once an application is marketed, its demand grows and if the technology is not ready by then, there is tremendous pressure to get the technology ready in as short time as possible, usually, leading to compromises on quality. Before we decide whether to start with hardware or software designs, we should analyze the effect of one on the other. What does it mean in software to design something in hardware? What consequences will this design have? Therefore, there is a need to educate design engineers about the consequences of their work on other fields/blocks of SDR and to cultivate an attitude of caring for not just our work but also its effect on other modules.
3. Need for upgrading the education system along with advancing technology
Dr. van der Perre expressed fears that no new research would take place until we update the fundamental concepts in today's education. One of the problems in finding future system solutions is that most people look at today's problems only and this too, with a limited view of past education. This becomes especially important since time constants for system designs have gotten dramatically smaller making fundamental technology education much more important.
Prof. Isoaho suggested a way for achieving what Dr. van der Perre proposed. He said, we should select such a thesis topic during our education that encompasses multiple disciplines so that an engineer automatically gets to know the impact one field has on the other. More groups lead to more discussion and knowledge is better disseminated by this sort of interdisciplinary study.
A speaker from the audience mentioned one difficulty that hardware and software professionals face when working together is their inherent lack of knowledge about advancements in each other's fields. Another speaker suggested that the way data or information flow is presented is also important. This may have been in reference to Dr. Mitola's presentation the same morning about the importance of a meta-language for SDR purposes.
Dr. Cummings warned that the interdisciplinary aspect should to be tackled with care and that such problems needed to be addressed in a different way. He said that we should develop the meta-language as soon as possible as a common medium for both hardware and software professionals to represent information and make standards more interoperable but that would not be possible without international co-operation.
Transportability of knowledge has a big effect and hence the portability of knowledge is indeed a big challenge.
4. Importance of tools and economics in the design of SDR
Dr. Mitola said that installing flexibility in a device or technology costs money, and therefore, there is a need to have "opportunistic flexibility," that is to offer only those features in a device which people want or are necessary. Probably, market research before the design stage would give us an idea of the mood, likes, dislikes and taste of the general public. Only then should we begin work on incorporating the necessary features in the SDR. After that, it is the job of system engineers to manage complexity arising from opportunistic flexibility.
Dr. van der Perre added that currently there are a lot of heterogeneous software each with its own development tool or complier. Therefore, manual programming of one code spanning multiple tools or compilers is difficult or costly due to the absence of multi-tool talent. It is of little consequence to use software that does not run on a real platform, for example, Matlab programmes cannot run on a processor, but C language programmes can. Her next comment supported what we had already learnt in the tutorial on SDR; she said, reconfigurable processors and application specific instruction set processors (ASIP) were preferred over FPGA because of dearth of talent in programming FPGA boards. She reiterated that it was the responsibility of every individual to come out of his/her specified role and scout for knowledge on the role played by others.
5. Other conclusions from the panel discussion