FONT SIZE : AAA
Selecting the most suitable technique to implement an embedded system that fulfills all the requirements of a given application may not be a trivial issue since designers need to consider many different interrelated factors. Among the most important ones are cost, performance, energy consump- tion, available resources (i.e., computing resources, sizes of different types of memories, or the number and type of inputs and outputs available), reliabil- ity and fault tolerance, or availability. Even if these are most likely the factors with higher impact on design decision, many others may also be significant in certain applications: I/O signal compatibility, noise immunity (which is strongly application dependent), harsh environmental operating conditions (such as extreme temperature or humidity), tolerance to radiations, physical size restrictions, special packaging needs, availability of the main comput- ing device and/or of companion devices (specific power supplies, external crystal oscillators, specific interfa
The integration capacity is at the risk of Moore’s law starting to suffer from some fatigue. As a consequence, the continuous growth of resource integra- tion over the years is slowing down compared to what has been happen- ing over the last few decades. Transistor sizes are not being reduced at the same pace as higher computing performance is being demanded, so larger circuits are required. Larger circuits negatively affect manufacturing yield and are negatively affected by process variation (e.g., causing more differ- ences to exist between the fastest and slowest circuits coming out from the same manufacturing run, or even having different parts of the same circuit achieving different maximum operating frequencies). This fact, combined with the use of lower power supply voltages, also decreases fault tolerance, which therefore needs to be mitigated by using complex design techniques and contributes to a reduction in system lifetime.
ces, etc.), existence of second sources of manufacturing, time to product deprecation, intellectual property (IP) pro- tection, and so forth.
For simple embedded systems, small microcontrollers and small FPGAs are the main market players. As the complexity of the applications to be supported by the embedded system grows, larger FPGAs have different opponents, such as digital signal processing (DSP) processors, multicore processors, general-purpose graphic processing units (GPGPUs), and ASICs. In order to place the benefits and drawbacks of FPGAs within this contest, qualitative and quantitative comparisons between all these technologies are presented in the next sections for readers to have sound decision criteria to help determine what are the most appropriate technologies and solutions for a given application.
The continuous improvements in silicon semiconductor fabrication tech- nologies (mainly resulting in reductions of both transistor size and power supply voltage) implicitly allow lower energy consumption and higher per- formance to be achieved. Transistor size reduction also opens the door for higher integration levels, which although undoubtedly being a big advan- tage for designers, give rise to some serious threats regarding, for instance, circuit reliability, manufacturing yield (i.e., the percentage of fabricated parts that work correctly), or noise immunity.
Power consumption is also becoming one of the main problems faced by designers, not only because of consumption itself but also because of the need for dissipating the resulting heat produced in silicon (especially with mod- ern 3D stacking technologies, where different silicon dies are decked, reduc- ing the dissipation area while increasing the number of transistors—and, therefore, the power consumption—per volume unit). Circuits at the edge of the technology are rapidly approaching the limits in this regard, which are estimated to be around 90 W/cm 2 , according to the challenges reported for reconfigurable computing by the High Performance and Embedded Architectures and Computation Network of Excellence (www.hipeac.net).
Maximum operating frequency seems to be saturated in practice. A limit of a few GHz for clock frequencies has been reached in regular CMOS tech- nologies with the smallest transistor sizes, no matter the efforts of circuit designers to produce faster circuits, for instance, by heavily pipelining their designs to reduce propagation delay times of logic signals between flip-flops (the design factor that, apart from the technology itself, limits operating frequency).
Is the coming situation that critical? Probably not. These problems have been anticipated by experts in industry and academia, and dif- ferent approaches are emerging to handle most of the issues of concern. For instance, low-power design techniques are reaching limits that were not imaginable 10–15 years ago, using dynamic voltage scaling or power gating and taking advantage of enhancements in transistor threshold volt- ages (e.g., thanks to multithreshold transistors). Anyway, the demand for higher computing power with less energy consumption is still there. Mobile devices have a tremendous, ever-increasing penetration in all aspects of our daily lives, and the push of all these systems is much higher than what tech- nology, alone, can handle.
Is there any possibility to face these challenges? Yes, using parallelism. Computer architectures based on single-core processors are no longer pro- viding better performance. Different smart uses of parallel processing are leading the main trends in HPC, as can be seen in the discussion by Kaeli and Akodes (2011). Actually, strictly speaking, taking the most advantage of parallelism does not just mean achieving the highest possible performance using almost unlimited computing resources but also achieving the best possible performance–resources and performance–energy trade-offs. This is the goal in the area of embedded systems, where resources and the energy budget are limited.
In this context, hardware-based systems and, in particular, configurable devices are opening new ways for designing efficient embedded systems. Efficiency may be roughly measured by the ratio of the number of operations per unit of energy consumed, for example, in MFlops/mW (millions of floating- point operations per second per milliwatt). Many experiments have shown that improvements of two orders of magnitude may be achieved by replac- ing single processors with hardware computing.
FPGAs have an increasingly significant role when dealing with energy con- sumption. Sometime ago, the discussion regarding consumption would have been centered on power consumption, but the shift toward considering also energy as a major key element comes from the fact that the concern on energy availability is becoming a global issue. Initially, it just affected porta- ble devices or, in a more general sense, battery-operated devices with limited usability because of the need of recharging or replacing batteries.
However, the issue of energy usage in any computing system is much more widespread. The most opposite case to restricted-energy, restricted-resource tiny computing devices might be that of huge supercomputing centers (such as for cloud-computing service providers). The concern on the “electricity bill” of these companies is higher than ever. To this respect, although FPGAs cannot be considered the key players in this area, they are presently having a growing penetration. As a proof of that, it can be noticed that there are ser- vices (including some any of us could be using daily, such as web searchers or social network applications) currently being served by systems including thousands of FPGAs instead of thousands of microprocessors.
Why is this happening? Things have changed in recent years, as tech- nologies and classical computing architectures are considered to be mature enough. There are some facts (slowly) triggering a shift from software-based to hardware-based computing. As discussed in Section 1.3.1, fabrication technologies are limited in the maximum achievable clock speed, so no more computing performance can be obtained from this side. Also, single- core microprocessor architectures have limited room for enhancement. Even considering complex cache or deep pipelined structures, longer data size operators, or other advanced features one might think of, there are not much chances for significant improvements.
There is no way of significantly improving performance in a computing system other than achieving higher levels of parallelism. To this respect, the trend in software-based computing is to move from single-core architectures to multi- or many-core approaches. By just taking into account that hardware- based computing structures (and, more specifically, FPGAs) are intrinsically parallel, it means that FPGAs have better chances than software-based comput- ing solutions to provide improved computing performance (Jones et al. 2010).
In addition, if the energy issue is included in the equation, it is clear that reducing the time required to perform a given computation helps in reduc- ing the total energy consumption associated with it (moreover, considering that, in most applications, dynamic power consumption is dominant over static power consumption*). Thus, a certain device with higher power con- sumption than an opponent device may require less energy to complete a computing task if the acceleration it provides with respect to the opponent is sufficiently high. This is the case with FPGAs, where the computing fab- ric can be tailored to exploit the best achievable parallelism for a given task (or set of tasks), having in mind both acceleration and energy consumption features.
The graph in Figure 1.2 qualitatively shows the performance and flexibility offered by the different software- and hardware-based architectures suit- able for embedded system design. Flexibility is somewhat related to the ease of use of a system and its possibilities to be adapted to changes in specifications.
FIGURE 1.2
Performance versus flexibility of different technologies for embedded system design.
* Even though, since technologies with higher integration levels and higher resource availability suffer more from static power consumption, this factor needs to be taken into consideration.
As can be seen from Figure 1.2, the highest performance is achieved by ASICs and GPGPUs. The lack of flexibility of ASICs is compensated by their very high energy efficiency. In contrast, although GPGPUs are excellent (if not the best) performant software-based computing devices, they are highly power consuming. Multicore technologies are close to GPGPUs in perfor- mance, and, in some cases, their inherent parallelism matches better the one required by the target application. While GPGPUs exploit data parallelism more efficiently, multicore systems are best suited to multitask parallelism. Known drawbacks of GPGPUs and many multicore systems include the need for relying on a host system and limited flexibility with respect to I/O avail- ability. At the high end of flexibility, DSP processors offer better performance than single general-purpose microprocessors or microcontrollers because of their specialization in signal processing. This, of course, is closely related to the amount of signal processing required by the target application.
FPGAs are represented as less flexible than specialized and general- purpose processors. This comes from the fact that software-based solu- tions are in principle more flexible than hardware-based ones. However, there exist FPGAs that can be reconfigured during operation, which may ideally be regarded to be as flexible as software-based platforms since reconfiguring an FPGA essentially means writing new values in its config- uration memory. This is very similar to modifying a program in software approaches, which essentially means writing the new code in program memory. Therefore, FPGAs can be considered in between ASICs and software-based systems, in the sense that they have hardware-equivalent speeds with software-equivalent flexibility. Shuai et al. (2008) provide a good discussion on FPGAs and GPUs.
Figure 1.3 shows a comparative diagram of the aforementioned approaches. The legend shows the axes for flexibility, power efficiency, performance, unit cost, and design cost (complexity).
The cost associated with design complexity is important for embedded devices because the number of systems to be produced may not be too large. Since in the area of embedded systems, significant customization and design effort are needed for every design, additional knowledge is demanded as com- plexity grows. Hence, complex systems might require a lot of design exper- tise, which is not always available in small- or medium-sized design offices and labs. Design techniques and tools are therefore very important in embed- ded system design. They are briefly analyzed in Section 1.3.4. Moreover, tools related to FPGA-based design are analyzed in detail in Chapter 6.
Some design techniques and tools (e.g., those related to PCB design and manufacturing) are of general applicability to all technologies mentioned so far. According to the complexity of the design, these might include tech- niques and tools for electromagnetic protection and emission mitigation,
FIGURE 1.3 Comparative features of ASICs, FPGAs, general-purpose processors and microcontrollers, multicore processors, and GPGPUs. Notes: Outer (further away from the center) is better. ASIC cost applies to large enough production
thermal analysis, signal integrity tests, and simulation. Some other techniques and tools are specific to the particular technology used (or to some but not all of them), as discussed in the following sections.
General-purpose processors and microcontrollers are the best (and some- times the only practically viable) solution for simple embedded systems with low computing power requirements. They just require designers’ knowledge in programming and debugging simple programs, mostly (if not totally) written in high-level languages. Emulators and debuggers help in validating the developed programs, contributing to a fast design cycle.
In the simplest cases, no operating system (OS) is required; the processor just runs the application program(s), resulting in the so-called bare-metal system. As complexity grows, applications might require complex use of interrupts or other processor features, therefore making it necessary to use an OS as a supporting layer for running multiple tasks concurrently. In this case, dead times of a task can be used to run other tasks, giving some impres- sion of parallelism (although actually it is just concurrency). In very specific cases, system requirements might demand the use of assembly code in order to accelerate some critical functions.
In brief, off-the-shelf simple and cheap processors must be used whenever they are powerful enough to comply with the requirements of simple target applications. Other platforms should be considered only if they provide a significant added value. For instance, it may be worth using FPGAs to solve a simple application if, in addition, they implement glue logic and avoid the need for populating PCBs with annoying discrete devices required just for interconnection or interfacing purposes.
Because of their specific architectures, DSP processors are more suitable than general-purpose processors or microcontrollers for many applications above a certain complexity level, where they provide better overall characteristics when jointly considering performance, cost, and power consumption. For instance, DSP-based platforms can solve some problems by working at lower clock frequencies than general-purpose processors would require (therefore reducing energy consumption) or achieving higher throughput (if they work at the same clock frequency).
Specific DSP features are intended to increase program execution efficiency. These include hardware-controlled loops, specialized addressing modes (e.g., bit reverse, which dramatically reduces execution times in fast Fourier transforms), multiply–accumulate (MAC) units (widely used in many signal processing algorithms), multiple memory banks for parallel access to data, direct memory access (DMA) schemes for automated fast I/O, and the ability to execute some instructions in a single clock cycle. There are complex issues (both hardware and software) related to the efficient use of these features. For instance, real parallel operation of functional units can be achieved by using very long instruction word (VLIW) architectures. VLIW systems are capable of determining (at compile time) whether several functional units can be used simultaneously (i.e., if at a given point of program execution there are instructions requiring different functional units to carry out operations with different data that are already available). This implies the ability of the hard- ware to simultaneously access several memories and fetch several operands or coefficients, which are simultaneously sent to several functional units. In this way, by using multiple MAC units, it may be possible, for instance, to compute several stages of a filter in just one clock cycle.
Advantage can only be taken from DSP processors with VLIW architectures with deep knowledge of the architecture and carefully developing assembly code for critical tasks. Otherwise, they may be underused, and performance could even be worse than when using more standard architectures.
For those embedded systems where the performance of off-the-shelf DSP processors complies with the requirements of the application and that of general-purpose processors or microcontrollers does not, the former are in general the best implementation platform. However, like in the case of general-purpose processors and microcontrollers, except for some devices tailored for specific applications, it is not unusual that external acquisition circuitry is required (e.g., for adaptation to specific I/O needs), which may justify the use of FPGAs instead of DSP processors.
Although DSP processors exploit parallelism at functional module level, it might be the case that the maximum performance they offer is not enough for a given application. In this case, real parallel platforms need to be used. Software-based parallel solutions (multicore processors and GPGPUs) are dis- cussed in Section 1.3.4.3 and hardware-based ones (FPGAs) in Section 1.3.4.4.
The internal architectures of multicore processors and GPGPUs are designed to match task parallelism and data parallelism, respectively. Multicore sys- tems can very efficiently execute multiple, relatively independent tasks, which are distributed among a network of processing cores, each of them solving either a different task or some concurrent tasks. GPGPUs contain a large number of computing elements executing threads that, in a simplistic manner, may be considered as relatively (but not fully) independent execu- tions of the same code over different pieces of data.
Multicore devices can be programmed using conventional high-level languages (such as C or C++), just taking into consideration that differ- ent portions of the code (i.e., different tasks) are to be assigned to different processors. The main issues regarding the design with these platforms are related to the need for synchronization and data transfer among tasks, which are usually addressed by using techniques such as semaphores or barriers, when the cores share the same memory, or with message passing through interconnection networks, when each core has its own memory. These tech- niques are quite complex to implement (in particular for shared memory systems) and also require detailed, complex debugging. For systems with hard real-time constraints, ensuring the execution of multiple tasks within the target deadlines becomes very challenging, although some networking topologies and resource management techniques can help in addressing, to a certain extent, the predictability problem (not easily, though).
GPGPUs operate as accelerators of (multi)processor cores (hosts). The host runs a sequential program that, at some point in the execution process, launches a kernel consisting of multiple threads to be run in the companion GPGPU. These threads are organized in groups, such that all threads within the same group share data among them, whereas groups are considered to be independent from each other. This allows groups to be executed in paral- lel according to the execution units available within the GPGPU, resulting in the so-called virtual scalability. Thread grouping is not trivial, and the success of a heavily accelerated algorithm depends on groups efficiently per- forming memory accesses. Otherwise, kernels may execute correctly but with low performance gains (or even performance degradation) because of the time spent in data transfers to/from GPGPUs from/to hosts. Programming kernels requires the use of languages with explicit parallelism, such as CUDA or OpenCL. Debugging is particularly critical (and nontrivial) since a careful and detailed analysis is required to prevent malfunctions caused by desynchronization of threads, wrong memory coalescence policies, or inefficient kernel mapping. Therefore, in order for GPGPUs to provide bet- ter performance than the previously discussed implementation platforms, designers must have deep expertise in kernel technology and its mapping in GPGPU architectures.
FPGAs offer the possibility of developing configurable, custom hardware that might accelerate execution while providing energy savings. In addi- tion, thanks to the increasing scale of integration provided by fabrication technologies, they can include, as discussed in detail in Chapter 3, one or more processing cores, resulting in the so-called field- programmable systems-on-chip (FPSoCs) or systems-on-programmable chip (SoPCs).* These systems may advantageously complement and extend the charac- teristics of the aforementioned single- or multicore platforms with custom hardware accelerators, which allow the execution of all or some critical tasks to be optimized, both in terms of performance and energy consumption.
Powerful design tools are required to deal with the efficient integration of these custom hardware peripherals and others from off-the-shelf libraries, as well as other user-defined custom logic, with (multiple) processor cores in an FPSoC architecture. These SoPC design tools, described in Chapter 6, require designers to have good knowledge of the underlying technologies and the relationship among the different functionalities needed for the design of FPSoCs, in spite of the fact that vendors are making significant efforts for the automation and integration of all their tools in single (but very complex) environments. In this sense, in the last few years, FPGA vendors are offering solutions for multithreaded acceleration that compete with GPGPUs, thus providing tools to specify OpenCL kernels that can be mapped into FPGAs. Also, long-awaited high-level synthesis (HLS) tools now provide a method to migrate from high-level languages such as C, C++, or SystemC into hardware description languages (HDLs), such as VHDL or Verilog, which are the most widely used today by FPGA design tools.
ASICs are custom integrated circuits (mainly nonconfigurable, in the sense explained in Section 1.4) fully tailored for a given application. A careful design using the appropriate manufacturing technology may yield excellent perfor- mance and energy efficiency, but the extremely high nonrecurrent engineering costs and the very specific and complex skills required to design them make this target technology unaffordable for low- and medium-sized productions.
The lack of flexibility is also a problem, since, nowadays, many embedded systems need to be capable of being adapted to very diverse applications and working environments. For instance, the ability to adapt to changing commu- nication protocols is an important requirement in many industrial applications.
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: Memory - Configuration Proms for FPGA's
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: Memory - Configuration Proms for FPGA's
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: CPLDs
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: CPLDs
Lifecycle:Unconfirmed -
RoHS:
Support