Design of SoPC Systems

The implementation of SoPC systems involves tasks related to both software and hardware development. At pure hardware design level, the main chal- lenge for the design tools is their ability to efficiently integrate IP blocks, providing consistent platform-based design techniques and compatible IP libraries for reuse and rapid integration. Consistent methods are also needed for all other aspects of the whole system design flow, so synthesis-, simulation-, and verification-related aspects must also be considered for an efficient integration. From the software point of view, the main problems are associated with debugging the whole software system (possibly made up of a -real time- OS, drivers, and custom software) when implemented in real hardware. 

There are tools that support the design based on embedded soft or hard processor cores (described in Sections 3.2 and 3.3, respectively). In general, they include peripheral IPs, soft processor customization tools, software development tools, hardware/software debuggers, hardware verification tools, libraries, and software and hardware code download methods to devel- opment boards. 

Additionally, SoPC systems can be complemented with standard modules that are generated from core generator tools, embedded in the design envi- ronments, capable of generating instances of components such as memories, interfaces, encoders and decoders to/from multiple standards, or arithmetic operators, among others. 

In the simplest cases, the SoPC can be directly created without the need for any additional HDL description. Designers just have to choose the processor core, configure its features in some kind of graphical user interface, define the types and sizes of memories, and select the peripherals to be included (or import custom peripherals described in HDL). Once the hardware structure has been defined, programming can be carried out, usually in high-level lan- guages. After programming is complete, the SoPC system can be generated and the FPGA configured. 

Hardware and software design tools for SoPCs are analyzed in Sections 6.3.1 and 6.3.2, respectively, whereas core libraries and core generator tools are addressed in Section 6.3.3. 

Hardware Design Tools for SoPCs

As described in Chapter 3, there are many diverse hardware elements a SoPC system may consist of. However, without loss of generality, they may be divided into two categories, namely, interconnect masters (usually microcontrollers or DMA blocks) and slaves (such as specialized peripher- als, hardware accelerators, or memories), arranged in single- or multimaster architectures, and either memory mapped or streamed (i.e., containing addresses and data connections or just passing data between data producers and data consumers—usually through FIFOs, respectively). 

In order to better understand how tools help in the development of SoPC systems, it is also worth recalling that some of these constituent elements are hard cores (prefabricated in the silicon), whereas others are soft cores (built from the resources of the reconfigurable fabric). Regarding hard cores, two possible configurations exist in SoPC systems: 

1. Coarse-grain configuration, where the components taking part in the design are activated and all others remain inactive. 2. Conventional FPGA configuration, where elements attached to the interconnections between the hardware part (processing system) and the configurable part (the configurable logic section) are set. 

The structure in Figure 6.4 (that may be found in devices such as Xilinx Zynq or Altera Cyclone V) contains both types of configuration mechanisms. On the one side, the processing subsystem, which may include just one or sev- eral coupled processing cores, is equipped with a huge variety of “standard” peripherals, such as serial (e.g., I 2 C, SPI, or UART) or network interfaces (e.g., Ethernet or CAN interfaces), or GPIO. Each one of these may come with a variable number of elements, which may or may not be needed for a par- ticular application and, therefore, may be selected to operate or be left inac- tive. For instance, the external inputs and outputs of the interfaces can be directed to virtually any pin in the FPGA by means of an I/O MUX. This corresponds to coarse-grain reconfiguration since the user decides whether to use a whole block, not to use it, or use another one instead. 

FIGURE 6.4 Simplified example of an SoPC implementation on a dual-core hard processor platform.

When commercial development boards are used, the connectors or exter- nal circuits to which the FPGA chip is attached to are predefined, so the con- nectivity that the I/O MUX must provide is “suggested” for each particular board once the customization definition files for that board are installed in the design environment. This relieves designers of the need for customiz- ing external connectivity, so their only task is to “click and select” every required individual module. 

On the other side, the customization enabled by the configurable logic subsystem (the FPGA part of the SoPC) provides much wider adaptation possibilities. The variety of elements available to make up a complete, applica- tion-tailored system allows designers to include, among others, the following: 

• Custom I/O peripherals. 

• Standard I/O peripherals not available in the processing subsystem. This includes the fact that additional ones may be required when the number of peripherals of a given type available in the processing subsystem is not enough for the target application. 

• Custom controllers, which operate almost independently of the pro- grams running in the processing part, but which can be configured to some extent by means of registers accessible by the processors. 

• Hardware accelerators (either custom or standard), which can be used as replacement for repetitive software tasks to increase pro- cessing speed. In this case, there is no FPGA I/O connectivity asso- ciated since connections are directly made between the processing and configurable parts of the device. 

• I/O peripherals with strong processing requirements (e.g., filters), built from DSP modules. 

• Bridges to standard connection interfaces different from the ones used natively in the SoPC, in order to reuse existing modules from other IP libraries. 

• Bridges to support hierarchical communication structures, in order to separate traffic at different levels of interaction, for instance, as discussed in Section 3.5. 

• DMA controllers, which produce specific transactions to/from other elements, in order to achieve high data bandwidth between two ele- ments (e.g., a memory and a high-speed I/O) without intervention of the processor core(s). 

• Of course, soft processors. The use of several processors allows soft- ware tasks to be more efficiently distributed, or task execution to be isolated. 

All these elements may be important for the design of different embedded systems. Examples of the use of FPGAs in industrial embedded systems and the resources that make these devices suitable for different applications in the area are described in Chapter 9. 

One of the main challenges of SoPC design tools is the need to deal with such a huge variety of elements and use generic ways to connect them, avoid- ing complex, time-consuming, and error-prone designer tasks. The gener- alization of connectivity options is achieved to some extent by classifying connections according to several different concepts (most of them analyzed in Section 3.5) as follows: 

• Memory-mapped or streamed connections. 

• In the case of memory-mapped connections, interfaces can be either master or slave, and there may be a single master or multiple masters. 

• Low- or high-speed connections, supporting single or burst transactions. 

• External or internal connectivity. SoPC tools allow internal modules to be easily interconnected through compatible interfaces (either memory mapped or streamed). It is also possible to connect internal modules with others elsewhere out of the SoPC so that they have access to other parts of the design implemented in the FPGA or to external devices. In the first case, the SoPC design tools provide specific ports in the SoPC subsystem entity, which allow it to be connected to other elements in the device, designed using other approaches. In the case of external signals, the tools also provide the ports required to communicate out- side the SoPC, but taking into account that they have to be connected to FPGA I/O pins, placement restrictions for I/O connections must be provided, as discussed in Section 6.2.1. 

It is advisable to make efforts for designing IP modules that guarantee com- patibility with standardized connections. Although at first it may seem that designing them “by hand” provides more control to the designer and simpli- fies the design process, actually there are many clear advantages of making them compatible with SoPC standardized interfaces and designing modules as library components that can be integrated in not just a given one but many SoPC designs. In other words, companies or design teams should consider as a fundamental strategy the development of libraries of proprietary compat- ible IP modules, which can later be seamlessly integrated in multiple SoPC designs. By having access to such libraries, SoPC designers may simply select IP modules from the library, attach them to the SoPC under construction, and connect them to other elements using standardized interfaces. Moreover, interface standardization allows the design tools to verify whether connec- tions are defined in such a way that they will operate correctly. 

This approach is also compatible with design parameterization, for instance, using “generics,” a VHDL feature that enables hardware customiza- tion according to generic parameters specified at design time (i.e., statically assigned case by case). Using this approach, whenever a module from an IP library is selected to be attached to an SoPC system under construction, the specification of the corresponding design parameters is required from the designer by an automatically generated tool interface. 

As can be seen, connectivity standardization and classification allow SoPC designs to be arranged such that all interconnections among internal ele- ments can be made in a controlled way. This ensures, on the one side, correct system behavior and, on the other side, the possibility of building a layered structure of software elements on top of the hardware, which facilitates soft- ware integration. For instance, memory-mapped interfaces with multiple slave elements sharing the same memory map are automatically assigned memory positions and memory ranges, and the corresponding memory decoding logic is automatically attached to the design. Additionally, all mem- ory addresses are supplied as constants with automatically assigned names, which allows software programmers to more easily handle the associated elements (registers and memory-mapped areas), providing an abstraction layer that “isolates” hardware and software designs, so that their respective developments can be overlapped. Software designers do not need to know the actual memory addresses in the final hardware design but can use the automatically generated names instead. This separation also grants code portability; that is, software controllers and drivers may be reused regard- less of the memory assignments done in the automated hardware design. These issues are further explained in Section 6.3.2. 

Software Design Tools for SoPCs

SoPCs require software to run on the processor (or processors) so that the combined action of these programs and the tasks performed by the various hardware elements included in the SoPC system produce the expected results. Hardware and software designs should be carried out from a partition of tasks that, considering available resources as a restric- tion, allocates most computing-intensive tasks to hardware elements and least frequently used tasks, control-based tasks, or (likely) high-level tasks to the software part. 

Considering the many different configuration possibilities, the complex- ity of the underlying architecture can be excessive for the software designer to handle. So, for tools to ease rapid deployment of hardware/software solutions, they must provide sufficient levels of abstraction as well as auto- mation processes that enable designers to easily do two things: verify the integration of software and hardware, and develop and test the necessary control software. 

For complex stand-alone processors, a programmer’s model is provided where registers and main addressable components (i.e., the elements to be handled from the software designer’s perspective) are contained. Similarly, tools for software development in SoPCs must provide such levels of 

FIGURE 6.5 Layered structure for software development support.

abstraction. Figure 6.5 shows a simplified layered structure to connect hard- ware and software, upon which these tools rely. 

Moving bottom-up the hardware representation, including all elements that are actually placed in the FPGA, is made abstract by a layer usually known as hardware abstraction layer (HAL). This simplifies the representa- tion and hides pure hardware details, just keeping the elements that may directly or indirectly be used by upper layers. 

Although design tools are more and more integrated, for instance, through the use of standardized programming environments (such as Eclipse) for programming and verification, there is still a frontier between hardware and software design tools. The HAL layer provides the information to be passed from the hardware design tools to the software design environment. 

From the HAL, memory and register maps are obtained, allowing software designer to easily address any element in the hardware that can be accessed from the processor(s). Every such element is given a constant definition that matches the actual address in the hardware. The name of the constant is nor- mally obtained by the concatenation of at least the bus name and its associ- ated memory map name (automatically or user provided), the device name (normally user provided), and the register generic name (provided by the tools). Although using these names for developing programs might result in being tedious, and even in some cases error prone, it ensures portability (in turn improving productivity): Modifications in the hardware forcing a small redesign of a block within the underlying structure will not affect other blocks’ related software code. For addressed memory areas, constant names are also used to specify upper and lower limits, or ranges. In addition to these “ canonical” names, user-defined aliases can be used for easier identification of specific registers (e.g., the most commonly used) in the design. 

Many of the aforementioned registers are required to be used during the initialization phase of the system for adequate configuration setting. To facil- itate this, tools also include APIs with functions automating the initializa- tion, control, and access processes. In some cases, functions for component verification, benchmarking, and validation are also available. Hardware ver- ification and rapid application deployment are enabled by these high-level functions. Athigher abstraction levels, a distinction must be made between bare-metal applications and those handled by an OS (as also discussed in Section 3.1.1.2). Bare-metal applications rely on functions to access hardware resources and on the abstraction levels provided by the HAL and upper layers. For applica- tions managed by an OS, there is another abstraction provided by the drivers supporting the underlying hardware. The use of drivers improves portabil- ity, but on the other hand, the development of the ported embedded system is more complex because of the need for also porting the OS. However, tool and FPGA vendors are aware of this complexity, so they provide custom- izable porting, either directly or through agreements with the companies supporting the OS. There is also a need for porting or integrating other com- ponents, such as filesystems on top of flash memory controllers so that the OS can easily handle all information. These flash memories need to be par- titioned in order to allocate bootloaders and root filesystems. This process is sometimes cumbersome because we are dealing with embedded systems, so there may be a lack of terminals to interface with the system. 

Once these steps are completed, the advantages of using an OS will become apparent. For instance, some standard peripherals can be configured auto- matically or by specifying the required configuration in the initialization files of the OS. For a very usual feature such as Ethernet communication, module detection, initialization (including link detection), or speed negotia- tion are automatically carried out and network and transport protocols are provided by the OS. Therefore, software designers just need to develop an application that relies on OS sockets, using libraries similar to those avail- able in conventional platforms such as personal computers. In the case of bare-metal applications, the TCP/IP or UDP/IP support provided by the OS is replaced by somehow equivalent high-level functions. Lightweight imple- mentations of this part of the communications stack may be provided to relieve users of the need for configuring the access to the physical device outside of the FPGA and the media access control layer inside the FPGA. The latter can be available either in the configurable fabric or, in many SoPC devices, as a hardware block. 

The top software development support layer in Figure 6.5 is the inte- grated environment itself. As mentioned before, these are standard envi- ronments (with some customization), such as Eclipse, separated from the hardware development environments. They integrate tasks such as the consistent management of all data related to software development, con- figuration management, software project management, interfaces with integrated compilers, deployment tools (interfaces with bitstream down- loaders and executable code downloaders), execution control, access for debugging and profiling control, and its associated windows for visual- ization of results. 

Software applications are packed into projects with support for more than one platform. Projects also integrate source code, compiled libraries (static and dynamic), intermediate representations (i.e., assembly code), and con- figuration data. Intermediate files are checked for consistency with respect to other elements in the project, providing automatic recompilation of the code when some portions they depend on are changed. For user-defined information, such as source code, version control may be activated, allowing programmers to keep control of the changes, backtrack to former versions, or issue versions and releases of the code. 

Compiler options may be selected either manually (by expert users) or from a list of options in wizards or graphic windows. Compilation may be launched as an individual operation by the user, or automatically in response to changes in the code they depend on. After successful compilation and library linking, the executable code is ready to be downloaded to the FPGA, either together with the bitstream or separately. 

During development and verification, execution may be controlled from the integrated environment, once the executable files have been downloaded to the FPGA. For bare-metal applications, this may be done in two ways: 

1. By installing a bootloader that provides a communication path between the FPGA and the computer hosting the integrated environment 

2. By using dedicated logic, usually associated with the JTAG program- ming interface, with some possible extensions for debugging, which enable memory and register content download and execution control When using an OS, execution control is achieved by remote debugging, debugger accesses being carried out through either a serial communication link or a communication port set on top of the TCP/IP stack, if available. Debugging tools for software validation, profiling, and mixed hardware/ software verification will be specifically analyzed in Section 6.6. 

After the validation of the hardware and software parts, and of the correct interoperability among them and the environment of the embedded system, final deployment involves permanently setting all required information, that is, bitstream, executable file(s), and, if it exists, OS image. All this information can be included in a single file, stored in a nonvolatile memory, from which the FPGA will be configured at power-up, as described in Section 6.2. 

Core Libraries and Core Generation Tools

Apart from the tools mentioned in Sections 6.3.1 and 6.3.2, there exist tools intended to generate standardized, but to some extent customizable, cores (e.g., memories) that may be integrated in a design in the same way a custom- designed block may be. These tools produce HDL or netlist-level models of the core. Some core generators are based on highly configurable and param- eterizable models that, by means of using VHDL “generics” or constants included in customizable packages, give designers the possibility of rapidly obtaining a core that fits their needs. 

Many of these cores are for free use, whereas others are only usable at some cost. The latter are usually from third parties whose business is based on selling IP libraries. The ways they are licensed differ, but in some cases, designers are allowed to use them during a given time (they would stop operating after some hours of use, just giving the chance to test their usefulness before purchasing them) or to use them while there is a JTAG cable connected between the development board and the integrated tool environment. 

Some cores are technology independent, in the sense that they may be used in more than one FPGA technology, whereas in other cases, they are family or even device specific. 

In the case of standardized communication interfaces, memory inter- faces, and other I/O-related standards, especially when they are associated with specific devices, the cores include specifications about location, I/O type, and timing constraints in order to ensure that they will work prop- erly on the target device. Also, when standard internal connectivity (such as a slave interface for a given task) is included, the cores are conveniently integrated into the SoPC tools so that connections can be automatically made in a consistent way. For standard interfaces and functions, certified modules are provided in many cases, ensuring full compatibility with the related standards. 

Vendors and associated third-party partners offer huge libraries of com- ponents, which include far too many cores to be listed here. Therefore, just some significant examples are given here: 

• Different types of memories, such as single- or dual-port RAM mem- ories, or FIFO memories, among others. They can be parameterized in size (data width, number of addresses) and have either synchro- nous or asynchronous access. FIFO memories may be equipped with different access and control interfaces (e.g., configurable half-full or half-empty flags). According to their requirements and the resources available in the target device, memory cores can be adapted to be implemented using embedded memory blocks or distributed logic, as discussed in Section 2.4.2. 

• Memory controllers and interfaces to external memories, such as all kinds of compatible DRAM (DDR, LP-DDR, etc.), flash controllers, or DMA controllers. 

• DSP-related blocks, such as digital filters, modulators, and demodula- tors for signals under various standards, compressors and decompres- sors, cyphering blocks, FFT, DCT (and their inverse operators), tools for designing linear algebra blocks and related blocks, CORDIC blocks for trigonometric math, and signal synthesizers (e.g., sinusoidal generators). 

• A wide variety of communication interfaces, certified in many cases, targeting different applications. These may also come as a set of modules allowing custom (application-dependent) communication interfaces to be built by combining blocks such as demodulators, data scramblers, interleavers, or error-correction encoders/decoders. 

• Modules whose application domains are very specific (and so are their architectures and features) but widely used. For instance, there is a large variety of video signal compression and decompres- sion blocks for specific standards, such as H.264 families. There are blocks targeting applications in the aerospace sector (compatible with ARINC or NIST standards, for instance) as well as in indus- trial or medical domains. On many occasions, these specific cores are available subject to some kind of licensing scheme.