On-Chip Buses

One key factor to successfully develop embedded systems is to achieve an efficient communication between processors and their peripherals. Therefore, one of the major challenges of SoC technology is the design of the on-chip communication infrastructure, that is, the communication buses ensuring fast and secure exchange of information (either data or control sig- nals), addressing issues such as speed, throughput, and latency. At the same time, it is very important (particularly when dealing with FPSoC platforms) that such functionality is available in the form of reusable IP cores, allowing both design costs and time to market to be reduced. Unfortunately, some IP core designers use different communication protocols and interfaces (even proprietary ones), complicating their integration and reuse, because of com- patibility problems. In such cases, it is necessary to add glue logic to the designs. This creates problems related to degraded performance of the IP core and, in turn, of the whole SoC. To address these issues, over the years, some leading companies in the SoC market have proposed different on-chip bus architecture standards. The most popular ones are listed here: 

• Advanced Microcontroller Bus Architecture (AMBA) from ARM (open standard) 

• Avalon from Altera (open-source standard) 

• CoreConnect from IBM (licensed, but available at no licensing or royalty cost for chip designers and core IP and tool developers) 

• CoreFrame from PalmChip (licensed) 

• Silicon Backplane from Sonics (licensed) 

• STBus from STMicroelectronics (licensed) 

• WishBone from OpenCores (open-source standard) 

Most of these buses originated in association with certain processor archi- tectures, for instance, AMBA (ARM processors), CoreConnect (PowerPC), or Avalon (Nios-II). Integration of a standard bus with its associated processor(s) is quite straightforward, resulting in modular systems with optimized and predictable behavior. Due to this, there is a trend, seen in the case of not only for chip vendors but also third-party IP companies, toward the use of technology- independent standard buses in library components, which ease design integration and verification. 

In the FPGA market, AMBA has become the de facto dominating connec- tivity standard in industry for IP-based design because the leading vendors (Xilinx, Altera, Microsemi, QuickLogic) are clearly opting for embedding ARM processors (either Cortex-A or Cortex-M) within their chips. Other buses widely used in FPSoCs are Avalon and CoreConnect because of their association with the Nios-II and MicroBlaze soft processors, respectively. Wishbone is also used in some Lattice and OpenCores processors. These four buses are analyzed in detail in Sections 3.5.1 through 3.5.4.

AMBA 

AMBA originated as the communication bus for ARM processor cores. It consists of a set of protocols included in five different specifications. The most widely used protocols in FPSoCs are Advanced eXtensible Interface (AXI3, AXI4, AXI4-Lite, AXI4-Stream) and Advanced High-performance Bus (AHB). Therefore, these are the ones analyzed in detail here, but at the end of the section, a table is included to provide a more general view of AMBA.  

AHB 

AMBA 2 specification, published in 1999, introduced AHB and Advanced Peripheral Bus (APB) protocols (ARM 1999). AMBA 2 uses by default a hier- archical bus architecture with at least one system (main, AHB) bus and secondary (peripheral, APB) buses connected to it through bridges. The per- formance and bandwidth of the system bus ensure the proper interconnec- tion of high-performance, high clock frequency modules such as processors, on-chip memories, and DMA devices. Secondary buses are optimized to connect low-power or low-bandwidth peripherals, their complexity being, as a consequence, also low. Usually these peripherals use memory-mapped registers and are accessed under programmed control. 

The structure of a SoC based on this specification is shown in Figure 3.18. The processor and high-bandwidth peripherals are interconnected through an AHB bus, whereas low-bandwidth peripherals are interconnected through an APB bus. The connection between these two buses is made through a bridge that translates AHB transfer commands into APB format and buf- fers all address, data, and control signals between both buses to accommo- date their (usually different) operating frequencies. This structure allows the effect of slow modules in the communications of fast ones to be limited. 

FIGURE 3.18 SoC based on AHB and APB protocols.

FIGURE 3.19 AHB bus structure according to AMBA 2 specification.

In order to fulfill the requirements of high-bandwidth modules, AHB supports pipelined operation, burst transfers, and split transactions, with a configurable data bus width up to 128 bits. As shown in Figure 3.19, it has a master–slave structure with arbiter, based on multiplexed interconnections and four basic blocks: AHB master, AHB slave, AHB arbiter, and AHB decoder. 

AHB masters are the only blocks that can launch a read or write operation, by generating the address to be accessed, the data to be transferred (in the case of write operations), and the required control signals. In an AHB bus, there may be more than one master (multimaster architecture), but only one of them can take over the bus at a time. 

AHB slaves react to read or write requests and notify the master if the trans- fer was successfully completed, if there was an error in it, or if it could not be completed so that the master has to retry (e.g., in the case of split transactions). 

The AHB arbiter is responsible to ensure only one AHB master takes over the bus (i.e., starts a data transfer) at a time. Therefore, it defines the bus access hierarchy, by means of a fixed arbitration protocol. Finally, the AHB decoder is used for address decoding, generating the right slave selection signals. In an AHB bus, there is only one arbiter and one decoder. 

Operation is as follows: All masters willing to start a transfer generate the corresponding address and control signals. The arbiter then decides which master signals are to be sent to all slaves through the correspond- ing MUXs, while the decoder selects the slave actually involved in the transfer through another MUX. In case there is an APB bus, it acts as a slave of the corresponding bridge, which provides a second level of decoding for the APB slaves. 

In FPSoCs using AHB, the processor is a master; the DMA controller is usually a master too. On-chip memories, external memory controllers, and APB bridges are usually AHB slaves. Although any peripheral can be con- nected as an AHB slave, if there is an APB bus, slow peripherals would be connected to it. 

Multilayer AHB 

AMBA 3 specification (ARM 2004a), published in 2003, introduces the multilayer AHB interconnection scheme, based on an interconnection matrix that allows multiple parallel connections between masters and slaves to be established. This provides increased flexibility, higher bandwidth, the possi- bility of associating the same slave to several masters, and reduced complex- ity, because arbitration tasks are limited to the cases when several masters want to access the same slave at the same time. 

The simplest multilayer AHB structure is shown in Figure 3.20, where each master has its own AHB layer (i.e., there is only one master per layer). The decoder associated with each layer determines the slave involved in the transfer. If two masters request access to the same slave at the same time, the arbiter associated with the slave decides which master has the higher prior- ity. The input stages of the interconnection matrix (one per layer) store the addresses and control signals corresponding to the pending transfers so that can be carried out later. 

The number of input and output ports of the interconnection matrix can be adapted to the requirements of different applications. In this way, it is possible to build structures more complex than the one in Figure 3.20. For instance, 

FIGURE 3.20 Multilayer interconnect topology.

FIGURE 3.21 ARM Cortex-M3 core and peripherals in SmartFusion2 devices.

it is possible to have several masters in the same layer, define local slaves (connected to just one layer), or group a set of slaves so that the intercon- nection matrix treats them as a single one. This is useful, for instance, to combine low-bandwidth slaves. 

An example of FPSoC that uses AHB/APB buses is the Microsemi SmartFusion2 SoC family (Microsemi 2013). As shown in Figure 3.21, it includes an ARM Cortex-M3 core and a set of peripherals organized in 10 masters (MM), 7 direct slaves (MS), and a large number of secondary slaves, connected through an AHB to AHB bridge and two APB bridges (APB_0 and APB_1). The AHB bus matrix is multilayer. 

AXI 

ARM introduced in AMBA 3 specification a new architecture, namely, AXI or, more precisely, AXI3 (ARM 2004b). The architecture was provided with additional functionalities in AMBA 4, resulting in AXI4 (ARM 2011). AXI provides a very efficient solution for communicating with high-frequency peripherals, as well as for multifrequency systems (i.e., systems with mul- tiple clock domains). 

AXI is currently a de facto standard for on-chip busing. A proof of its success is that some 35 leading companies (including OEM, EDA, and chip designers—FPGA vendors among them) cooperate in its development. As a result, AXI provides a communication interface and architecture suitable for SoC implementation in either ASICs or FPGAs. 

AMBA 3 and AMBA 4 define four different versions of the protocol, namely, AXI3, AXI4, AXI4-Lite, and AXI4-Stream. Both AXI3 and AXI4 are 

FIGURE 3.22 Architecture of the AXI protocol.

very robust, high-performance, memory-mapped solutions.* AXI4-Lite is a very reduced version of AXI4, intended to support access to control registers and low-performance peripherals. AXI4-Stream is intended to support high- speed streaming applications, where data access does not require addressing. 

As shown in Figure 3.22, AXI architecture is conceptually similar to that of AHB in that both use master–slave configurations, where data transfers are launched by masters and there are interconnect components to connect masters to slaves. 

The main difference is that AXI uses a point-to-point channel architec- ture, where address and control signals, read data, and write data use inde- pendent channels. This allows simultaneous, bidirectional data transfers between a master and a slave to be carried out, using handshake signals. A direct implication of this feature is that it eases the implementation of low- cost DMA systems. 

AXI defines a single connection interface either to connect a master or a slave to the interconnect component or to directly connect a master to a slave. This interface has five different channels: read address channel, read data channel, write address channel, write data channel, and write response channel. Figure 3.23 shows read and write transactions in AXI. 

Address and control information is sent through either the read or the write address channels. In read operations, the slave sends the master both data and a read response through the read data channel. The read response notifies the master that the read operation has been completed. The protocol includes an overlapping read burst feature, so the master may send a new read address before the slave has completed the current transaction. In this way, the slave can start preparing data for the new transaction while com- pleting the current one, thus speeding up the read process. In write opera- tions, the master sends data through the write data channel, and the slave 

FIGURE 3.23 Read (a) and write (b) transactions in AXI protocol.

replies with a completion signal through the write response channel. Write data are buffered, so the master can start a new transfer before the slave noti- fies the completion of the current one. Read and write data bus widths are configurable from 8 to 1024 bits. All data transfers in AXI (except AXI4-Lite) are based on variable-length bursts, up to 16 transfers in AXI3 and up to 256 in AXI4. Only the starting address of the burst needs to be provided to start the transfer. 

The interconnect component in Figure 3.22 is more versatile than the inter- connection matrix in AHB. It is a component with more than one AMBA interface, in charge of connecting one or more masters to one or more slaves. In addition, it allows a set of masters or slaves to be grouped together, so they are seen as a single master or slave. 

In order to adapt the balance between performance and complexity to dif- ferent application requirements, the interconnect component can be config- ured in several modes. The most usual ones are shared address and data buses, shared address buses and multiple data buses, and multilayer, with multiple address and data buses. For instance, in systems requiring much higher bandwidth for data than for addresses, it is possible to share the address bus among different interfaces while having an independent data bus for each interface. In this way, data can be transferred in parallel at the same time as address channels are simplified. 

Other interesting features of AXI are as follows: 

• It supports pipeline stages (register slices in ARM’s terminology) in all channels, so different throughput/latency trade-offs can be achieved depending on the number of stages. This is feasible because all channels are independent of each other and send information in only one direction. 

• Each master–slave pair can operate at a different frequency, thus simplifying the implementation of multifrequency systems. 

• It supports out-of-order transaction completion. For instance, if a master starts a transaction with a slow peripheral and later another one with a fast peripheral, it does not need to wait for the former to be completed before attending the latter (unless completing the transactions in a given order is a requirement of the application). In this way, the negative influence of dead times caused by slow peripherals is reduced. Complex peripherals can also take advan- tage of this feature to send their data out of order (some complex peripherals may generate different data with different latencies). Out-of-order transactions are supported in AXI by ID tags. The mas- ter assigns the same ID tag to all transactions that need to be com- pleted on order and different ID tags to those not requiring a given order of completion. 

We are just intending here to highlight some of the most significant features of AXI, but it is really a complex protocol because of its versatility and high degree of configurability. It includes many other features, such as unaligned data transfers, data upsizing and downsizing, different burst types, system cache, privileged and secure accesses, semaphore-type operations to enable exclusive accesses, and error support. 

Today, the vast majority of FPSoCs use this type of interface, and vendors include a large variety of IP blocks based on it, which can be easily con- nected to create highly modular systems. In most cases, when including AXI-based IPs in a design, the interconnect logic is automatically gener- ated and the designer usually just needs to define some configuration parameters. 

The most important conclusion that can be extracted from the use of this solution is that it enables software developers to implement SoCs without the need for deep knowledge of FPGA technology, but mainly concentrating on programming tasks. 

As an example, Xilinx adopted AXI as a communication interface for the IP cores in its FPGA families Spartan-6, Virtex-6, UltraScale, 7 series, and Zynq-7000 All Programmable SoC (Sundaramoorthy et al. 2010; Singh and Dao 2013; Xilinx 2015a). The portfolio of AXI-compliant IP cores includes a large number of peripherals widely used in SoC design, such as processors, timers, UARTs, memory controllers, Ethernet controllers, video controllers, and PCIe. In addition, a set of resources known as Infrastructure IP are also available to help in assembling the whole FPSoC. They provide features such as routing, transforming, and data checking. 

Examples of such blocks are as follows: 

• AXI Interconnect IP, to connect memory-mapped masters and slaves. It performs the tasks associated with the interconnect component by combining a set of IP cores (Figure 3.24): As commented earlier, AXI does not define the structure of the interconnect component, but it can be configured in multiple ways. The AXI Interconnect IP core supports the use models shown in Figure 3.25, which highlights the versatility and power of AXI for the implementation of FPSoCs. 

• AXI Crossbar, to connect AXI memory-mapped peripherals. 

• AXI Data Width Converter, to resize the datapath when master and slave use different data widths. 

• AXI Clock Converter, to connect masters and slaves operating in different clock domains. 

• AXI Protocol Converter, to connect an AXI3, AXI4, or AXI4-Lite master to a slave that uses a different protocol (e.g., AXI4 to AXI4- Lite or AXI4 to AXI3). 

• AXI Data FIFO, to connect a master to a slave through FIFO buffers (it affects read and write channels). 

• AXI Register Slice, to connect a master to a slave through a set of pipeline stages. In most cases, this is intended to reduce critical path delay. 

• AXI Performance Monitors and Protocol Checkers, to test and debug AXI transactions. 

FIGURE 3.24 Block diagram of the Xilinx’s AXI Interconnect IP core.

FIGURE 3.25 Xilinx’s AXI Interconnect IP core use models.

In order for readers to have easy access to the most significant information regarding the different variations of AMBA, their main features are summarized in Table 3.2.

Avalon 

Avalon is the solution provided by Altera to support FPSoC design based on the Nios-II soft processor. The original specification dates back to 2002, and a slightly modified version can be found in Altera (2003). 

Avalon basically defines a master–slave structure with arbiter, which supports simultaneous data transfers among multiple master–slave pairs. When multiple 

TABLE 3.2  Specifications and Protocols of the AMBA Communication Bus 

Year Spec. Protocol Aim and Features 

1999 AMBA 2 AHB Supports high-bandwidth system modules 

Main system bus in microcontroller usage 

                      Some features are 

                      • 32-bit address width and 8- to 128-bit data width 

                      • Single shared address bus and separate read and write data buses 

                      • Default hierarchical bus topology support 

                      • Supports multiple bus masters 

                      • Burst transfers 

                      • Split transactions 

                      • Pipelined operation (fixed pipeline between address/control and data phases) 

                      • Single-cycle bus master handover 

                      • Single-clock edge operation 

                      • Non-tri-state implementation 

                      • Single frequency system APB Simple, low-power interface to support low-bandwidth peripherals Some features are 

                      • Local secondary bus encapsulated as a single AHB slave device 

                      • 32-bit address width and 32-bit data width 

                      • Simple interface 

                      • Latched address and control 

                      • Minimal gate count for peripherals 

                      • Burst transfers not supported 

                      • Unpipelined 

                      • All signal transitions are only related to the rising edge of the clock 

TABLE 3.2 (Continued )  Specifications and Protocols of the AMBA Communication Bus 

Year Spec. Protocol Aim and Features 

2003 AMBA 3 AXI 

Intended for high-performance memory-mapped requirements 

(AXI3)               Key features: 

                        • 32-bit address width and 8- to 1024-bit data width 

                        • Five separate channels: read address, write address, read data, write data, and write response 

                        • Default bus matrix topology support 

                        • Simultaneous read and write transactions 

                        • Support for unaligned data transfers using byte strobes 

                        • Burst-based transactions with only start address issued 

                        • Fixed-burst mode for memory-mapped I/O peripherals 

                        • Ability to issue multiple outstanding addresses 

                        • Out-of-order transaction completion 

                        • Pipelined interconnect for high-speed operation 

                        • Register slices can be applied across any channel 

AHB-The main differences with regard to AHB are that it does not support multiple bus masters and extends data width 

Lite up to 1024 bits 

APB Includes two new features with regard to AMBA 2 specification, namely, wait states and error reporting 

ATB Advanced Trace Bus: adds a data diagnostic interface to the AMBA specification for debugging purposes 

TABLE 3.2 (Continued )MSpecifications and Protocols of the AMBA Communication Bus

Year Spec. Protocol Aim and Features

2011 AMBA 4 ACE AXI Coherency Extensions: extends the AXI4 protocol and provides support for hardware-coherent caches. Enables

                       correctness to be maintained when sharing data across caches

                       correctness to be maintained when sharing data across caches

Lite

AXI4 The main difference with regard to AXI3 is that it allows up to 256 beats of data per burst instead of just 16 

                       It supports Quality of Service signaling

AXI4- A subset of AXI4 intended for simple, low-throughput memory-mapped communications

Lite                 Key features

                       • Burst length of one for all transactions

                       • 32- or 64-bit data bus

                       • Exclusive accesses not supported

AXI4- Intended for high-speed data streaming

Stream Designed for unidirectional data transfers from master to slave, greatly reducing routing

                       Key features:

                       • Supports single- and multiple data streams using the same set of shared wires

                       • Supports multiple data widths within the same interconnect

APB Includes two new functionalities with regard to AMBA 3 specification, namely, transaction protection and sparse data transfer

2013 AMBA 5 CHI Coherent Hub Interface: it defines the interconnection interface for fully coherent processors and dynamic memory

controllers.

                       Used in networks and serves

FIGURE 3.26 Sample FPSoC based on Altera’s Avalon bus.

masters want to access the same slave, the arbitration logic defines the access priority and generates the control signals required to ensure all requested transactions are eventually completed. Figure 3.26 shows the block diagram of a sample FPSoC including a set of peripherals connected through an Avalon Bus Module. 

The Avalon Bus Module includes all address, data, and control signals, as well as arbitration logic, required to connect the peripherals and build up the FPSoC. Its functionality includes address decoding for peripheral selec- tion, wait-state generation to accommodate slow peripherals that cannot pro- vide responses within a single clock cycle, identification and prioritization of interrupts generated by slave peripherals, or dynamic bus sizing to allow peripherals with different data widths to be connected. The original Avalon specification supports 8-, 16-, and 32-bit data. 

Avalon uses separate ports for address, data, and control signals. In this way, the design of the peripherals is simplified, because there is no need for decod- ing each bus cycle to distinguish addresses from data or to disable outputs. 

Although it is mainly oriented to memory-mapped connections, where each master–slave pair exchanges a single datum per bus transfer, the origi- nal Avalon specification also includes streaming peripherals and latency- aware peripherals modes (included in the Avalon Bus Module), oriented to support high-bandwidth peripherals. The first one eases transactions between streaming master and streaming slave to perform successive data transfers, which is particularly interesting for DMA transfers. The second one allows bandwidth usage to be optimized when accessing synchronous peripherals that require an initial latency to generate the first datum, but after that are capable of generating a new one each clock cycle (such as in the case of digital filters). In this mode, the master can execute a read request to the peripheral, then move to other tasks, and resume the read operation later. 

As the demand for higher bandwidth and throughput was growing in many application domains, Avalon and the Nios-II architecture evolved to cope with it. The current Avalon specification (Altera 2015a) defines seven different interfaces: 

1. Avalon Memory Mapped Interface (Avalon-MM), oriented to the connection of memory-mapped master–slave peripherals. It pro- vides different operation modes supporting both simple peripher- als requiring a fixed number of bus cycles to perform read or write transfers and much more complex ones, for example, with pipelin- ing or burst capabilities. With regard to the original specification, maximum data width increases from 32 to 1024 bits. 

Like AMBA and many other memory-mapped buses, Avalon pro- vides generic control and handshake signals to indicate the direction (read or write), start, end, successful completion, or error of each data transfer. Examples of such signals are “read,” “write,” or “response” in Figure 3.27. There are also specific signals required in advanced modes, such as arbitration signals in multimaster systems, wait signals to notify the master the slave cannot provide an immediate response to the request (“wait_request” in Figure 3.27), data valid sig- nals (typical in pipelined peripherals to notify the master that there are valid data in the data bus, “read_data_valid” in Figure 3.27), or control signals for burst transfers. 

2. Avalon Streaming Interface (Avalon-ST, Figure 3.28), oriented to peripherals performing high-bandwidth, low-latency, unidirectional point-to-point transfers. The simplest version supports single stream 

FIGURE 3.27 Typical read and write transfers of the Avalon-MM interface.

FIGURE 3.28 Avalon-ST interface signals.

of data, which only requires the signals “data” and “valid” to be used and, optionally, “channel” and “error.” The sink interface samples data only if “valid” is active (i.e., there are valid data in “data”). The signal “channel” indicates the number of the channel, and “error” is a bit mask stating the error conditions considered in the data transfer (e.g., bit 0 and bit 1 may flag CRC and overflow errors, respectively). 

Avalon-ST also allows interfaces supporting backpressure to be implemented. In this case, the source interface can only send data to the sink when this is ready to accept them (the signal “ready” is active). This is a usual technique to prevent data loss, for example, when the FIFO at the sink is full. 

Finally, Avalon-ST supports burst and packet transfers. In packet- based transfers, “startofpacket” and “endofpacket” identify the first and last valid bus cycles of the packet. The signal “empty” identifies empty symbols in the packet, in the case of variable-length packets. 

3. Avalon Conduit Interface, which allows data transfer signals (input, output, or bidirectional) to be created when they do not fit in any other types of Avalon interface. These are mainly used to design interfaces with external (off-chip) devices. Several conduits can be connected if they use the same type of signals, of the same width, and within the same clock domain. 

4. Avalon Tri-State Conduit Interface (Avalon-TC), oriented to the design of controllers for external devices sharing resources such as address or data buses, or control signals in the terminals of the FPGA chip. Signal multiplexing is widely used to access multiple external devices mini- mizing the number of terminals required. In this case, the access to the shared terminals is based on tri-state signals. Avalon-TC includes all control and arbitration logic to identify multiplexed signals and give bus control to the right peripheral at any moment. 

5. Avalon Interrupt Interface, which is in charge of managing inter- rupts generated by interrupt senders (slave peripherals) and notify them to the corresponding interrupt receivers (masters). 

6. Avalon Reset Interface, which resets the internal logic of an interface or peripheral, forcing it to a user-defined safe state. 

7. Avalon Clock Interface, which defines the clock signal(s) used by a peripheral. A peripheral may have clock input (clock sink), clock out- put (clock source), or both (for instance, in the case of PLLs). All other synchronous interfaces a peripheral may use (MM, ST, Conduit, TC, Interrupt, or Reset) are associated with a clock source acting as syn- chronization reference. 

An FPSoC based on the Nios-II processor and Avalon may include multiple different interfaces or multiple instances of the same interface. Actually, a single component within the FPSoC may use any number and type of inter- faces, as shown in Figure 3.29. 

To ease the design and verification of Avalon-based FPSoCs, Altera pro- vides the system integration tool Qsys (Altera 2015b), which automatically generates the suitable interconnect fabric (address/data bus connections, bus width matching logic, address decoder logic, arbitration logic) to con- nect a large number of IP cores available in its design libraries. Actually, 

FIGURE 3.29 Sample FPSoC using different Altera’s Avalon interfaces.

Qsys also eases the design of systems using both Avalon and AXI and automatically generates bridges to connect components using different buses (Altera 2013).

CoreConnect 

CoreConnect is an on-chip interconnection architecture proposed by IBM in the 1990s. Although the current strong trend to use ARM cores in the most current FPGA devices points to the supremacy of AMBA-based solu- tions, CoreConnect is briefly analyzed here because Xilinx uses it for the MicroBlaze (soft) and PowerPC (hard) embedded processors. 

CoreConnect consists of three different buses, intended to accommodate memory-mapped or DMA peripherals of different performance levels (IBM 1999; Bergamaschi and Lee 2000): 

1. Processor Local Bus (PLB), a system bus to serve the processor and connect high-bandwidth peripherals (such as on-chip memories or DMA controllers). 

2. On-Chip Peripheral Bus (OPB), a secondary bus to connect low- bandwidth peripherals and reduce traffic in PLB. 3. Device Control Register (DCR), oriented to provide a channel to con- figure the control registers of the different peripherals from the pro- cessor and mainly used to initialize them. 

The block diagram of the CoreConnect bus architecture is shown in Figure 3.30, where structural similarities with AMBA 2 (Figure 3.18) may be noticed. Same as AMBA 2, CoreConnect uses two buses, PLB and OPB, with different performance levels, interconnected through bridges. 

FIGURE 3.30 Sample FPSoC using CoreConnect bus architecture.

Both PLB and OPB use independent channels for addresses, read data, and write data. This enables simultaneous bidirectional transfers. They also sup- port a multimaster structure with arbiter, where bus control is taken over by one master at a time. 

PLB includes functionalities to improve transfer speed and safety, such as fixed- or variable-length burst transfers, line transfers, address pipelining (allowing a new read or write request to be overlapped with the one current being serviced), master-driven atomic operation, split transactions, or slave error reporting, among others. 

PLB-to-OPB bridges allow PLB masters to access OPB peripherals, there- fore acting as OPB masters and PLB slaves. Bridges support dynamic bus siz- ing (same as the buses themselves), line transfers, burst transfers, and DMA transfers to/from OPB masters. F

ormer Xilinx Virtex-II Pro and Virtex-4 families include embedded PowerPC 405 hard processors (Xilinx 2010a), whereas PowerPC 440 proces- sors are included in Virtex-5 devices (Xilinx 2010b). In all cases, CoreConnect is used as communication interface. Specifically, PLB buses are used for data transfers and DCR for initializing the peripherals as well as for system veri- fication purposes. 

Although the most recent versions of the MicroBlaze soft processor (from 2013.1 on) use as main interconnection interfaces AMBA 4 (AXI4 and ACE) and Xilinx proprietary bus LMB, optionally, they can implement OPB. 

WishBone 

Wishbone Interconnection for Portable IP Cores (usually referred to just as Wishbone) is a communication interface developed by Silicore in 1999 and maintained since 2002 by OpenCores. Like the other interfaces described so far, Wishbone is based on a master–slave architecture, but, unlike them, it defines just one bus type, a high-speed bus. Systems requiring connections to both high-performance (i.e., high-speed, low-latency) and low-performance (i.e., low-speed, high-latency) peripherals may use two separate Wishbone interfaces without the need for using bridges. 

The general Wishbone architecture is shown in Figure 3.31. It includes two basic blocks, namely, SYSCON (in charge of generating clock and reset sig- nals) and INTERCON (the one containing the interconnections). It supports four different interconnection topologies, some of them with multimaster capabilities: 

• Point to point, which connects a single master to a single slave. 

• Data flow, used to implement pipelined systems. In this topology, each pipeline stage has a master interface and a slave interface. 

• Shared bus, which connects two or more masters with one or more slaves, but only allows one single transaction to take place at a time. 

FIGURE 3.31 General architecture and connection topologies of Wishbone interfaces.

• Crossbar switch, which allows two or more masters to be simultane- ously connected to two or more slaves; that is, it has several connec- tion channels. 

Shared bus and crossbar switch topologies require arbitration to define how and when each master accesses the slaves. However, arbiters are not defined in the Wishbone specification, so they have to be user defined. 

According to Figure 3.31, Wishbone interfaces have independent address (ADR, 64-bit) and data (DAT, 8-/16-/32- or 64-bit) buses, as well as a set of handshake signals (selection [SEL], strobe [STB], acknowledge [ACK], error [ERR], retry [RTY], and cycle [CYC]) ensuring correct transmission of infor- mation and allowing data transfer rate to be adjusted for every bus cycle (all Wishbone bus cycles run at the speed of the slowest interface). 

In addition to the signals defined in its specification, Wishbone supports user-defined ones in the form of “tags” (TAGN in Figure 3.31). These may be used for appending information to an address bus, a data bus, or a bus cycle. They are especially helpful to identify information such as data transfers, parity or error correction bits, interrupt vectors, or cache control operations. 

Wishbone supports three basic data transfer modes: 

1. Single read/write, used in single-data transfers. 

2. Block read/write, used in burst transfers. 

3. Read–modify–write, which allows data to be both read and written in a given memory location in the same bus cycle. During the first half of the cycle, a single read data transfer is performed, whereas a write data transfer is performed during the second half. The CYC_O signal (Figure 3.31) remains asserted during both halves of the cycle. This transfer mode is used in multiprocessor or multitask systems where different software processes share resources using sema- phores to indicate whether a given resource is available or not at a given moment. 

Wishbone is used in Lattice’s LM8 and LM32, as well as in OpenCores’ OpenRISC1200 soft processors, described in Sections 3.2.1 and 3.2.2, respectively.