tr0170 openbus interconnect component reference

8/2/2019 TR0170 OpenBus Interconnect Component Reference

1/15

OpenBus Interconnect ComponentReference

Summary

Technical Reference

TR0170 (v2.0) March 04, 2008

This document provides detailed reference information with respect to the OpenBus

Interconnect component.

The Interconnect component provides a means of accessing one or more peripheral devices over a single OpenBus interface. It

connects directly to the IO or MEM ports of a processor component, facilitating communication with I/O peripherals or physical

memory devices, respectively.

The Interconnect component can be used with any of the 32-bit processors supported by, and available for use in, an OpenBus

System.

So just what makes the use of this intermediary component beneficial in an OpenBus System? This a good question and one

that can be answered by several key functions that the Interconnect component performs functions which make life much

easier in terms of implementing a design within the OpenBus System:

Allows the definition of a base address for a connected slave peripheral device (I/O or memory), which is then used to map

that device into the processor's address space.

Allows for the connection of multiple slave peripheral devices (I/O or memory), all of which are accessed by the processor

over a single bus.

Allows for the connection of slave peripheral I/O devices that have different data bus widths (8-, 16- or 32-bit).

Handles the address mapping from the processor to the slave peripheral device (I/O or memory). This involves not only the

mode of addressing used (byte addressing or word addressing) but also the address bus width the number of bits required

to drive the connected slave device.

In comparison to its counterpart (WB_INTERCON) in the schematic world, the OpenBus System streamlines the use of the

Interconnect component, with much of the configuration handled for you 'behind the scenes'. For more information on

configuring the component, see the section Configuring the Interconnect component, later in this document.

Feature summary

Completely configurable from the OpenBus System document

1-to-n multiplexing (1 slave interface port, multiple master interface ports)

Ability to control decode address width, with comparator hardware generated automatically

Ability to define specific mapping into processor address space

8-, 16- and 32-bit slave peripheral support

Placing an Interconnect component

As with all OpenBus components, the Interconnect component resides on, and is placed from, the OpenBus Palette panel.

Simply click on the entry for the component, in the Connectors region of the panel. The component will appear floating on the

cursor ready for placement in the OpenBus System document (*.OpenBus).

Simply position the component at the required location in the workspace and click to effect placement.

While floating on the cursor, the component can be rotated or flipped:

Press the Spacebar to rotate the component. Rotation is anti-clockwise and in steps of 90.

Press the X or Y keys to flip the component along the X-axis or Y-axis respectively.

TR0170 (v2.0) March 04, 2008 1


2/15

OpenBus Interconnect Component Reference

Figure 1. Place an Interconnect component directly from the OpenBus Palette panel.

Although each OpenBus component has a designator, it is not a designator in the schematic sense of the word. There is no

notion of annotation in the OpenBus System document. Rather, it is simply unique comment text. This text will initially be thename of the component as used in the schematic world, along with a suffix to distinguish multiple instances (e.g.

WB_INTERCON_1). Change this text to a more meaningful descriptor as required, but make sure the text of multiple instances of

the same component are unique. For example an Interconnect component linked to a processor's IO port might be designated

INTERCON_IO, while an Interconnect component linked to the processor's MEM port might be designated INTERCON_MEM.

Editing an Interconnect component

Configuration aside, there are three 'areas' of the Interconnect component that can be edited:

Its location

Its ports

Its standard component properties, including user-defined parameters.

The following sections take a closer look at each of these three areas.

Editing location

To change the location of an Interconnect component within the workspace, simply click anywhere on the component away

from its ports and drag to reposition it. The component can be rotated or flipped while dragging.

The components' designator and user-defined parameter text fields can be graphically edited independently of the component

(Figure 2). Such text can be relocated as required. Simply click on the text and drag it. A text field can be rotated and/or flipped

as necessary.

The size of the text cannot be modified graphically. This property, including font type, must be defined as part of the object's

properties, accessed through the OpenBus Inspector or OpenBus List panels.

If the Enable In-Place Editing option is enabled on the

Schematic General page of the Preferencesdialog (DXP Preferences), you will be able to edit the value for the

designator or user-defined parameter directly in the

workspace. Simply select the text object and then click once

to invoke the feature. Type the new value as required and

then click away from the text object or press Enter to effect

the change.

Figure 2. Example associated designator and parameter text objects.

If you attempt to move an Interconnect component or

associated text object that has its Locked property enabled,

a dialog will appear asking for confirmation to proceed with

the edit.

If the Protect Locked Objects option is enabled on the Schematic Graphical Editing page of the Preferencesdialog, and

the Interconnect component or associated text object has its Locked property enabled also, then you will be prohibited fromselecting the component/text object. Editing will therefore not be possible.

2 TR0170 (v2.0) March 04, 2008


3/15


Editing ports

The OpenBus Editor provides various features and commands for the manipulation of ports with respect to an Interconnect

component. The following sections look at the management of ports for a placed Interconnect component how they can be

added and removed, and how they can be rearranged with respect to their order.

Port addition/removal

When you initially place an Interconnect component it will have a default number of ports specifically one master port (m0) and

one slave port (s0)

It is highly likely that you will have more than one I/O peripheral in your design,

requiring connection to a processor through an Interconnect component. There may

also be a series of slave memory devices that will be accessed by the processor, again

through use of an Interconnect device. Such an Interconnect component will therefore

have to be modified to have the correct number of ports.

Figure 3. Adding a port to an Interconnect

component.

To add a port, simply click on the button on the OpenBus toolbar (or use the Place

Add OpenBus Port command). A dimmed port shape will appear floating on the

cursor. As you move the shape next to the perimeter of an Interconnect component, it

will become solid darker gray with a blue outline (Figure 3). Position the new port as

required and click to effect placement.Ports can also be clustered into groups around an Interconnect component. Up to four

cluster groups are possible (analogous to the four main points on a compass). To add a

new port to an existing group, ensure you place the port directly next to an existing port in that group (Figure 4).

Figure 4. Clustering ports into groups.

To remove a port, simply click to select it in the workspace, then press the Delete key. The port will be removed from the

Interconnect component, providing such removal is valid. Interconnect components must always have at least one master and

one slave port, which cannot be removed.

Rearranging ports

You may find, during the course of wiring up the OpenBus components, that certain ports could be better placed to ease wiring

and make the system more readable. For an Interconnect component, you may want to cluster groups of ports differently after

initial port addition. The OpenBus Editor provides the ability to change the location of a port (or ports) around a component.

To change the location of a port, simply click on the port and drag it to the required location on the perimeter of its parent

component. Figure 5 illustrates this for an Interconnect component.

TR0170 (v2.0) March 04, 2008 3


4/15


5/15


Editing component properties

In a Schematic document, all placed objects have an associated properties dialog, typically accessed from the right-click context

menu or by double-clicking directly on the object. In an OpenBus System document, there are no such properties dialogs.

Viewing and editing of properties relating to an object - which will be mostly graphical in nature are carried out using the

OpenBus Inspector or OpenBus List panels. These panels can be opened using the OpenBus panel access button, to the

bottom-right of the main design window.

Figure 6 illustrates these panels for an Interconnect component selected within an example OpenBus System.

Figure 6. View and modify properties for a selected Interconnect component directly in either the OpenBus Inspector or OpenBus List panels.

The OpenBus Inspector panel also offers quick, efficient editing of parameters across multiple components in the OpenBus

System document. For more complex control over the update of parameters across the entire FPGA design project including

components on both top-level schematic and underlying OpenBus System document, use the Parameter Editor Table For

Projectdialog (Tools Parameter Manager).

User-defined filtering

The OpenBus Inspector and OpenBus List panels enable you to interrogate and edit the properties of one or more selected

objects either in the current OpenBus System document, or across all open OpenBus System documents. When used in

conjunction with appropriate filtering, these panels enable you to target and edit multiple objects of the same kind with greater

accuracy and efficiency. Such user-defined filtering can be achieved through use of the OpenBus Filter panel accessed from

the same menu as all other OpenBus-related panels. The OpenBus Filter panel allows you to construct filters through the

creation of logical queries.

Figure 7 illustrates use of the OpenBus Filter panel to quickly select all Interconnect components in an example OpenBus

System, using the query expression OpenBusComponentKind = 'Interconnect'. This is a simple example, and the two

Interconnect components could easily have been selected manually. Imagine however, if there had been several OpenBus-

based projects and you wanted to change a property common to all Interconnect components in a single sweep now that's

where use of the filter comes into its own, with the change made courtesy of the OpenBus Inspector or OpenBus List panels.

TR0170 (v2.0) March 04, 2008 5


6/15


Figure 7. Filtering multiple similar objects using the OpenBus Filter panel and a well-defined query.

Configuring the Interconnect component

Configuration of an Interconnect component is performed using the Configure OpenBus Interconnectdialog (Figure 8). Access

this dialog by right-clicking over the component and choosing the Configure command from the menu that appears. Alternatively,

double-click on the component to access the dialog directly.

Figure 8.Configuration dialog for the Interconnect component.

Use this dialog to define the slave devices that you wish to connect to the processor. If you are familiar with configuration of the

WB_INTERCON component in the schematic world, you will appreciate the reduced level of information required to configure

the Interconnect component. The OpenBus System handles much of the configuration for you, so information such as data bus

width, addressing mode and device type are no longer defined manually.

There is no manual addition/deletion of slave devices to/from the Interconnect. If a link exists between a slave peripheral device

and the Interconnect component, then that device will automatically be added and appear listed in the dialog.

There is no manual definition of the Master Address Size. This too is taken care of in the background, dependent on which port

of the processor the Interconnect is linked IO (24-bit) or MEM (32-bit).

6 TR0170 (v2.0) March 04, 2008


7/15


There are, in fact, only three pieces of information required to complete the configuration of the Interconnect for each slave

device Address, Number of bits to decode and Size. Default information for each comes directly from the linked peripheral

component itself.

Address

This address (also referred to as the Base Address) is used to map the slave device into a processor's address space (either

peripheral I/O or external memory). The size of the address depends on whether the device linked to the Interconnect is slave

peripheral I/O or slave memory:

For a slave peripheral I/O device, it is a 24-bit value, entered as a 6-digit hexadecimal number. As the processor peripheral

I/O space is in the range 0xFF000000 to 0xFFFFFFFF, the entry in the dialog includes the top byte 0xFF prefix as a

guiding reminder of this.

For a slave memory device, the base address is a 32-bit value, entered as an 8-digit hexadecimal number.

When adding slave peripheral I/O devices, default base addresses are assigned, starting at 0xFF000000 for the device

connected to port m0 and incremented in steps of 0x10000. When adding slave memory devices, addresses are assigned

starting at 0x01000000 for the device connected to port m0 and incremented in steps of 0x1000000. You must specify

Address values for each device, in accordance with design requirements.

Care should be taken when defining base addresses for memory devices, as it is possible to specify invalid addresses. If an

address lower than 0x01000000 is supplied, then the device will never be selected because the internal processor decoderroutes all such addresses to the processor's Internal Memory space. Such addresses will therefore never appear on the

processor's External Memory interface.

Number of bits to decode

This value (also referred to as the Decode Address Width) determines how many bits of the incoming address line, from the

processor, are used to identify and select the correct slave device for subsequent communications.

At a high level, if you visualize the Interconnect component in terms of a multiplexer, then a slave device will be accessed by the

processor over the single bus interface when it is selected for communications. This selection is achieved by comparing the n

(number of bits to decode) top bits of the address written by the processor, with the n top bits of the Base Address defined for

each slave device. When a match is found, the processor begins communications with that slave immediately. The required n-

bit comparators one per attached slave device are generated automatically during the synthesis phase.

At a low level, when communication between devices takes place over a Wishbone Bus, it is the STB_O and CYC_O lines thatinitiate the start of a valid data cycle and transfer. The bus from the processor is connected through to each master port on the

Interconnect component. The STB_O and CYC_O lines of each port are conditioned to only go active if:

the corresponding STB_I and CYC_I lines of the Interconnect's slave port are High AND

the associated comparator for the interface yields a High output as a result of address bit comparison.

To illustrate this, consider an OpenBus System in which three slave peripheral I/O devices are connected to a processor

through an Interconnect component. 2 bits are used to decode the incoming address from the processor. Table 1 lists the three

devices, along with their base addresses and the value that will cause the associated comparator to give a High output.

Table 1. Example address decoding.

Peripheral Device linked to

Interconnect port...

Base Address Number of bits

to decode

Comparator gives High

when top 2 bits are...

m0 0xFF00_0000 2 00

m1 0xFF40_0000 2 01

m2 0xFF80_0000 2 10

Figure 9 illustrates more closely what is going on inside the Interconnect component with regards to the role of the comparator

for each slave device interface. Only STB and CYC signals are shown, all other bus signals have been excluded for clarity.

TR0170 (v2.0) March 04, 2008 7


8/15


=

Slave Ports0

MasterPortm0

ADR_I[23..22]

00

STB_I

CYC_I

STB_O

CYC_O

=Master

Portm1

ADR_I[23..22]

01

STB_I

CYC_I

STB_O

CYC_O

=Master

Portm2

ADR_I[23..22]

10

STB_I

CYC_I

STB_O

CYC_O

Figure 9. Address decoding for slave devices attached to an Interconnect component.

The number of address decode bits specified determines the number of slave devices that can be connected to the Interconnect

component. For n bits, 2n

devices can be addressed. For example, if you specify 3 bits, the resulting 8 possible values allow for

8 slave devices to be attached to the Interconnect component.

Using a smaller number of bits for comparison will lower the hardware overhead, but also limit the number of slave devices that

can be used. The optimal scenario would be to make the decode address width as small as possible while allowing enough

slave devices to be added to the Interconnect component, in accordance with design requirements.

8 TR0170 (v2.0) March 04, 2008


9/15


For each peripheral I/O and memory device supported for use in an OpenBus System design, the number of address decode

bits is set, by default, to 8. In terms of decoding, this means:

For peripheral I/O devices, the top 8 bits of the address from the processor (ADR_I[23..16]) are compared against the top 8

bits of the 24-bit value defined for each device's Base Address.

For memory devices, the top 8 bits of the address from the processor (ADR_I[31..24]) would be compared against the top 8

bits of the 32-bit value defined for each device's Base Address.

Address decode bits vs Base Address a juggling act

As previously mentioned, you should try to set the number of address decode bits to a value that will adequately cover the

number of slave devices you wish to link to the Interconnect component. The simple approach is to take the number of slaves

and consider the number of address decode bits, n, that will provide at least this number when inserted into the expression

slaves = 2n. So:

2 slaves requires 1 decode bit

3 -4 slaves require 2 decode bits

5-8 slaves require 3 decode bits

9-16 slaves require 4 decode bits, and so on.

You must also consider which base addresses to assign each slave device, in conjunction with the number of address decodebits. Certain addresses may never get selected if they are not spaced adequately in the processor's address space.

How decode bits affect memory addressing

Before looking at specific examples of specifying too few or too many address decode

bits, it is worth looking at how the use of address decoding impacts on where in

processor memory a device is addressed.

If a slave peripheral is connected directly to the IO port of a processor in an OpenBus

System, with no Interconnect component, that device will be mapped repeatedly

throughout the entire processor Peripheral I/O space. The reason is that with no decode

bits, all addresses will select the device. Figure 10 illustrates this for a port peripheral,

GPIO, that has a base address of 0xFF00_0000.

Now consider the same peripheral, but this timeconnected to the processor via port m0 of an

Interconnect component. Let's assume the

same base address (0xFF00_0000) and the

use of 1 decode bit. The peripheral will be

selected for communications if the top bit of the address line and the top bit of the

device's base address are both 0. Figure 11 illustrates how the processor's Peripheral

I/O space will now look.

GPIO

GPIO

GPIO

GPIO

GPIO

.

.

.

0xFF00_0000

0xFFFF_FFFF

Figure 10. Single peripheral mapped intoaddress space with no Interconnect used.

GPIO

GPIO

.

.

GPIO

0xFF00_0000

0xFFFF_FFFF

0xFF7F_FFFF

0xFF80_0000

Figure 11. Single peripheral mapped intoaddress space using an Interconnect and

1 decode bit.

This time, as the device is only selected when the top address bit is 0, it is repeated only

in the lower half of the address space. Notice that if you wanted to add a second slave

device, you would need to give it a base address that started anywhere from

0xFF80_0000 and above. To give it a base address lower than this would result in it

not being selected, as the two devices would each have an address with a top bit of 0.

GPIO

GPIO

.

.

0xFF00_0000

0xFFFF_FFFF

0xFF3F_FFFF

0xFF40_0000

.

.

Figure 12. Single peripheral mapped intoaddress space using an Interconnect and2 decode bits.

If we take the number of decode bits to 2, we can see (Figure 12) that the peripheral is

still repeated, but in a much more constricted area of memory. In fact, you can see the

pattern add an extra decode bit and we effectively shrink the area into which that

device is mapped. With 2 decode bits, should you wish to now add a second peripheral

device, you would give it a base address anywhere from 0xFF40_0000 and above.

Armed with a better understanding of how base addresses and decode bits work hand-

in-hand to correctly map the physical devices in an OpenBus System, you should be

able to avoid the pitfalls of using too few or too many decode bits. Let's take a look at an

example of each case however, to underline the importance of setting appropriate

decoder widths and device base addresses.

TR0170 (v2.0) March 04, 2008 9


10/15


Specifying too few decode bits

For this example, let's assume the following devices are attached to a processor via an Interconnect component:

Port m0 port peripheral (GPIOA), with base address 0xFF00_0000

Port m1 port peripheral (GPIOB), with base address 0xFF10_0000

Port m2 port peripheral (GPIOC), with base address 0xFF20_0000

For simplicity, lets assume each peripheral is 1KB in size. The number of bits to decode in each case is set to 2.

Figure 13 shows the mapping of such devices in the processor's Peripheral I/O

space.

0xFF00_0000

0xFFFF_FFFF

0xFF10_0400

0xFF20_0400

GPIOA

GPIOB

GPIOC

0xFF10_0000

0xFF00_0400

0xFF20_0000

Figure 13. Example devices mapped into Peripheral

I/O space.

Looking at the top 2 bits of each device's base address, we have:

GPIOA 00

GPIOB 00

GPIOC 00

From this, we can see that upon synthesis, the decode address for each

device would be the same, 00. We have clearly not used enough decode bits

to provide unique decode addresses for each device. So just how many should

we use? Let's look at the top nibble of each device's base address:GPIOA 0000

GPIOB 0001

GPIOC 0010

From this, we can see that using 3 decode bits would still not be enough as

that would result in GPIOA and GPIOB both having decode addresses of 000.

If we use 4 decode bits, we could guarantee uniqueness of decode addresses

between devices.

Of course, we could leave the 2 decode bits and simply change the base

addresses for the devices, to give them greater separation in the address

space. So to gain unique decode addresses using top 2 bits only, addresses

could be changed to:GPIOA 0xFF00_0000

GPIOB 0xFF40_0000

GPIOC 0xFF80_0000.

0xFF00_0000

0xFFFF_FFFF

0xFF80_0000

0xFF70_0400

GPIOA

GPIOB

0xFF00_0400

0xFF70_0000

Figure 14. Example devices mapped into PeripheralI/O space.

Note: To avoid the possibility of devices never being decoded for

communications, the Configure OpenBus Interconnectdialog allows you to

define a decoding 'order of priority'. Use the (increase priority) and

(decrease priority) buttons in the dialog to reorder the device entries. Highest

decoding priority is given to a device at the top of the list.

Specifying too many decode bits

For this example, let's assume the following devices are attached to a

processor via an Interconnect component:

Port m0 port peripheral (GPIOA), with base address 0xFF00_0000

Port m1 port peripheral (GPIOB), with base address 0xFF70_0000

For simplicity, lets assume each peripheral is 1KB in size. The number of bits

to decode in each case is set to 15.

Figure 14 shows the mapping of such devices in the processor's Peripheral I/O

space.

Looking at the top 15 bits of each device's base address, we have:

GPIOA 000000000000000

GPIOB 011100000000000

At first sight, these are both unique decode addresses. We are, however, onlyconsidering the base address of each device. Remember that each device is

10 TR0170 (v2.0) March 04, 2008


11/15


1KB in size. Let's consider the top 15 bits of the upper limit of each device's memory allocation:

GPIOA (0xFF00_0400) - 000000000000010

GPIOB (0xFF70_0400) - 011100000000010

These addresses are outside of those selectable using the respective 15-bit decode addresses (generated from the base

addresses). In fact, we can determine that the following address ranges for each device will not be selectable:

For GPIOA addresses in the range 0xFF00_0200 to 0xFF00_0400

For GPIOB addresses in the range 0xFF70_0200 to 0xFF70_0400

We know that using too few address decode bits can lead to devices not being selected at all. At the other end of the spectrum,

using too many address decode bits restricts the size of each device. Remember that as you add an extra decode bit, the range

in address space selectable using the device's decode address is reduced. Too many bits therefore results, as we have seen, in

a selectable space that is too narrow to fit the 1KB devices.

The remedy in this example is simply to reduce the number of address bits. Looking at the top bits of the base addresses,

unique decode addresses can be gained using 2 decode bits.

Size

This value (also referred to as Address Bus Size) defines the number of address bits required to drive the connected slave

device. For OpenBus components (peripherals and memory controllers) this information is sourced automatically from thecomponent itself and typically should not need to be modified.

TR0170 (v2.0) March 04, 2008 11


12/15


13/15


Connecting multiple memory devices

The nature of your FPGA design may

warrant the use of several memory devices,

possibly of differing type, each of which

requires to be mapped into a specific

location within the processor's addressspace. Within the OpenBus System, this

can be readily achieved through use of an

Interconnect component.

Figure 17 illustrates the use of an

Interconnect component to connect to

SRAM, SDRAM and Block RAM, via the

corresponding, and appropriately-

configured, memory controllers.

Connecting multipleperipheral I/O devices

Typically in an FPGA design, theprocessor will need to interface to multiple

peripheral I/O devices, many of which are

interfacing controllers for communicating

with external devices or circuitry. Each of

these peripherals may contain any number

of internal registers with which to write

to/read from. It is not possible to

communicate directly, and simultaneously,

with each of these slave devices. A means of multiplexing must be used, allowing the processor to talk to any number of slaves

over the one bus interface. Again, this can be achieved using an Interconnect component within the OpenBus System.

Figure 17. Multiplexing a processor's external memory interface using an Interconnectcomponent.

In the example system of Figure 18, the Interconnect component enables a single 32-bit processor (MicroBlaze) to

communicate with three peripheral I/O devices (a Parallel Port Unit, a PS2 Controller and a 32-bit Ethernet Media AccessController).

Figure 18. Multiplexing a processor's peripheral I/O interface using an Interconnect component.

TR0170 (v2.0) March 04, 2008 13


14/15


Sharing slave devices between processors

Some FPGA designs may require shared processor access to one or more slave memory or peripheral I/O devices. In the

OpenBus System, this is catered for by using both an Interconnect component and an Arbiter component. These devices

facilitate connection of two (or more) processor masters to a whole bank of slave devices. The devices would be mapped into

the respective processor address spaces at identical locations. The following figures show examples of using Interconnect and

Arbiter components to allow two TSK3000A processors to access a variety of physical slave memory (Figure 19) and peripheral

I/O (Figure 20) devices.

Figure 19. Sharing multiple slave memory devices between two processors.

Figure 20. Sharing multiple slave peripheral I/O devices between two processors.

14 TR0170 (v2.0) March 04, 2008


15/15


For further information on the Arbiter component, refer to the document TR0171 OpenBus Arbiter Component Reference.

For more information on the concepts and workings of the OpenBus System, refer to the article AR0144 Streamlining

Processor-based FPGA design with the OpenBus System.

Revision History

Date Version No. Revision

05-Nov-2007 1.0 Initial release

04-Mar-2008 2.0 Updated for Altium Designer Summer 08

Software, hardware, documentation and related materials:

Copyright 2008 Altium Limited.

All rights reserved. You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or

posted on any network computer or broadcast in any media, and (2) no modifications of the document is made. Unauthorized duplication, in

whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in

published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be

prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium, AltiumDesigner, Board Insight, Design Explorer, DXP, LiveDesign, NanoBoard, NanoTalk, P-CAD, SimCode, Situs, TASKING, and Topological

Autorouting and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. All other registered or

unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed.

TR0170 (v2.0) March 04, 2008 15
http://tr0171%20openbus%20arbiter%20component%20reference.pdf/http://ar0144%20streamlining%20processor-based%20fpga%20design%20with%20the%20openbus%20system.pdf/http://ar0144%20streamlining%20processor-based%20fpga%20design%20with%20the%20openbus%20system.pdf/http://ar0144%20streamlining%20processor-based%20fpga%20design%20with%20the%20openbus%20system.pdf/http://ar0144%20streamlining%20processor-based%20fpga%20design%20with%20the%20openbus%20system.pdf/http://tr0171%20openbus%20arbiter%20component%20reference.pdf/

tr0170 openbus interconnect component reference

Documents