Embedded Processors in FPGA Architectures

Only 10 years ago we would have thought about the idea of a smart watch enabling us to communicate with a mobile phone, check our physical activ- ity or heart rate, get weather forecast information, access a calendar, receive notifications, or give orders by voice as the subject of a futuristic movie. But, as we know now, smart watches are only one of the many affordable gadgets readily available in today’s market. 

The mass production of such consumer electronics devices providing many complex functionalities comes from the continuous evolution of elec- tronic fabrication technologies, which allows SoCs to integrate more and more powerful processing and communication architectures in a single device, as shown by the example in Figure 3.1. 

FPGAs have obviously also taken advantage of this technological evolu- tion. Actually, the development of FPSoC solutions is one of the areas (if not THE area) FPGA vendors have concentrated most of their efforts on over recent years, rapidly moving from devices including one general-purpose microcontroller to the most recent ones, which integrate up to 10 complex processor cores operating concurrently. That is, there has been an evolution from FPGAs with single-core processors to homogeneous or heterogeneous mul- ticore architectures (Kurisu 2015), with symmetric multiprocessing (SMP) or asymmetric multiprocessing (AMP) (Moyer 2013). 

This chapter introduces the possibilities FPGAs currently offer in terms of FPSoC design, with different hardware/software alternatives. But, first of all, we will discuss the broader concept of SoC and introduce the related terminology, which is closely linked to processor architectures. 

From Chapter 1, generically speaking, a SoC can be considered to consist of one or more programmable elements (general-purpose processors, micro- controllers, DSPs, FPGAs, or application-specific processors) connected to and interacting with a set of specialized peripherals to perform a set of tasks. From this concept, a single-core, single-thread processor (general-purpose, 

FIGURE 3.1 Processing and communication features in a smart watch SoC.

microcontroller, or DSP) connected to memory resources and specialized peripherals would usually be the best choice for embedded systems aimed at providing specific, non-time-critical functionalities. In these architectures, the processor acts as system master controlling data flows, although, in some cases, peripherals with memory access capabilities may take over data trans- fers with memory during some time intervals. Using FPGAs in this context provides higher flexibility than nonconfigurable solutions, because when- ever a given software-implemented functionality does not provide good- enough timing performance, it can be migrated to hardware. In this solution, all hardware blocks are seen by the processor as peripherals connected to the same communication bus. 

In order for single-core architectures to cope with continuous market demands for faster, more computationally powerful, and more energy- efficient solutions, the only option would be to increase operating frequency (taking advantage of nanometer-scale or 3D stacking technologies) and to reduce power consumption (by reducing power supply voltage). However, from the discussion in Chapter 1, it is clear that for the most demanding current applications, this is not a viable solution, and the only ones that may work are those based on the use of parallelism, that is, the ability of a system to execute several tasks concurrently. 

The straightforward approach to parallelism is the use of multiple single- core processors (with the corresponding multiple sources of power con- sumption) and the distribution of tasks among them so that they can operate concurrently. In these architectures, memory resources and peripherals are usually shared among the processors and all elements are connected through a common communication bus. Another possible solution is the use of multithreading processors, which take advantage of dead times dur- ing the sequential execution of programs (for instance, while waiting for the response from a peripheral or during memory accesses) to launch a new thread executing a new task. Although this gives the impression of parallel execution, it is just in fact multithreading. Of course, these two relatively sim- ple (at least conceptually) options are valid for a certain range of applications, but they have limited applicability, for instance, because of interconnection delays between processors or saturation of the multithreading capabilities. 

Multicore Processors

The limitations of the aforementioned approaches can be overcome by using multicore processors, which integrate several processor cores (either mul- tithreading or not) on a single chip. Since in most processing systems the main factor limiting performance is memory access time, trying to achieve improved performance by increasing operating frequency (and, hence, power consumption) does not make sense above certain limits, defined by the characteristics of the memories. Multicore systems are a much more efficient solution than that because they allow tasks to be executed concur- rently by cores operating at lower frequencies than those a single processor would require, while reducing communication delays among processors, all of them within the same chip. Therefore, these architectures provide a better performance–power consumption trade-off. 

 Main Hardware Issues

There are many concepts associated with multicore architectures, and the commercial solutions to tackle them are very diverse. This section concen- trates just on the main ideas allowing to understand and assess the ability of FPGAs to support SoCs. Readers can easily find additional information in the specialized literature about computer architecture (Stallings 2016). 

The first multicore processors date back some 15 years ago, when IBM intro- duced the POWER4 architecture (Tendler et al. 2002). The evolution since then resulted in very powerful processing architectures, capable of supporting different OSs on a single chip. One might think the ability to integrate mul- tiple cores would have a serious limitation related to increased silicon area 

FIGURE 3.2(a) Homogeneous and (b) heterogeneous multicore processor architectures. (a) Homogeneous architecture: processor cores are identical; (b) heterogeneous architecture: combines different processor cores.

and, in turn, cost. However, nanometer-scale and, more recently, 3D stack- ing technologies have enabled the fabrication of multicore chips at reasonably affordable prices. Today, one may easily find 16-core chips in the market. 

As shown in Figure 3.2, multicore processors may be homogeneous (all of whose cores have the same architecture and instruction set) or heterogeneous (consisting of cores with different architectures and instruction sets). Most general-purpose multicore processors are homogeneous. In them, tasks (or threads) are interchangeable among processors (even at run time) with no effect on functionality, according to the availability of processing power in the different cores. Therefore, homogeneous solutions make an efficient use of parallelization capabilities and are easily scalable. 

In spite of the good characteristics of homogeneous systems, there is a cur- rent trend toward heterogeneous solutions. This is mainly due to the very nature of the target applications, whose increasing complexity and growing need for the execution of highly specialized tasks require the use of plat- forms combining different architectures, as, for instance, microcontrollers, DSPs, and GPUs. Therefore, heterogeneous architectures are particularly suitable for applications where functionality can be clearly partitioned into specific tasks requiring specialized processors and not needing intensive communication among tasks. 

Communications is actually a key aspect of any embedded system, but even more for multicore processors, which require low-latency, high- bandwidth communications not only between each processor and its memory/ peripherals but also among the processors themselves. Shared buses may be used for this purpose, but the most current SoCs rely on crossbar intercon- nections (Vadja 2011). Given the importance of this topic, the on-chip buses most widely used in FPSoCs are analyzed in Section 3.5. 

To reduce data traffic, multicore systems usually have one or two levels of local cache memory associated with each processor (so it can access the data it uses more often without affecting the other elements in the system), 

FIGURE 3.3 Usual cache memory architectures.

plus one higher level of shared cache memory. A side benefit of using shared memory is that in case the decision is made to migrate some sequential pro- gramming to concurrent hardware or vice versa, the fact that all cores share a common space reduces the need for modifications in data or control struc- tures. Examples of usual cache memory architectures are shown in Figure 3.3. 

The fact that some data (shared variables) can be modified by different cores, together with the use of local cache memories, implicitly creates prob- lems related to data coherence and consistency. In brief, coherence means all cores see any shared variable as if there were no cache memories in the system, whereas consistency means instructions to access shared variables are programmed in the sharing cores in the right order. Therefore, coherence is an architectural issue (discussed in the following) and consistency a pro- gramming one (beyond the scope of this book). 

A multicore system using cache memories is coherent if it ensures all pro- cessors sharing a given memory space always “see” at any position within it the last written value. In other words, a given memory space is coherent if a core reading a position within it retrieves data according to the order the cores sharing that variable have written values for it in their local caches. Coherence is obviously a fundamental requirement to ensure all processors access correct data at any time. This is the reason why all multicore proces- sors include a cache-coherent memory system. 

Although there are many different approaches to ensure coherence, all of them are based on modification–invalidation–update mechanisms. In a simplistic way, this means that when a core modifies the value of a shared variable in its local cache, copies of this variable in all other caches are invali- dated and must be updated before they can be used. 

Main Software Issues

As in the case of hardware, there are many software concepts to be con- sidered in embedded systems, and multicore ones in particular, at different levels (application, middleware, OS) including, but not limited to, the neces- sary mechanisms for multithreading control, partitioning, resource sharing, or communications. 

Different scenarios are possible depending on the complexity of the soft- ware to be executed by the processor and that of the processor itself,* as shown in Figure 3.4. For simple programs to be executed in low-end proces- sors, the usual approach is to use bare-metal solutions, which do not require any software control layer (kernel or OS). Two intermediate cases are the implementation of complex applications in low-end processors or simple applications in high-end processors. In both cases, it is usual (and advisable) to use at least a simple kernel. Although this may not be deemed necessary for the latter case, it is highly recommended for the resulting system to be easily scalable. Finally, in order to efficiently implement complex applica- tions in high-end processors, a real-time or high-end OS is necessary (Walls 2014). Currently, this is the case for most embedded systems. 

Other important issues to be considered are the organization of shared resources, task partitioning and sequencing, as well as communications between tasks and between processors. From the point of view of the soft- ware architecture, these can be addressed by using either AMP or SMP approaches, depicted in Figure 3.5. 

SMP architectures apply to homogeneous systems with two or more cores sharing memory space. They are based on using only one OS (if required) for 

FIGURE 3.4 Software scenarios.

* Just to have a straightforward idea about complexity, we label as low-end processors those whose data buses are up to 16-bit wide and as high-end processors those with 32-bit or wider data buses.

FIGURE 3.5 AMP and SMP multiprocessing.

all cores. Since the OS has all the information about the whole system hard- ware at any point, it can efficiently perform a dynamic distribution of the workload among cores (which implies extract application parallelism, parti- tion of tasks/threads, and dynamic assignment of tasks to cores), as well as the control of the ordering of task completion and of resource sharing among cores. Resource sharing control is one of the most important advantages of 

SMP architectures. Another significant one is easy interprocess communica- tion, because there is no need for implementing any specific communication protocol, thus avoiding the overhead this would introduce. Finally, debug- ging tasks are simpler when working with just one OS. SMP architectures are clearly oriented to get the most possible advantage of parallelism to maximize processing performance, but they have a main limiting factor, related to the dynamic distribution of workload. This factor affects the ability of the system to provide a predictable timing response, which is a fundamental feature in many embedded applications. Another past drawback, the need for an OS supporting multicore processing, is not a significant problem anymore given the wide range of options currently available (Linux, embedded Windows, and Android, to cite just some). 

In contrast to SMP, AMP architectures can be implemented in either homo- geneous or heterogeneous multicore processors. In this case, each core runs its own OS (either separate copies of the same or totally different ones; some cores may even implement a bare-metal system). Since none of the OSs is specifically in charge of controlling shared resources, such control must be very carefully performed at the application level. AMP solutions are oriented to applications with a high level of intrinsic parallelism, where critical tasks are assigned to specific resources in order for a predictable behavior to be achieved. Usually, in AMP systems, processes are locked (assigned) to a given processor. This simplifies the individual control of each core by the designer. In addition, it eases migration from single-core solutions. 

Many-Core Processors

Single- and multicore solutions are the ones most commonly found in SoCs, but there is a third option, many-core processors, which find their main niche in systems requiring a high scalability (mostly intensive computing applica- tions), for instance, cloud computing datacenters. Many-core processors con- sist of a very large number of cores (up to 400 in some existing commercially available solutions [Nickolls and Dally 2010; NVIDIA 2010; Kalray 2014]), but are simpler and have less computing power than those used in multicore sys- tems. These architectures aim at providing massive concurrency with a com- paratively low energy consumption. Although many researchers and vendors (Shalf et al. 2009; Jeffers and Reinders 2015; Pavlo 2015) claim this will be the dominant processing architecture in the future, its analysis is out of the scope of this book, because until now, it has not been adopted in any FPGA. 

FPSoCs

At this point two pertinent questions arise: What is the role of FPGAs in SoC design, and what can they offer in this context? Obviously, when speak- ing of parallelism or versatility, no hardware platform compares to FPGAs. Therefore, combining FPGAs with microcontrollers, DSPs, or GPUs clearly seems to be an advantageous design alternative for a countless number of applications demanded by the market. Some years ago, FPGA vendors realized the tremendous potential of SoCs and started developing chips that combined FPGA fabric with embedded microcontrollers, giving rise to FPSoCs. 

The evolution of FPSoCs can be summarized as shown in Figure 3.6. Initially, FPSoCs were based on single-core soft processors, that is, configu- rable microcontrollers implemented using the logic resources of the FPGA fabric. The next step was the integration in the same chip as the FPGA fabric of single-core hard processors, such as PowerPC. In the last few years, sev- eral families of FPGA devices have been developed that integrate multicore processors (initially homogeneous architectures and, more recently, hetero- geneous ones). As a result, the FPSoC market now offers a wide portfolio of low-cost, mid-range, and high-end devices for designers to choose from depending on the performance level demanded by the target application. 

FPGAs are among the few types of devices that can take advantage of the latest nanometer-scale fabrication technologies. At the time of writing this book, according to FPGA vendors (Xilinx 2015; Kenny 2016), high-end FPGAs are fabricated in 14 nm process technologies, but new families have already 

FIGURE 3.6 FPSoC evolution.

been announced based on 10 nm technologies, whereas the average for ASICs is 65 nm. The reason for this is just economic viability. When migrat- ing a chip design to a more advanced node (let us say from 28 to 14 nm), the costs associated with hardware and software design and verification dra- matically grow, to the extent that for the migration to be economically viable, the return on investment must be in the order of hundreds of millions of dollars. Only chips for high-volume applications or those that can be used in many different applications (such as FPGAs) can get to those figures. 

The different FPSoC options currently available in the market are ana- lyzed in the following sections.