OpenBus Interconnect Component Reference

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

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 the name 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 Preferences dialog (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. 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.
Figure 2. Example associated designator and parameter text objects.

If the Protect Locked Objects option is enabled on the Schematic Graphical Editing page of the Preferences dialog, and the Interconnect component or associated text object has its Locked property enabled also, then you will be prohibited from selecting the component/text object. Editing will therefore not be possible.

TR0170 (v2.0) March 04, 2008

OpenBus Interconnect Component Reference

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. 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.

Figure 3. Adding a port to an Interconnect component.

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

OpenBus Interconnect Component Reference

Figure 5. Rearranging ports around an Interconnect component.

TR0170 (v2.0) March 04, 2008

OpenBus Interconnect Component Reference

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 Project dialog (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 OpenBusbased 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

OpenBus Interconnect Component Reference

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 Interconnect dialog (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).

TR0170 (v2.0) March 04, 2008

OpenBus Interconnect Component Reference 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 decoder routes 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 nbit 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 that initiate 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... m0 m1 m2

Base Address 0xFF00_0000 0xFF40_0000 0xFF80_0000

Number of bits to decode 2 2 2

Comparator gives High when top 2 bits are... 00 01 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

OpenBus Interconnect Component Reference

STB_I STB_O ADR_I[23..22]

=
00 CYC_O CYC_I

Master Port m0

STB_I STB_O ADR_I[23..22] Slave Port s0 01 CYC_O CYC_I

Master Port m1

STB_I STB_O ADR_I[23..22]

=
10 CYC_O CYC_I

Master Port m2

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 n component. For n bits, 2 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.

TR0170 (v2.0) March 04, 2008

OpenBus Interconnect Component Reference 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 n slaves = 2 . 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 decode bits. 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.
0xFFFF_FFFF
GPIO 0xFFFF_FFFF

. . .
GPIO GPIO GPIO

0xFF80_0000 GPIO . . GPIO GPIO 0xFF00_0000 0xFF7F_FFFF

Now consider the same peripheral, but this time GPIO connected to the processor via port m0 of an 0xFF00_0000 Interconnect component. Let's assume the Figure 10. Single peripheral mapped into same base address (0xFF00_0000) and the address space with no Interconnect used. 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. 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.
0xFFFF_FFFF

Figure 11. Single peripheral mapped into address space using an Interconnect and 1 decode bit.

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 handin-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.
. . GPIO . . GPIO

0xFF40_0000 0xFF3F_FFFF 0xFF00_0000

Figure 12. Single peripheral mapped into address space using an Interconnect and 2 decode bits.

TR0170 (v2.0) March 04, 2008

OpenBus Interconnect Component Reference

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. 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. Note: To avoid the possibility of devices never being decoded for communications, the Configure OpenBus Interconnect dialog 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
0xFF70_0400 0xFF80_0000 0xFFFF_FFFF
0xFF10_0400 0xFF20_0400 0xFFFF_FFFF

GPIOC
0xFF20_0000

GPIOB
0xFF10_0000

0xFF00_0400

GPIOA
0xFF00_0000

Figure 13. Example devices mapped into Peripheral I/O space.

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, only considering the base address of each device. Remember that each device is

GPIOB
0xFF70_0000

0xFF00_0400

GPIOA
0xFF00_0000

Figure 14. Example devices mapped into Peripheral I/O space.

10

TR0170 (v2.0) March 04, 2008

OpenBus Interconnect Component Reference 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 the component itself and typically should not need to be modified.

TR0170 (v2.0) March 04, 2008

11

OpenBus Interconnect Component Reference

Using the Interconnect in an OpenBus System - Examples

The Interconnect component can, as previously discussed, be used to connect to one or more slave memory or peripheral I/O devices. The following sections provide examples of where the Interconnect component can be used in an OpenBus System.

Connecting single slave devices

Although a single memory or peripheral I/O device can be connected directly to the respective MEM or IO port of the processor, use of an Interconnect component simplifies matters. Without an Interconnect component, there are a few limitations to note and appreciate: By not using an Interconnect, you will only be able to directly connect a single peripheral to the processor's IO and/or MEM port. With no handling of the data bus widths, only a 32-bit peripheral can be attached to the processor's IO port. The Interconnect component is the only place where you can define the base address for the memory or peripheral I/O device. Mapping of devices into processor address space can not be performed from the processor's associated configuration dialogs. As a result, you will be restricted to a base address of 0xFF000000 for a peripheral I/O device, and 0x01000000 for a memory device.

Figure 15 shows the use of an Interconnect component to connect external memory (SRAM) to the MEM port of a TSK3000A processor. The physical SRAM is connected to the Interconnect via an appropriately-configured SRAM Controller.

Figure 15. Using an Interconnect component to connect to a single

For further information on the SRAM Controller physical memory. peripheral, refer to the core reference CR0152 WB_MEM_CTRL Configurable Wishbone Memory Controller. Figure 16 shows similar use of an Interconnect component to connect a single slave peripheral I/O device (an IEEE754 Floating Point Unit) to the IO port of a TSK3000A processor.

Figure 16. Using an Interconnect component to connect a single slave I/O peripheral.

12

TR0170 (v2.0) March 04, 2008

OpenBus Interconnect Component Reference

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 address space. 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 appropriatelyconfigured, memory controllers.

Connecting multiple peripheral I/O devices

Typically in an FPGA design, the processor 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 Figure 17. Multiplexing a processor's external memory interface using an Interconnect component. 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. 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 Access Controller).

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

TR0170 (v2.0) March 04, 2008

13

OpenBus Interconnect Component Reference

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

OpenBus Interconnect Component Reference 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 05-Nov-2007 04-Mar-2008 Version No. 1.0 2.0 Revision Initial release 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, Altium Designer, 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