Implementing AHB Peripherals in Virtex 4 and Virtex 5 Logic Tiles

Application Note 170



Release information

The following changes have been made to this Application Note.

Change history

Date

Issue

Change

June 21, 2006

A

First release

April 25, 2007

B

Added support for Virtex 5 Logic Tiles

Proprietary notice

ARM, the ARM Powered logo, Thumb and StrongARM are registered trademarks of ARM Limited.

The ARM logo, AMBA, Angel, ARMulator, EmbeddedICE, ModelGen, Multi-ICE, LT-XC4VLX100+, TDMI and STRONG are trademarks of ARM Limited.

All other products, or services, mentioned herein may be trademarks of their respective owners.

Confidentiality status

This document is Open Access. This document has no restriction on distribution.

Feedback on this Application Note

If you have any comments on this Application Note, please send email to errata@arm.com giving:

·         the document title

·         the document number

·         the page number(s) to which your comments refer

·         an explanation of your comments.

General suggestions for additions and improvements are also welcome.

ARM web address

http://www.arm.com


1                   Introduction

1.1             Purpose of this application note

 

The Versatile families of ARM development boards enable customers to implement AMBA AHB masters and slaves.

AMBA AHB is a specification intended for an internal bus, in which all masters and slaves are inside an ASIC or FPGA.

In AHB the outputs from all the masters are multiplexed, so that only the master that has been granted the bus can access it. Similarly, the outputs from all the slaves are multiplexed, so that only the slave that is being accessed puts its response on the bus.

 

This kind of approach is not appropriate in a modular development system, in which different masters and slaves are in different chips or even boards. Implementing AHB in a system like this would require a huge number of signals connecting the chips and boards.

In order to solve this problem, ARM development boards implement a tri-state version of the AHB bus.

 

This application note explains the tri-state implementation of AHB and shows how to implement AHB masters and slaves in Virtex 4 and Virtex 5 logic tiles, so that they can be connected to the PB926EJ-S M1, M2 and S buses.

The application note also includes working example Verilog, pre-built FPGA configuration images and test software for the peripherals in the logic tile.

 

This revision of the application note includes information and example HDL for the following configuration:

·         A typical Versatile system, with a PB926EJ-S baseboard and a Virtex 4 or a Virtex 5 logic tile


1.2             Getting Started

When using this application note with a baseboard, ensure that the baseboard is programmed and functioning correctly first. Refer to the relevant documentation for further information (for example PB926EJ-S user guide). Once you have done this please follow these steps to program the FPGA image in the Virtex 4 or Virtex 5 Logic Tile with the image provided with this application note.

 

1.       Plug the Logic Tile on the PB926EJ-S Logic Tile site.

2.       Fit the CONFIG jumper link on the PB926EJ-S (J32).

3.       Connect RVI to the to the JTAG ICE connector (PB926EJ-S J31), or a USB cable to the PB926EJ-S USB Debug Port (J30).

4.       Connect +12V to J28 on the PB926EJS board (positive on center pin, +/-10%, 35W).

5.       Power-up the boards. The '3V3' and ‘5V’ LEDs should both be lit.

6.       If using the USB connection, ensure that your PC has correctly identified an ARM® RealView™ ICE Micro Edition device is connected to the USB port. If the Windows operating system requires a USB driver to be installed please refer to PB \boardfiles\USB_Debug_driver\readme.txt.

7.       If using Real View ICE (RVI), you must ensure that the RVI unit is powered and has completed its start-up sequence (check the LEDs on the front panel have stopped flashing).

 

8.       You can now run the relevant ‘progcards’ utility for the connection you have prepared above.

 

 

9.        Select the FPGA image you wish to program into the Logic Tile. The progcards utility will report its progress as the image is programmed into the tile and verified (this may take several minutes for a large image). A successful download will be terminated with the message “Programming Successful”.

10.   Power down the boards.

11.   Set the configuration switches to load Logic Tile FPGA image 1 (on the Logic Tile set switch S2:1 OFF and S2:2 ON).

12.   Remove the CONFIG jumper link, and power-up the boards. Ensure the 'FPGA_OK’ (Logic Tile D12) LED is lit. On the PB926EJ-S the Character LCD should show the Firmware and Hardware versions indicating that the Boot monitor firmware is running.

13.   The system will now be fully configured and ready for use.

 


Tri-state AHB implementation in ARM development boards

 

Figure 1 shows a typical implementation of an AHB system inside an ASIC. This AHB system consists of three masters and three slaves.

The left block diagram shows how the outputs of the masters are multiplexed. The output of the multiplexer is routed to the inputs of the slaves. The multiplexer is controlled by the system arbiter, so only one master accesses the bus at one time.

The right block diagram shows how the outputs of the slaves are multiplexed. The output of the multiplexer is routed to the inputs of the masters. The multiplexer is controlled by the system address decoder, so only one slave is accessed at one time. 

 

Image

Figure 1: AHB masters and slaves in an ASIC

 

Figure 2 shows how the same system would normally be implemented with development boards. It is important to note that conceptually this implementation in development boards is exactly the same as the implementation in the ASIC.

In this type of system the system bus is routed to all the boards in the system, and is accessed with tri-state buffers. In this example configuration the design is split into three boards.

 

The left block diagram shows how the outputs from the masters are routed to the system bus.

If there is only one master in a board, the board tri-state multiplexers are enabled when that master is granted the bus.

If there are two or more masters in a board, their outputs are multiplexed. The board tri-state buffers are enabled when one of the masters in the board is granted the bus.

The signals from the system bus drive the inputs of the slaves directly.

It is important to note that there must be a single system bus arbiter which grants the bus to the different masters. This is the only way to guarantee that only one master accesses the bus at a given time.

 

The way slaves access the system bus is equivalent, as shown in the right block diagram.

The main difference is that there is only one arbiter in the whole system, but there is one address decoder in each one of the boards that implement slaves.

Each address decoder must check if one of the slaves in the board is being accessed. If that is the case, it must enable the tri-state buffers that give access to the system bus. This must be done at the correct phase of the access.

If there are two or more slaves in the same board, the decoder must also control the multiplexing of their outputs.

 

Image

Figure 2: AHB masters and slaves in development boards

 

The example in Figure 2 is only one possible implementation of this system in development boards. There are several alternatives to this configuration, which are explained later in this document.


 

1.3             Accessing the AHB system bus with tri-state buffers

 

Since AHB is a pipelined bus, the arbitration, address and data phases of each transfer happen in different cycles. The control logic for the tri-state buffers must take this into account, so that the buffers are enabled in the correct clock cycle.

Figure 3 shows the arbitration, address and data phases in an AHB transfer.

 

Image

Figure 3: Phases in an AHB transfer with no wait states

 


Figure 4 shows how to connect the signals from the tri-state system bus to the AHB masters in a logic tile.

The master inputs HRESP and HREADY are connected directly from the system bus. HRDATA is connected directly to HDATA in the system bus. HDATA contains the data read from a slave during a read cycle.

The master outputs, HADDR and control signals, are multiplexed and drive the signals of the system bus with tri-state buffers. These buffers are enabled if one of the masters in the logic tile is granted the bus during the address phase of this cycle.

HDATA is driven by HWDATA with a tri-state buffer. This buffer is enabled when one of the masters in the logic tile is granted the bus during the data phase of this cycle, and if the current access is a write access.

 

Image

Figure 4: Connections of AHB masters

 


Figure 5 shows how to connect the signals from the tri-state system bus to the AHB slaves in a logic tile.

The address and control signals, which are slave inputs, are connected directly from the system bus.

HREADYIn is connected directly to HREADY from the system bus. HREADYIn indicates if the last transfer in the system bus has finished, so it is needed by all the AHB slaves.

HWDATA is connected directly to HDATA in the system bus. HDATA contains the data written by a master into a slave during a write cycle.

The slave outputs HRESP and HREADY are multiplexed and drive the signals of the system bus with tri-state buffers. These buffers are enabled if one of the slaves in the logic tile is accessed during the address phase of this cycle.

HDATA is driven by HRDATA with a tri-state buffer. This buffer is enabled when one of the slaves in the logic tile is accessed during the data phase of this cycle, and if the current access is a read access.

 

 

Image

Figure 5: Connection of AHB slaves

 


In some systems both masters and slaves are connected to the same system bus, so the HRDATA and HWDATA signals must also be multiplexed. This is shown in Figure 6.

HDATA is driven from HRDATA when HWRITE is low during the data phase of the current cycle. Otherwise HDATA is driven from HWDATA.

The tri-state buffers that gives access to HDATA on the system bus is enabled only if a logic tile master is granted the bus and it is a write cycle, or if a logic tile slave is accessed and it is a read cycle.

 

Image

Figure 6: Multiplexing HRDATA and HWDATA into HDATA

 

 

 

 

 

2                   Using logic tiles with PB926EJ-S

2.1             The Versatile family of boards

 

A Versatile system normally consists of:

·         A Versatile baseboard, such as the PB926EJ-S. This board contains a development chip with the ARM processor, a bus matrix and a number of peripherals. On the board there is volatile and non-volatile memory, and also an FPGA, which implements more peripherals.

·         One or more logic tiles, which can be configured to implement hardwired logic, AHB peripherals or synthesizable cores.

 

The development chip on the PB926EJ-S interfaces external peripherals with three external buses:

·         AHB M1 is an external master bus, so the development chip behaves as a bus master. The AHB M1 is connected to the baseboard FPGA and logic tiles, but the baseboard FPGA does not connect any slave to this bus.

·         AHB M2 is an external master bus, so the development chip behaves as a bus master. The AHB M2 is connected to the baseboard FPGA and logic tiles. The baseboard FPGA has its slaves connected to this bus.

·         AHB S is an external slave bus, so the development chip behaves as a slave of the bus. The AHB S bus is connected to the baseboard FPGA and logic tiles. The baseboard FPGA has the PCI master connected to this bus.

 

The development chip is based around an internal bus matrix.

·         The AHB M1 and M2 bridges inside the development chip are slaves of the bus matrix, mapped at fixed addresses of the memory map.

·         The AHB S bridge is a master of the bus matrix, and has its own bus layer.

All masters (including external masters) have access to the M1 and M2 external buses. For details about what slaves can be accessed by each master, please see the   PB926EJ-S documentation.

 

 

2.2             PB926EJ-S buses: control signals

 

When connecting a logic tile on top of a PB926EJ-S baseboard, some signals must be driven by the logic tile.

The PB926EJ-S uses the nTILE_DET signal from the logic tile to detect if logic tiles are present or not. Some control signals for the AHB bridges are not driven by the baseboard when a logic tile is present, so they must be driven by the design in the logic tiles.

 

 

These signals are:

·         AHB M1 bus:

o        HGRANTM1: Grant signal for the AHB M1 bridge. It can be used to attach more than one master to AHB M1

o        HREADYM1 and HRESPM1: From slaves connected to AHB M1

·         AHB M2 bus:

o        HGRANTM2: Grant signal for the AHB M2 bridge. It can be used to attach more than one master to AHB M2

o        HREADYM2 and HRESPM2: From slaves connected to AHB M2. These signals must be enabled only when the master on AHB M2 accesses slaves in the logic tile

·         AHB S bus:

o        HSELS: Selection signal from the address decoder, which indicates that the AHB S bridge on the development chip is being accessed. This signal can be used to connect other slaves to the AHB S bus.

o        HMASTLOCKS: Indicates a locked transaction on the AHB S bus.

o        LTHGRANT: Grant signal for the PCI master in the PB926EJ-S FPGA.

 

2.3             PB926EJ-S buses: standard operation

 

In order to comply with the AHB specification, the slaves connected to a bus must respond to the whole range of addresses. In a system with a PB926EJ-S baseboard and one or more logic tiles this has the following implications:

·         The logic tile must respond to the 4GB address range in bus M1

·         The logic tile must respond to addresses 0x0 - 0x03FFFFFF and 0x14000000 - 0x1FFFFFFF in bus M2. These addresses are the only ones which are not mapped to any slave in the PB926EJ-S FPGA.

Normally a default slave is used to respond to the addresses not mapped to real slaves. The default slave simply drives HREADY = 1 and HRESP = ERROR, so it generates an abort when it is accessed.

 

The example HDL code provided with this application note implements a standard system in a logic tiles, consisting of the following elements:

·         Slaves connected to bus M1 and mapped at address 0xC0000000. Addresses from 0x80000000 to 0xFFFFFFFF are mapped to bus M1 inside the development chip, so these slaves are accessible from all the masters in the system.

·         Default slaves respond to accesses to other addresses in bus M1 and to addresses 0x0 - 0x03FFFFFF and 0x14000000 - 0x1FFFFFFF in bus M2.

·         Any masters implemented in logic tiles are connected to bus S. These masters can access the resources inside the development chip through the bus matrix, as well as those on buses M1 and M2.

 

 

Figure 7 shows a standard system in which the masters and slaves are synthesized in several logic tiles.

 

Image

Figure 7: Standard configuration of PB926EJ-S plus logic tiles – flow from masters to slaves

 

The figure shows how masters connected to the AHB S bus can access slaves connected to the AHB M1 and AHB M2 buses through the bus matrix.

The figure also shows which signals of the header connectors are used to route the M1, M2 and S buses:

·         AHB M1 is routed via HDRZ: This bus is routed straight up the stack, so AHB M1 can be accessed directly by all the logic tiles in the stack.

Different M1 slaves can be implemented in different logic tiles. They must access the bus with tri-state buffers. The tri-state buffers must only be enabled when the slaves in the logic tile are accessed.

·         AHB M2 is routed via HDRX: This bus is only connected to the logic tile at the bottom of the stack. This is normally not a problem since the M2 bus should only be used to access boot memory.

·         AHB S is routed via HDRY: This bus is only connected to the logic tile at the bottom of the stack.

The figure shows how to connect masters implemented in another logic tile to the AHB S bus. Since the S bus is only connected to the bottom tile, that tile needs to route the S bus up the stack using a different set of signals.

The outputs from the different masters are multiplexed in the bottom tile.

 

Note that AHB M2 and AHB S are only fully connected to the bottom logic tile if the X and Y bus switches are configured in fold-over mode.

 

With this configuration the control signals are driven the following way:

HGRANTM1 = 1, HGRANTM2 = 1

READYM1 and HRESPM1 driven by the slaves connected to AHB M1

HREADYM2 and HRESPM2 driven by the default slave connected to AHB M2

HSELS = 1

 

An arbiter must be provided to arbitrate between the masters in the logic tile and the PCI master on the PB926EJ-S FPGA. This arbiter drives LTHGRANT and HMASTLOCKS on the S bus. LTHBUSREQ and LTHLOCK are the bus request and lock signals from the PCI master, and are routed on HDRY.

 

Sometimes the user may not need to synthesize AHB masters in the logic tile. In this case the masters and arbiter can be removed. The logic tile pins should be driven as follows:

 

·         The signals on the AHB S bus which are outputs of the logic tile should be driven with high impedance.

 

·         LTHGRANT must be tied high, so the PCI master on the baseboard is always granted the bus

 

·         HMASTLOCK must be tied low

 

·         All other control signals (HGRANTM1, HGRANTM2 and HSELS) are tied in the standard way

 

2.4             PB926EJ-S buses: booting from AHB expansion bus

 

The PB926EJ-S baseboard has an option to boot from the AHB expansion bus. If this option is selected, the ARM926EJ-S begins to run code from the AHB M2 bus after reset.

If this option is selected, real non-volatile memory should be connected to bus AHB M2. This type of memory is not available on the logic tile itself, so in order to connect the FPGA to a Flash device you may need to design your own Flash board with logic tile connectors or solder a Flash device to an interface tile.

 

An easier option is to use the logic tile FPGA Block RAM to emulate non-volatile memory. In this case the block RAM must be connected to bus M2 and mapped to both addresses 0x0 - 0x03FFFFFF and 0x14000000 - 0x1FFFFFFF.

The addresses at 0x14000000 are used as an alias of block RAM. This is necessary to load the boot code, since the memory can only be accessed at address 0 when the baseboard boots from AHB expansion bus and before the memory is remapped.

The procedure to boot from AHB expansion bus is the following:

·         Boot the board from NOR Flash

·         Use a debugger or the boot monitor to load the boot image at address 0x14000000

·         Configure the baseboard’s DIP switches to boot from AHB expansion bus

·         Put the processor in run state and push the DEVCHIP RECONFIG button on the PB926EJ-S baseboard

·         This causes a reconfiguration of the ARM926EJ-S development chip, so the processor boots from the type of memory selected by the DIP switches

 

2.5             PB926EJ-S buses: connecting masters to AHB M1 and M2 buses

 

In some cases customers may not want to follow the standard configuration, but prefer to connect the logic tile masters to AHB M1 and M2.

Two possible ways to do this are shown in Figure 8:

·         AHB M1 uses a multi-layer AHB bus implementation, so the masters in the bus can access different slaves simultaneously

·         AHB M2 works as a standard AHB bus, in which all the masters are connected to the same bus

Note that both configurations work and can be used on either M1 or M2.

 

Image

Figure 8: Connecting logic tile masters to AHB M1 and M2 buses – flow from masters to slaves

 

With either of these configurations, the logic tile masters can only access slaves connected to the same bus as the masters. The logic tile masters cannot access the resources inside the development chip or on the other AHB buses.

These configurations represent how PB926EJ-S can still be used to emulate an ASIC with a single ARM processor and a standard AHB bus.

 

In Figure 8, the AHB M1 bus matrix is in charge of performing the arbitration of the masters connected to M1. In this case HGRANTM1, the grant signal for the AHB M1 bridge, can be tied high. The bus matrix drives HREADYM1 low when the AHB M1 bridge has to wait for the internal master to finish a transfer.

The logic tile M2 master accesses the AHB M2 bus with tri-state drivers. In order to avoid bus contention an arbiter must be implemented on the logic tile. This arbiter must drive the HGRANTM2 signal, which enables the outputs of the AHB M2 bridge inside the development chip.

With the configuration shown in the picture, the M2 master in the logic tile can access the slaves inside the baseboard FPGA.

 


2.6             PB926EJ-S buses: connecting slaves to the AHB S bus

 

The ARM926EJ-S development chip provides the HSELS signal so that external slaves can be connected to the AHB S bus. HSELS is routed to the logic tile headers, so that slaves on the S bus can be implemented in logic tiles.

Slaves connected to the AHB S bus can only be accessed by external masters, that is the PCI master or masters synthesized in logic tiles. They cannot be accessed by the masters inside the development chip.

·         HSELS must be 1 when an AHB S master is accessing the development chip

·         HSELS must be 0 when an AHB S master is accessing the AHB S slave

HSELS must be driven by an address decoder in the logic tile. This lets you map the AHB S slaves “on top” of the standard PB926EJ-S memory map.

 

Image

Figure 9: Connecting logic tile slaves to the S bus – flow from masters to slaves

 

Normally HSELS should be tied high and no slaves should be connected to the AHB S bus. Otherwise different masters have different memory maps, which can result in complex problems.

HSELS should only be used in very specific cases, and it requires a very good understanding of AHB and ARM technology.

 

2.7             PB926EJ-S clocks

 

The PB926EJ-S clock architecture is complex and highly configurable. The baseboard contains clock multiplexers, so that different clock signals can be used. The clock multiplexers can be configured so that the clocks are driven by either the baseboard or the logic tiles.

The HCLKCTRL bits of the SYS_CFGDATA1 register configure the clock multiplexers. This configuration must match the design in the logic tile, so that the design in the logic tile is clocked with the same signals as the AHB bridges in the development chip. Detailed information about the clock multiplexers can be found in the PB926EJ-S user guide.

 

The baseboard can be configured to generate the clocks for the M1, M2 and S buses. In this case the baseboard FPGA generates the clocks, which are connected to the logic tile on the “F2L” signals (FPGA to Logic tile). These signals are:

·         Baseboard’s HCLKM1_F2L connects to logic tile’s CLK_POS_UP_IN

·         Baseboard’s HCLKM2_F2L connects to logic tile’s ZL217

·         Baseboard’s HCLKS_F2L connects to logic tile’s CLK_NEG_UP_IN

 

The baseboard’s GLOBALCLK connects to the logic tile’s CLK_GLOBAL. This clock can be driven by either the logic tile or the baseboard. If the global clock is driven from the logic tile, then the baseboard’s driver to GLOBALCLK must be disabled. This can be done by driving the signal F2LSPARE4 high from the logic tile.

Separate clocks for the AHB M1, M2 and S buses can also be driven from the logic tile FPGA’s I/O pins. These signals are named HCLKM1_L2F, HCLKM2_L2F and HCLKS_L2F on the baseboard. “L2F” stands for “Logic tile to FPGA”.

 

CLK_POS_UP_IN and CLK_NEG_UP_IN are connected to global clock inputs of the bottom logic tile’s FPGA. ZL217 is connected to a normal I/O pin of the FPGA, which makes the AHB M2 clock routing less efficient.

 

CLK_POS_UP_IN, ZL217 and CLK_NEG_UP_IN, are only connected to the bottom logic tile. A design split into several logic tiles should not be clocked with these signals. Otherwise, the clocks must be routed through the bottom logic tile up the stack, which can cause significant clock skew.

When there is more than one logic tile in the system, the whole design must be clocked with CLK_GLOBAL, since this signal is connected to all the tiles in the system.

All the clocks inside the development chip are derived from GLOBALCLK. Therefore in this case both the maximum speed of the development chip and the design on the logic tiles impose a restriction on the frequency of GLOBALCLK.

 

When there is only one logic tile on top of the baseboard, it is recommended to use CLK_POS_UP_IN to clock the peripherals connected to AHB M1, ZL217 to clock those connected to AHB M2 and CLK_NEG_UP_IN to clock those connected to AHB S.


This provides greater flexibility, since different buses can be clocked with different clocks:

·         AHB M1 can be clocked with signals from the baseboard (OSC0 or OSC1) or from the logic tile (HCLKM1_L2F or CLK_GLOBAL)

·         AHB M2 can be clocked with signals from the baseboard (OSC0 or OSC2) or from the logic tile (HCLKM2_L2F or CLK_GLOBAL)

·         AHB S can be clocked with signals from the baseboard (OSC0 or OSC3) or from the logic tile (HCLKS_L2F or CLK_GLOBAL)

If the frequency of the AHB M1, M2 and S buses is different from the frequency of GLOBALCLK, then the AHB bridges must be configured in asynchronous mode.

 

With the default value of HCLKCTRL (0xE0), the baseboard drives all its system bus clocks (GLOBALCLK, HCLKM1_F2L, HCLKM2_F2L and HCLKS_F2L) with the signal OSC0.

 

Selection of the default bridge mode after power up is set by S1[3]. With S1[3] OFF Synchronous mode is selected and CLK_GLOBAL is provided to drive the logic tile design. With S1[3] ON Asynchronous mode is selected and CLK_POS_UP_IN, ZL217 and CLK_NEG_UP_IN are provided to drive the logic tile design.

When implementing a logic tile design it is important to use the appropriate clock(s) for the mode of operation used. Figure 17 and 18 gives a simplified view of how the clocks are routed on the VPB926EJ-S baseboard to the development chip and the logic tile FPGA. When using Synchronous mode OSCCLK0 drives the development chip and logic tile using GLOBALCLK. Buffers U24 and U3-1 introduce the same delay to the clock path and so GLOBALCLK appears at the development chip and logic tile FPGA simultaneously.

Image

Figure 10: Synchronous mode

 

When using Asynchronous mode OSCCLK0 still drives the Development chip core but the M1, M2 and S bridges are driven asynchronously by CLK_POS_UP_IN, ZL217 and CLK_NEG_UP_IN respectively. There are no buffers on the VPB926EJ-S baseboard introducing delays to the M1, M2 and S clock paths. Similarly there are no buffers on the logic tile for these clocks and so the development chip bridges and logic tile FPGA have matched clock paths.

 

Image

Figure 11: Asynchronous clocking

The Example designs provided demonstrate how to implement both Synchronous and Asynchronous bridge modes. The clock buffers must be set appropriately in the Top Level HDL design (AHBTopLevel.v or AHBTopLevel.vhd). Also the constraints file must be set to the appropriate clock selection (an170_veratile_master.ucf).

 

3                   Description of the Example HDL

3.1             General description

 

Example Verilog code, synthesis scripts and pre-synthesized bit-files are provided with this application note. The example code shows how to implement AHB masters and slaves in a logic tile on a PB926EJ-S.

Note: the example design is loaded into logic tile IMAGE 1 (S2[2] ON, S2[1] OFF).

 

The example design contains the following AHB slaves:

·         Two 256kB FPGA Block RAM controllers

·         An AHB to APB bridge: gives access to the following APB peripherals

o        APB configuration registers

o        APB interrupt controller

·         A default slave

 

In a PB926EJ-S system the AHB slaves are connected to the AHB M1 bus. On the AHB M2 bus there is only a default slave that covers the range of addresses mapped to the logic tile. The logic tile interrupt is routed to the VIC inside the development chip as source number 30.

Two AHB masters have been added to the configuration. The two masters are identical and have very limited functionality, since they are only intended to show how to integrate existing AHB masters in a logic tile.

The example masters generate a transfer when the logic tile push button is pressed. The address of the transfer is programmed in logic tile registers. Which master generates the transfer and the type of transfer is selected by the logic tile switches. The masters also include an arbiter when necessary.

The logic tile also includes some miscellaneous logic to control the logic tile hardware. This is mostly accessed through the on board FPGA to PLD serial interface:

·         A controller for the fold-over and thru switches

·         Three ICS307 clock controllers

·         Access to the user LEDs and user switches

·         Internal routing of the JTAG debug signals: D_TDI to D_TDO and D_TCK to D_RTCK

The example design works at up to 36MHz in both Synchronous and Asynchronous bridge modes on a PB926EJ-S system.

The example design can be built for Synchronous or Asynchronous bridge mode. When building the example it is necessary to set ‘SYNCMODE’ in the AHBTopLevel.v and run the appropriate PAR batch file (xilinx_par_sync.bat or xilinx_par_async.bat). Please refer to the comments in these files for information on setting the appropriate option.

 

3.2             Description of the HDL

 

Below there is a general description of the source code files provided. All the files are supplied as Verilog (.v). Each file normally contains only one module of the same name.

AHBTopLevel: This file is the top level HDL, which instantiates and interconnects the main blocks in the system. It also includes the tri-state interface logic that gives access to the external bus or buses.

AHBDecoder: Generates the HSEL selection signals for the AHB slaves. These signals are generated with combinatorial logic from HADDR. In the example code for configuration 1, the ID signals are used to map the logic tile at different addresses depending on its position in the stack.

In the example code for Versatile there are two decoder blocks, AHBDecoderM1 and AHBDecoderM2, one for each of the external master buses.

AHBMux3S1M: This module multiplexes the HREADY, HRESP, and HRDATA outputs from the AHB slaves. The outputs from the multiplexer are used to drive the tri-state buffers that access the AHB system bus.

AHBDefaultSlave: The HREADY and HRESP signals are driven by the default slave if the logic tile is accessed at an address not covered by any of the peripherals in the design.

AHBAPBSys: The APB components are instantiated in this block. These include the AHB-APB bridge and the APB peripherals.

AHB2APB: This is the bridge that connects the APB peripherals to the internal AHB bus. It also produces the peripheral select signals for each of the APB peripherals.

APBRegs: The APB register peripheral provides memory-mapped registers.

APBIntcon: The APB interrupt controller contains the interrupt controller registers, which can accept up to five external interrupts and four software interrupts. The example code only uses one external interrupt, generated by the push button.

AHBExampleMaster: Implements a simple AHB master that generates a transfer when the logic tile push button is pressed.

AHBMuxM2S: Multiplexes the outputs from the masters depending on which one is granted the bus. The outputs from the multiplexer drive the tri-state buffers that give access to the system bus.

AHBArbiter: Arbitrates between the different masters in the system. It implements a round robin scheme with equal priority between the masters.

ltxc4vlx100_serial: Provides the serial interface between the logic tile FPGA and PLD to allow control of on board clocks, fold/through switches, user LEDs and user switches.

AHB1Port1RAM.v: AHB to Block RAM memory controller to allows access to Block RAM memory from the AHB system bus.

AHBFSM.v: AHB Block RAM controller state machine.

ARM_64kx32_BRAM.v: FPGA block RAM configured as 64k * 32bit wide (256kB).

The Virtex 5 logic tile design includes the following files:

AHBZBSRAM: ZBT SSRAM controller that allows word, half-word, and byte access to the Logic Tile SSRAM from the AHB system bus. Two AHBZBTRAM modules are instantiated in the design, one for each SSRAM device on the board.

Figure 12 shows the structure of the example HDL. The HDL provided is commented, especially the top level file that shows the connection to the system bus.

 

Image

Figure 12: Structure of the example HDL

1 Virtex 5 only


3.3             Description of the masters

 

The example masters generate a single word access in the system bus when the logic tile push button is pressed.

The logic tile switch S1 selects which master generates a transfer and the type of transfer:

·         If S1-1 is OFF, the enabled master generates a write transfer

·         If S1-1 is ON, the enabled master generates a read transfer

·         If S1-2 is OFF, master 0 generates the transfer

·         If S1-2 is ON, master 1 generates the transfer

 

The addresses for the system bus accesses are programmed by writing to two logic tile registers: HADDR_TRANSFER0 and HADDR_TRANSFER1.

·         HADDR_TRANSFER0 contains the transfer address for master 0 and is located at offset address 0x24

·         HADDR_TRANSFER1 contains the transfer address for master 1 and is located at offset address 0x28

The example contains two registers which are named for compatibility with previous examples. The registers called IM_LT1_LEDS and IM_LT1_SW are used to configure the transfers generated by the masters:

·         IM_LT1_LEDS at address offset 0x014 becomes HDATA_WRITE and is a read/write register. The register contains the data that will be written in the next write transfer.

·         IM_LT1_SW at address offset 0x20 becomes HDATA_READ and is a read-only register. This register contains the data read in the last read access.

 

For example, if you want master 0 to write the data 0x05 to address 0x04000010, you must follow these steps:

·         Set S1-2 to OFF, so master 0 generates the transfer

·         Set S1-1 to OFF, so the transfer is a write transfer

·         Write 0x05 to register HDATA_WRITE at address 0xC0000014

·         Write 0x04000010 to register HADDR_TRANSFER0 at address 0xC0000024

·         Push the logic tile push button

 

Due to the PB926EJ-S system architecture, the logic tile master can access the baseboard devices through the development chip’s bus matrix. By default after reset, HADDR_TRANSFER0 and HADDR_TRANSFER1 are programmed to access the baseboard SDRAM.

·         HADDR_TRANSFER0 = 0x04000000

·         HADDR_TRANSFER1 = 0x04000004

 

3.4             Memory map

 

All the AHB and APB peripherals instantiated in the design can always be found at the same offset address. The example design responds to 256MB of addresses, for example from address 0xC0000000 to 0xCFFFFFFF.

The offset for the different peripherals is shown in Table 1:

 

Device

Registers

Int. Controller

Block RAM0

Block RAM1

Default Slave

Offset

0x0

0x01000000

0x02000000

0x020400001

0x024000000

Table 1: Offset address for peripherals in example design

1LT-XC5VLX330 devices have the Block RAM1 address beginning at 0x03000000, to accommodate the larger RAM blocks available.

 

All the slave peripherals are connected to AHB M1. The base address of the peripherals is fixed at 0xC0000000. The default slave responds to all the other addresses in the 4GB range.

A default slave is connected to AHB M2, which responds to the addresses assigned to the logic tile.

3.5             System registers

 

Table 2 shows the location of the system registers in the example design. The addresses shown are offsets from the logic tile base address.

 

Offset address

Name

Type

Size

Function

0x00000000

LT_OSC0

Read/write

19

Oscillator 0 divisor register

0x00000004

LT_OSC1

Read/write

19

Oscillator 1 divisor register

0x00000008

LT_OSC2

Read/write

19

Oscillator 2 divisor register

0x0000000C

LT_LOCK

Read/write

17

Oscillator lock register

0x00000010

LT_LEDS

Read/write

8

User LEDs control register (LT)

0x00000014

IM_LT1_LEDS / HDATA_ WRITE

Read/write

321

User LEDs control register (IM-LT1) / Data to write next transfer

0x00000018

LT_INT

Read/write

1

Push button interrupt register

0x0000001C

LT_SW

Read

8

Switches register (logic tile S1)

0x00000020

IM_LT1_SW / HDATA_READ

Read

321

Switches register (IM-LT1 S3) / Data read last transfer

0x00000024

HADDR_TRANSFER0

Read/write

32

Address next transfer master 0

0x00000028

HADDR_TRANSFER1

Read/write

32

Address next transfer master 1

Table 2: Location of system registers

1 LT1_LEDS and LT1_SW registers do not connect to external devices in this design, see section 3.3

 

Oscillator divisor registers

The oscillator registers LT_OSC0, LT_OSC1 and LT-OSC2 (at offset 0x00, 0x04 and 0x08) control the frequency of the clocks generated by the three clock generators on the logic tile.

Before writing to the oscillator registers, you must unlock them by writing the value 0x0000A05F to the LT_LOCK register. After writing the oscillator register, relock it by writing any other value to the LT_LOCK register.

 

Bits

Name

Access

Function

Default

[18:16]

OD

Read/write

Output divider:

000 = divide by 10

001 = divide by 2

010 = divide by 8

011 = divide by 4

100 = divide by 5

101 = divide by 7

110 = divide by 3

111 = divide by 6

b000

[15:9]

RDW

Read/write

VCO divider word. Defines the binary value of the RV[6:0] pins of the clock generator

b0010110

[8:0]

VDW

Read/write

Reference divider word. Defines the binary value of the V[7:0] pins of the clock generator

b001110000

 Table 3: LT_OSCx bit pattern

The reset value of these registers sets the oscillators to 24MHz. More information about setting up the frequency of the logic tile oscillators is available in the LT-XC4VLX100+ logic tile user guide.

 

Oscillator lock register

The lock register LT_LOCK (at offset 0x0C) controls access to the oscillator registers and allows you to lock them and unlock them. This mechanism prevents the oscillator registers from being overwritten accidentally.

 

Bits

Name

Access

Function

[16]

LOCKED

Read

This bit indicates if the oscillator registers are locked or unlocked:

0 = unlocked

1 = locked

[15:0]

LOCKVAL

Read/write

Write the value 0xA05F to this field to enable write accesses to the oscillator registers.

Write any other value to lock the oscillator registers.

Table 4: LT_LOCK bit pattern

User LEDs control registers

The LT_LED register (at offset 0x10) controls the 8 user LEDs on the logic tile.

Writing a 1 to a bit lights the associated LED.

Note: the IM_LT1_LED register (at offset 0x14) is maintained for compatibility with other examples and is only used to set HDATA_ WRITE – see Registers used by example masters below.

Push button interrupt register

The push button interrupt register LT_INT (at offset 0x18) contains 1 bit. It is a latched indication that the push button has been pressed. The contents of this register are fed to the interrupt controller registers.

 

Bits

Name

Access

Function

[0]

LT_INT

Read

Write

If the push button has been pressed, this bit is set.

Write 0 to this register to clear the latched push button indication.

Writing 1 to this register has the same effect as pressing the push button.

Table 5: LT_INT bit pattern             

 

Switch registers

Use the LT_SW register (at offset 0x1C) to read the setting of the 8-way DIP switch on the logic tile.

A value 1 indicates that the associated switch element is CLOSED (ON).

Note: the IM_LT1_SW register (at offset 0x20) is maintained for compatibility with other examples and is only used to read HDATA_READ – see Registers used by example masters below.

Registers used by example masters

HADDR_TRANSFER0 contains the transfer address for master 0 and is located at offset address 0x24

HADDR_TRANSFER1 contains the transfer address for master 1 and is located at offset address 0x28

IM_LT1_LEDS / HDATA_WRITE contains the data that will be written in the next write transfers and is located at offset address 0x14.

IM_LT1_SW / HDATA_READ contains the data read in the last read transfers and is located at offset address 0x20.

3.6             Interrupt controller

 

The interrupt controller included in the example design generates an interrupt signal from a number of interrupt sources. The output of the interrupt controller is routed to the primary interrupt controller inside the ARM926EJ-S development chip as interrupt source 30

The logic tile interrupt controller is designed so that it can accept up to four sources of interrupts and four software interrupts. In the example design only one source of interrupt is used, which is connected to the logic tile push button.

The other three sources or interrupt are unused in the example design, but users can use them to connect interrupt request signals for the peripherals they implement in the logic tile.

The interrupt controller contains registers to enable, disable and monitor the status of the different interrupt sources.

Table 6 shows the interrupt number assigned to each source of interrupt. Each interrupt source is associated with a bit number in the interrupt controller registers.

 

Bit

Name

Function

[7:5]

-

Spare (not used by the example image)

[4]

PBINT

Push button interrupt

[3:0]

SOFTINT[3:0]

Software interrupt generated by writing to LT_SOFTINT

Table 6: Interrupt register bit assignment

For example, in order to enable the push button interrupt you must set bit 4 of the interrupt enable register.

Table 7 shows the location of the interrupt controller memory mapped registers.

 

Offset address

Name

Type

Size

Function

0x01000000

LT_ISTAT

Read

8

Interrupt status

0x01000004

LT_IRSTAT

Read

8

Interrupt raw status

0x01000008

LT_IENABLE

Read

8

Interrupt enable

0x01000008

LT_IENSET

Write

8

Interrupt enable set

0x0100000C

LT_IENCLR

Write

8

Interrupt enable clear

0x01000010

LT_SOFTINT

Read/write

4

software interrupt

Table 7: Location of interrupt controller registers

 


The way that the interrupt enable, clear, status and raw status registers work is illustrated in Figure 13. This figure shows the control logic for one interrupt source, corresponding to one bit of all these registers.

 

Image

Figure 13: Interrupt controller internal design

 

nINT in the figure is the interrupt request output from the logic tile interrupt controller. This signal is activated when any bit of LT_ISTAT is set.

 

Interrupt status register

The status register LT_ISTAT contains the logical AND of the bits in the raw status register and the enable register.

Therefore a bit of the status register is 1 when its corresponding interrupt source is active and its corresponding interrupt enable bit has been set.

 

Interrupt raw status register

The raw status register LT_IRSTAT indicates the signal levels on the interrupt request inputs. A bit set to 1 indicates that the corresponding interrupt request is active.

 

Interrupt enable, interrupt enable set and interrupt enable clear

Reading from the interrupt enable register LT_IENABLE returns the current state of the interrupt source enable bits.

Writing 1 to a bit of the interrupt enable set register LT_IENSET sets the corresponding bit of LT_IENABLE

Writing 1 to a bit of the interrupt enable clear register LT_IENCLR clears the corresponding bit of LT_IENABLE

Writing 0 to a bit of LT_IENSET or LT_IENCLR leaves the corresponding bit of LT_IENABLE unchanged.

LT_IENABLE and LT_IENSET share the same address in the memory map.

 

Software interrupt register

This register is used to generate interrupts by software.

Writing 1 to any bit position in LT_SOFTINT register sets the corresponding bit in the interrupt controller registers. The LT_SOFTINT register has four bits, corresponding to the four software interrupts.

Writing a 0 to this register clears any software interrupts.

Reading from this register shows the raw status of the software interrupts.

The software interrupts should not be confused with the ARM SWI instruction.

 

3.7             Example software

 

Example software is provided to verify the example design and the logic tile hardware.

The source files included are logic.c, logic.h. Logic.c rw_support.s. Logic.c contains the main code, written in C. rw_support.s contains several assembler functions to perform word, half-word and byte accesses to the FPGA Block RAM.

A batch file with calls to the compiler, assembler and linker; and a built image are also provided for each of the configurations. The software can be re-built with both ADSv1.2 and RVDSv2.2 or later.

 

After the FPGA is configured, as indicated by the FPGA_OK LED, you can download and execute the example software on any ARM processor in the system. For example the software can be executed by the ARM926EJ-S processor on the PB926EJ-S baseboard.

 

The example code communicates with the user via the debugger’s console window. It operates as follows:

1. Reads the baseboard identification register to ensure that the software is executed on the correct system.

2. Sets the logic tile clocks

3. Flashes the LEDs on the logic tile and interface module (if present)

4. Tests the logic tile push button and interrupt controller.

5. Tests the Block RAMs for word, half-word and byte accesses.

6. Test the User LEDs and Switches.

 

Copyright © 2007 ARM Limited. All rights reserved. ARM DAI 0170B
Non-Confidential