View AU1500PCIREV1_2260677.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

1.3 revision: august 2002 issue date: pci bus software support for alchemy? au1500? processor from amd application note
? 2002 advanced micro devices, inc. all rights reserved. the contents of this document are provided in connection with advanced micro devices, inc. (?amd?) products. amd makes no representations or warranties with respect to the accuracy or completeness of the contents of this publication and reserves the right to make changes to specifications and product descripti ons at any time without notice. no license, whether express, implied, arising by estoppel or otherwise, to any intellectual property rights is granted by this publication. except as set forth in amd?s standard terms and conditions of sale, amd assumes no liability whatsoever, and disclaims any express or implied warranty, relating to its products including, but not limited to, the implied warranty of merchantability, fitness for a particular purpose, or infringement of any intellectual prop- erty right. amd?s products are not designed, intended, authorized or warranted for use as compo- nents in systems intended for surgical implant into the body, or in other applications intended to support or sustain life, or in any other application in which the failure of amd?s product could create a situation where pe rsonal injury, death, or severe property or environmental damage may occur. amd reserves the right to discontinue or make changes to its products at any time without notice. contacts www.amd.com pcs.support@amd.com trademarks amd, the amd arrow logo, and combinations thereof, a nd au1000, au1100, au1500, and alchemy are trademarks of advanced micro devices, inc. mips32 is a trademark of mips technologies. microsoft and windows are trademarks of microsoft corporation. other product names used in this publication are for identificati on purposes only and may be trademarks of their respective com panies.
application note 3 pci bus software support for the au1500 rev. 1.3 august 2002 1. introduction the au1500 system-on-a-chip, soc[1], features an integrated 33/66mhz pci 2.2 compliant bus for connecting to a variety of external peripherals. this document describes software techniques for supporting the au1500?s integrated pci bus. this document focuses on the software support and considerations that are needed for an au1500 integrated pci controller c onfigured as a host bridge. for information pertaining to th e au1500 configured as a pci sate llite, see ?satellite mode? on page 17. this document assumes the reader is familiar wi th the pci local bus specification version 2.2 [2]. 2. mips32 ? architecture memory map in the mips architecture, all addr esses (instruction fetche s, data loads and data stores) are virtual addresses [3]. as a result, addre ss translation is always performed on program instruction fetches and data accesses. the type of address translation depends upon the upper bits of the program address. the mips architecture defines the kuseg, kseg 0 and kseg1 regions according to these upper bits of the program?s virtual address. the pr ogram?s 32-bit memory space is thus divided: figure 1: mips 32-bit memory map the kuseg region extends from 0x00000000 to 0x7fffffff, a 2gb space which uses translation look-a-side buffers, tlbs, to determine the co rresponding physical address. the kuseg region is accessible while the cpu is in either user mode or kernel mode. the kseg0 region extends from 0x80000000 to 0x9fffffff, a 512mb space which has a direct correlation to a physical address. in addition, the ks eg0 region is inherently cacheable; me aning that both instruction and data caching is occuring for re ferences to this area. the kseg0 region is only accessible while the cpu is in kernel mode. reserved/kseg2 kseg1 kseg0 kuseg reserved/kseg3 0x00000000 0x80000000 0xa0000000 0xc0000000 0xe0000000
4 application note rev. 1.3 august 2002 pci bus software support for the au1500 the kseg1 region extends from 0xa0000000 to 0xbfffffff, a 512mb space which also has a direct correlation to a physical address. however, the kseg1 region is inherently non-cacheable; meaning that any instruction or data reference will bypa ss the cache and direc tly access physical memory. the kseg1 region is only accessible while the cpu is in kernel mode. for the kseg0 and kseg1 regions, the corresponding physical address is bits 28:0 of the virtual address with address bits 31:29 zero. that is, kseg0 and kseg1 map directly onto the first 512mb of physical memory. for example, kseg 0 address 0x80000000 and kseg1 address 0xa0000000 both map directly onto physical address 0x00000000. the kseg0 and kseg1 regions provide two views of physical memory; one cacheable and one non-cacheable. the address translation mechanism of the mips archit ecture always presents a physical address to the memory controllers (and othe r address decode logic). 3. au1500 36-bit physical addresses from the information/memory map in ?mips 32-bit memory map? on page 3, it is apparent that there is no room to locate a 32-bit pci address spac e directly within the mi ps 32-bit memory map! fortunately, the mips32 architecture specifies a 36- bit physical address space to accomodate large address spaces, such as the pci bus. the au1500 ta kes advantage of the 36- bit physical address and locates the pci address space as such: since 36-bit physical addresses are not directly vi sible to the processor (i.e. through the kseg0 or kseg1 regions), the pci space must be mapped into the system using a tlb and then accessed using virtual address pointers (a 32-bit poi nter which is translated by a tlb into a 36-bit physical address). the address translation steps are depicted in ?au1500 pci address translation? on page 5. table 1. au1500 pci address space mapping 36-bit physical address pci function 0x4 xxxxxxxx pci memory space 0x5 xxxxxxxx pci i/o space 0x6 xxxxxxxx pci configuration space
application note 5 pci bus software support for the au1500 rev. 1.3 august 2002 figure 2: au1500 pci address translation the pci controller decodes the upper bits of the 36- bit system bus physical address to determine if the cycle is a configuration, memory or i/o cycle. the lower 32-bits of the 36-bit system bus physical address are connected to the pci bus ad[31:0]. 4. software support the technique for supporting the pci bus is largely dependent upon the driver model for the software run-time system (i.e. operating system). for exampl e, drivers in the linux operating system run in ?kernel? mode (i.e. privileged and likely in either kseg0 or kseg1 regions), where as drivers in the windows ce operating system run in ?user? mode (i.e. each driver is in its own thread with its own address space). in linux, drivers run at the kernel privileged m ode and typically execute from either kseg0 or kseg1 space. that is, drivers expect the registers and/or memory of a peri pheral to be directly visible in the kseg0 or kseg1 regions. enabling pc i bus support in this environment is challenging since, at the time of this writing, the drivers do not have a readily-available facility for mapping a 36- bit address into a 32-bit address which can be acce ssed by the driver. nonetheless, a scheme is in place to support au1500 pci in linux. in windows ce, drivers run in a non-privileged mode as a thread of the i/o process, device.exe. each device driver has its own address space, and mu st explicitly map in the the physical address(es) of the peripheral?s resources. device drivers u tilize the mmmapiospace() function call which does support 36-bit physical addre sses and greatly facilitates pci bus support on the au1500. many real-time operating systems, rtos, do not use vi rtual memory, but rather execute entirely from the kseg0 and/or kseg1 regions. device driver s for these operating systems may expect the peripheral resources to be directly memory ma pped. without virtual memory, supporting the pci bus au1 sbus pci ad[31:0] 32-bit virtual address tlb 36-bit physical address au1500 cbe[3:0]
6 application note rev. 1.3 august 2002 pci bus software support for the au1500 is more challenging, but in most cases can be easily solved with the use of static or ?wired? tlb entries to directly map regions on the pci bus of interest to the rtos. most other operating systems or applications wit hout operating systems can use one or more of the techniques described herein. note: this document assumes a littl e-endian core conf iguration. since pci is inherently little- endian, with both the au1 core and pci in little-endian, each has the same ?view? of memory. utilizing the au1 core in big-endian mode is possi ble, and the issues are discussed in ?big-endian considerations? on page 17. 5. au1500 pci host bridge configuration the au1500 integrated pci controller must be c onfigured before it is utilized. this document assumes configuration of a host br idge (via the pci_cfg pin). the steps necessary to configure the controller are as follows. 1. enable the pci bus 33 and/or 66 mhz clock source. 2. take the au1500 pci controller and pci bus out of reset. 3. configure the au1500 pci controller registers. the pci controller requires these steps, in order, to ensure proper operation. 5.1 enable pci bus clock the 33 or 66 mhz pci clock can be generated eith er internally or externally, depending upon the application/board-design. for issues pertaining to pci clock generation, see the ?pci clock generation? applications note. if the pci clock is generated internally, the clock ge nerator registers must be programmed to generate the pci clock. if the pci clock is generated external ly, it must be enabled and running. 5.2 enable pci controller the pci bus signal rst# must be asserted for at least 100 microseconds after the pci clock has stablized. it then must be negated for a minimum of 5 pci clocks before accessing the pci bus. additional reset timing parameters are in the pci 2.2. specification: ?4.2.3.2. timing parameters? and ?4.3.2. reset?. the pci bus rst# signal also resets the au1500 pci controller. as such, rst# must be driven low and then high according to the pci reset timing to reset both the pci bus and the au1500 integrated pci controller. the au1500 pci controller must be taken out of reset a nd 5 pci clocks elapsed before any of its configuration registers can be accessed.
application note 7 pci bus software support for the au1500 rev. 1.3 august 2002 on the au1500, gpio200 defaults to an output that driv es low (a zero). this pin is intended to drive the pci bus rst# signal. if the board-design utilizes gpio200 in this capacity, then software must drive gpio200 according to the pci bus reset timi ng. the following code snippet de-asserts rst# by driving gpio200 high (no need to drive it low since it defaults to low). li t0, 0xb1700000 /* base address of gpio2 */ li t1, 3 /* gpio2_enable[mr=1,ce=1] sw t1, 0x0010(t0) /* gpio2_enable, provide clocks */ li t1, 1 /* gpio2_enable[mr=0,ce=1] sw t1, 0x0010(t0) /* gpio2_enable, take away reset */ li t1, 1 /* gpio2_dir[gpio200=1], output sw t1, 0x0000(t0) /* gpio2_dir, set gpio200 as output */ li t1, 0x00010001 /* gpio2_output[gpio200ena=1,gpio200=1] */ sw t1, 0x0008(t0) /* gpio2_output, gpio200 = 1 */ note: note: if gpio200 (or other gpio) is not used to control pci rst#, then pci rst# must also be tied to the au1500 rstin signal. see the au1500 specification update for additional information. 5.3 configure the pci controller the pci controller contains configuration regi sters which are located at physical address 0x0 14005000 (kseg1 address 0xb4005000). a simple host bridge setup is provided in table 2 on page 7. table 2. host bridge configuration register kseg1 address value pci_cmem 0xb4005000 0x00000000 pci_config 0xb4005004 0x0000000f pci_b2bmask_cch 0xb4005008 0x00000000 pci_b2bbase0_venid 0xb400500c 0x00000000 pci_b2bbase1_id 0xb4005010 0x00000000 pci_mwmask_dev 0xb4005014 0xe0000000 pci_mwbase_rev_ccl 0xb4005018 0x00000000 pci_err_addr 0xb400501c - pci_spec_intack 0xb4005020 - pci_id 0xb4005100 0x00001755 pci_statcmd 0xb4005104 0x02a00356 pci_classrev 0xb4005108 0x00000000
8 application note rev. 1.3 august 2002 pci bus software support for the au1500 the au1500 host bridge is enabled for operation wh en pci_statcmd[bus_master], bit 2, is set. the bridge will not generate pci cycles until this bit is set. furthermore, pci_statcmd[memory_space], bit 1, must be set if the au1500 memory window (see next section) is to be utilized. 5.3.1 au1500 memory window the registers pci_mwmask_dev, pci_mwbase_rev_ccl and pci_mbar provide a window into the au1500 memory. the window size can vary, as illustrated in table 3 on page 8. the example pci controller configuration above creates a 512mb window starting at au1500 physical address 0x0000000, which is visible in pci memory space starting at pci address 0x00000000. the configuration creates a simple 1:1 mapping of au1500 memory space into the pci space, and vice-versa. the 512mb window intentiona lly corresponds to the same size as the mips kseg0/kseg1 region which covers all sdram and static bus memories. 5.3.2 memory window considerations software likely needs at least these bus address translation routines: 1. au1 kseg0/1 address to pci address, 2. pci address to au1 kseg0/1 address, pci_hdrtype 0xb400510c 0x00000000 pci_mbar 0xb4005110 0x00000008 pci_timeout 0xb4005140 0x00000080 table 3. au1500 memory windows window size mwmask window size mwmask 64kb 0xffff 16mb 0xff00 128kb 0xfffe 32mb 0xfe00 256kb 0xfffc 64mb 0xfc00 512kb 0xfff8 128mb 0xf800 1mb 0xfff0 256mb 0xf000 2mb 0xffe0 512mb 0xe000 4mb 0xffc0 1gb 0xc000 8mb 0xff80 2gb 0x8000 table 2. host bridge configuration (continued) register kseg1 address value
application note 9 pci bus software support for the au1500 rev. 1.3 august 2002 3. au1 physical address to pci address, and 4. pci address to au1 physical address the bus address translation routines are necessary since a mips virtual address is not [necessarily] equivalent to a pci physical address. more spec ifically, the pci_mwbase and pci_mbar registers permit mapping a window of au1500 me mory anywhere in pci memory space. these bus address translation routines know how to compute, for a given memory location, a pci address from an au1 address, and vice versa. in particular, device dr ivers for pci devices should use these bus address translation routines when handling pci memory a ddresses, particularly for dma pointers/buffers. for example, with the simple host bridge configur ation above, the bus address translation routines merely manipulate the three most significant bits of the address corresponding to the mips kseg0/ kseg1 designations. in more complicated schemes, th e bus address translation routines must include the pci_mwbase and/or pci_mbar va lue in the address calculations. in determining the au1500 memory window size a nd location, the following items should be taken into consideration: 1. pci accesses into au1500 memory must o ccur to memory that is pre-fetchable. 2. the au1 mips vector table may be exposed in pci space, so it may be possible to damage the vector table. 3. the au1500 memory window is located in pci space via pci_mbar. this register is not visi- ble to the pci auto-configuration routine. pci-initiated memory accesses to au1500 memory mu st be to pre-fetchabl e memory. when a pci- initiated memory access occurs to au1500 memory, up to 8 words are transferred. as a result, it is not possible to access the integrated peripherals or othe r memory locations (such as fifos, registers, etc.) that have side-effects. in most instances, only the au1500 sdram should be accessed from pci. depending upon how the au1500 memory window is configured, the au1 core mips vector table in ram (virtual address 0x80000000, physical address 0x00000000) may be exposed in the pci space. depending upon the application and/or the development status of the associated software, this may not be desirable. if the au1 core vector table must be protected, then the pci_mwbase register must be changed, along with the bus address translation routin es, to avoid exposing the mips vector table in pci space. during the pci bus auto-configuration, pci device mbars are programmed with address ranges that do not conflict with other pci devices. however, the au1500 itself is not visible during a pci bus auto-configuration, so the au1500 pci_mbar register is programmed independent of the standard pci auto-configuration code. see ?aut o-configuration considerations? on page 11 for more information. 5.3.3 application-specific values the registers pci_b2bmask_cch, pci_b2bbase0_venid, pci_b2bbase1_id, pci_b2bbase1_id, pci_mwmask_dev, pci_id, pci_classrev all contain bitfields that correlate to values in the au1500 pci controller configuration space header. the valu es that are appropriate for the pci configuration space header are determined by the application. consult ?appendix d: class codes? of the pci 2.2 specification, as well as the pci special in terest group, pcisig, for appropriate values.
10 application note rev. 1.3 august 2002 pci bus software support for the au1500 6. pci configuration cycles pci configuration cycles are used to configure devices that are attached to the pci bus. the configuration space is normally scanned by software to identify and more importantly configure the devices for proper behavior on the pci bus. the pci configuration space addre ss is derived from the au1 36-bit physical address: bits [35:32]=6 indicate pci configuration space, bit [31] indicates a type 0 or type 1 configuration cycle, and bits [30:2] are copied directly to the pci_ad[30:2]. note: note: the au1500 pci controller does not respond to a configuration cycle from itself. as such it will not be detected by a pci bus scan. 6.1 type 0 configuration cycles type 0 configuration cycles are the most common. th e address phase of a type 0 configuration cycle is the following: figure 3: type 0 configuration cycle bit 31 of the 36-bit physical address is a zero and causes the pci cont roller to emit ?00? on pci_ad[1:0]. during the address phase, only one b it is permitted to be set in the device number field. the single ?1? bit denot es the idsel of a pci target device for the configuration cycle. a total of 20 target devices is supported. the following table enumerates the 20 possible configuration spaces. table 4. au1500 type 0 confi guration cycle base addresses device number idsel 36-bit physical address device number idsel 36-bit physical address 0 pci_ad[11] 0x6 00000800 10 pci_ad[21] 0x6 00200000 1 pci_ad[12] 0x6 00001000 11 pci_ad[22] 0x6 00400000 2 pci_ad[13] 0x6 00002000 12 pci_ad[23] 0x6 00800000 3 pci_ad[14] 0x6 00004000 13 pci_ad[24] 0x6 01000000 4 pci_ad[15] 0x6 00008000 14 pci_ad[25] 0x6 02000000 5 pci_ad[16] 0x6 00010000 15 pci_ad[26] 0x6 04000000 6 pci_ad[17] 0x6 00020000 16 pci_ad[27] 0x6 08000000 31 11 10 8 7 2 1 0 device function register 00 pci_ad[31:0]
application note 11 pci bus software support for the au1500 rev. 1.3 august 2002 6.2 type 1 configuration cycles type 1 configuration cycles are used to confi gure pci devices on a remote pci bus. the address phase of a type 1 configuration cycle is the following: figure 4: type 1 configuration cycle bit 31 of the 36-bit physical address is a one and causes the pci controller to emit ?01? on pci_ad[1:0]. bits [30:2] of the 36-bit physical a ddress are copied directly to bits ad[30:2]. the following table illustrates the 36-bit physical addr esses for type 1 confi guration space addresses. in the table above, ?df? represents the device number and function number which form pci_ad[15:8], and ?bb? represents the bus number which forms pci_ad[23:16]. 6.3 auto-configuration considerations at boot and/or run-time, pci auto-c onfiguration software scans the pc i configuration space in search of pci devices. when a device is detected, the devi ce is allocated pci memory and/or i/o space and its mbar(s) are programmed with a unique base a ddress. when completed, the pci bus scan creates a conflict-free address map for the pci bus. 7 pci_ad[18] 0x6 00040000 17 pci_ad[28] 0x6 10000000 8 pci_ad[19] 0x6 00080000 18 pci_ad[29] 0x6 20000000 9 pci_ad[20] 0x6 00100000 19 pci_ad[30] 0x6 40000000 table 5. au1500 type 1 configur ation cycle base addresses bus 36-bit physical address bus 36-bit physical address 0 0x6 8000df00 4 0x6 8004df00 1 0x6 8001df00 5 0x6 8005df00 2 0x6 8002df00 255 0x6 80ffdf00 3 0x6 8003df00 bb (<= 255) 0x6 80bbdf00 table 4. au1500 type 0 configuration cycle base addresses (continued) device number idsel 36-bit physical address device number idsel 36-bit physical address 31 30 11 10 8 7 2 1 0 reserved function register 01 bus device pci_ad[31:0]
12 application note rev. 1.3 august 2002 pci bus software support for the au1500 in general, standard pci auto-configuration soft ware works as intended with the au1500 pci bus, but there are a few additional items to take into c onsideration (these items are handled outside the standard pci bus scan): 1. the au1500 pci controller does not respond to a configuration cycle from itself. as such, the au1500 memory window is not detected during a pci bus scan. 2. devices on the pci bus which are fast-back-to -back capable should be allocated space in the area defined by the au1500 pci controller back-to-back windows. the au1500 pci controller does not re spond to configuration cycles in itiated by itself . consequently, the pci auto-configuration software is not awar e of the au1500 memory window. this behavior has two inter-related side-effects which must be accomodated by software: the location and size of the au1500 memory windo w must be determined in advance, so that... the pci auto-configuration software must allocate memory regions that do not conflict with the au1500 memory window. pci auto-configuration software is usually instructed as to the address ranges from which pci device memory and i/o addresses can be assigned; ther efore, once the au1500 memory window location (in pci space) and size are known, the pci auto-configura tion software must be instructed to avoid the au1500 memory window. the au1500 pci controller supports fast back-to- back transactions. the pci_b2bmask, pci_b2bbase0 and pci_b2bbase1 registers form two windows for ut ilizing fast back-to-back pci signalling on outgoing memory transactions. to take advantage of this performance feature, the following must be accomodated by software: the location and size of the fast back-to-back wind ows must be determined in advance, so that... the pci auto-configuration software should allocat e memory regions from the fast back-to-back win- dows for devices that advertise the fast back-to-back capability. during the pci bus-scan, for those pc i devices that are fast back-to- back capable (command register bit 9 is set), the pci auto-configuration software assigns, if possible, a memory region from the au1500 pci controller fast back-to-back windows. pci auto-configuration software is usually instructed as to the address ranges to which fast back-to-back transactions are possible; therefore, once the au1500 fast back-to-back windows locati on (in pci space) and size are known, the pci auto-configuration software is provided the fast back -to-back address range so that fast back-to-back devices can be assigned base addresses within this range. note: note: when allocating pci memory addresses, the range 0xc0000000 to 0xdfffffff may be desirable since a 1:1 processor-to-pci mapping can be created. more specifically, an au1 core access to mips kseg2 virtual address 0xc0000000 can be mapped via tlbs to a pci access to 0xc0000000, a 1:1 mapping. in certain software environments this may greatly simplify accessing the pci devices (e.g. the pci device mbar value can be used as a pointer). this 512mb address range should easily acco modate most pci memory space needs (au1500 memory window, fast back-to-back window and general device memory space).
application note 13 pci bus software support for the au1500 rev. 1.3 august 2002 6.4 software techniques most operating systems have a pci configuration space support application programming interface, api, similar to the following: [4] uint8 pcicfgrd8 (bus, device, func, reg); uint16 pcicfgrd16 (bus, device, func, reg); uint32 pcicfgrd32 (bus, device, func, reg); void pcicfgwr8 (bus, device, func, reg, data); void pcicfgwr16 (bus, device, func, reg, data); void pcicfgwr32 (bus, device, func, reg, data); for type 0 configuration cycles, the lower 32-bits of the 36-bit physical address are computed in this fashion: addr = ((1 << device) << 11) | (func << 8)| reg; for type 1 configuration cycles, the lower 32-bits of the 36-bit physical address are computed in this fashion: addr = (1 << 31) | (bus << 16) | (device << 11) | (func << 8) | reg; with the lower 32-bits of the physical address comput ed, it is necessary to create a valid tlb entry in order to obtain a mapping onto the pci configuration space. there are three primary approaches for mappi ng pci configuration space and performing pci configuration cycles: technique #1) allocate a fixed tlb entry, and dyna mically map/unmap the tlb to the computed 36- bit pci configuration cycle address, or technique #2) allocate a fixed tlb entry which covers most of the configuration space, or technique #3) dynamically map/unmap the 36-b it pci configuration a ddress from the current process address space. 6.4.1 configuration space access technique #1 technique #1 is for operating systems (e.g. linux, rtoses, or other operating environments), in which device drivers do not have their own unique address space, and therefore can not dynamically map/unmap pci c onfiguration space on demand. a tlb entry (e.g. tlb index 0) must be allocated for the specific purpose of pci configuration cycles. the mips cp0 register wired (i.e. cp0 regist er 6) must be adjusted accordingly to prevent random tlb updates from over-writing the entry a llocated to the pci configuration space. the pagemask should be set to 4kb. furthermore, a tlb-translated address range (kuseg , kseg2 or kseg3) must be reserved for the purpose of providing a 4kb window into pci configur ation space. this 4kb window is sufficient to cover a pci configuration header and is the single window for all pci configuration accesses.
14 application note rev. 1.3 august 2002 pci bus software support for the au1500 note: note: the least significant bit of the device number field is masked off during address translation with a 4kb pagemask (a 4kb pagemask utilizes bits [31:12] of the virtual address). as a result, least significant bit of th e device number field (bit 11) must be included in the computation of the register offset from the virtual base of the pci configuration space. the cca encoding for the tlb entry must be the value 2 for non-cached accesses. after a pci configuration space access, examine the pci_config[erd,et,ef,ep] bits for access errors. see the sample pci bus scan code which demonstrates this technique. 6.4.2 configuration space access technique #2 technique #2 is quite similar to technique #1, but it simplifies the management of the pci configuration space. if the hardware design allo ws, more specifically all device idsels are connected to one of pci_ad[24:11 ] and no type 1 configuration cycles are needed, then a single fixed (i.e. wired) tlb entry can be established to cover the useful pci configuration space. thus the pci configuration space is not conti nually mapped and unmapped during run-time. a tlb entry (e.g. tlb index 0) must be allocated for the specific purpose of pci configuration cycles. the mips cp0 register wired (i.e. cp0 regist er 6) must be adjusted accordingly to prevent random tlb updates from over-writing the entry allo cated to the pci configuration space. the tlb pagemask is set to 16mb and utilizes both entrylo0 and entryl o1 to map a continguous 32mb of pci configuration space. a tlb-translated address range (kuseg, kseg2 or kseg3) must be reserved for the purpose of providing a 32mb window into pci configuration sp ace. this is not a general purpose solution, but may suit many embedded hardware a nd software designs. the pci conf iguration headers for devices with idsel connected to one of pci_ad[24:11] ar e then directly visible in this kuseg/kseg2/ kseg3 address range. the cca encoding for the tlb entry must be the value 2 for non-cached accesses. after a pci configuration space access, examine the pci_config[erd,et,ef,ep] bits for access errors. see the sample pci bus scan code which demonstrates this technique. 6.4.3 configuration space access technique #3 technique #3, on the other hand, permits device drivers in operating systems that do support a separate virtual address space for device driv ers (e.g. windows ce) to dynamically map/unmap pci configuration address space. the driver utilizes the established mapping/unmapping routines and the resulting virtual pointers to access pci configuration space, and therefore the need to dedicate a fixed tlb entry and reserve a kuseg address is un-necessary. in all techniques, the cca encoding for the tlb en try must be the value 2 for non-cached accesses.
application note 15 pci bus software support for the au1500 rev. 1.3 august 2002 7. pci memory space the au1 core is able to generate non-cache-able accesses, cache-able accesses and fast back-to-back accesses to pci memory. all pci accesses first travel through the au1500 tlb to yield a 36-bit physical address and a cca encoding to determin e cache-ability. the au1500 pci controller also features different types of windows into pci space to improve performance. 7.1 non-cache-able accesses non-cache-able accesses are designated by th e tlb producing the 36-bit physical address 0x4 xxxxxxxx with a cca encoding of 2 or 7. on a read to non-cache-able pci memory space, the au1 core stalls waiting for data, and on a write, the data flows through the write-buffer, stalling only if the write-buffer is full. a cca encoding of 2 prevents gathering in the write buffer, which in turns causes single-beat accesses to pci memory. cca encoding 7 permits gathering in the write buffer, which in turns allows for burst transfers on the pci bus. see au1500 data book ?2.3 write buffer? for more information. in general, non-cache-able pci memory space access es occur when referencing pci device registers and/or memory and tend to be the most frequent type of pci memory space access. 7.2 cache-able accesses generally speaking, pci memory space on the au1500 is non-cache-able. however, the au1500 pci controller features the pci_cmem register which cr eates a cache-able window into pci memory space. to utilize this feature, the pci_cmem must be enabled and the tlb must produce a physical address that hits in pci_cmem address range and a cca encoding of 4. the pci_cmem[cm_base] value is inherently prepended with 0x0 to compare against a 36-bit physical address (the au1 core cache tags are for a 32-bit physical address). if the physical address hits in pci_cmem, then a cache-able pci memory access takes place. note: note: it is not possible to use the tlb (with cca 4) by itself to acheive cache-able pci memory space accesses. the au1 core cache tags are 32-bit physical address tags, and so a 36-bit physical address, like pci memory spac e 0x4 xxxxxxxx, is inherently non-cache-able. the cache-able pci memory window can be located anywhere, and in particular, within the first 512mb of memory; the mips kseg0 region. however, to use the cache-able pci memory window in kseg0, the config[k0] field, the cca encoding for the kseg0 region, must be set to 4. do note, though, that changing kseg0 to cca 4 may not be su itable for all/most applications since it may introduce more processor stalls (since the critical word is no longer accessed first). a very important consideration in determining to use the cache-able pci memory window is that cache-able pci memory window is not coherent with the pci memory space. as such, the cache- able pci memory window may not be suitable for all applications.
16 application note rev. 1.3 august 2002 pci bus software support for the au1500 the address and mask values for pci_cmem are application-specific; there is no general-purpose setting for pci_cmem. as such, the need for this performance feature must be determined by the application designer. a graphics video frame buffer would benefit from the cache-able pci memory window. note that that the pci auto-configuration software must allocate the frame buffer mbar in an address covered by pci_cmem. this may require more careful pl anning of the pci memory space address map. 7.3 fast back-to-back accesses the au1500 pci controller supports fast back-to-back accesses. if the 36-bit physical from the tlb hits in the au1500 pci controller fast back-to-back range (as determined by pci_b2bmask, pci_b2bbase0 and pci_b2bbase 1), then the au1500 controller will use fast back-t o-back signalling. 7.4 direct memory access, dma pci devices can perform direct memory accesses, dma, into au1500 memory. for pci device dma into au1500 memory, the au1500 memory window must be enabled, see ?au1500 memory window? on page 8. pci devices that perform dma are pci bus masters. the au1500 internal pci bus arbiter can be used to grant different pci bus masters (up to 4) the bus, or an external arbiter can be used. the decision is application specific, and the choice of arbiter must be reflected in the pci_config[aen] bit. the device drivers for pci devices should utilize the bus address translation routines previously described in ?memory window considerations? on page 8. dma engines need pci space address pointers, and software needs virtual address pointers. the bus address translation routines are used to convert pointers from pci address sp ace to mips virtual address space. 7.5 miscellaneous all pci memory accesses are first translated by th e tlb into a pci physical address. since the tlb is of finite size (32 entries), it is possible that tlb faults will occur while accessing pci memory space. performance to pci memory space improve by utilizing static, or wired, tlb entries. with static tlb entries, tlb faults are eliminated so as to remove the overhead involved in a tlb fault. of course, the number of static tlb entries to us e and which pci spaces to cover are application specific. 8. pci i/o space all pci accesses first travel through the au1500 tlb to yield a 36-bit physical address. pci i/o space accesses are designated by the tlb producing the 36-bit physical address 0x5 xxxxxxxx. on a read to pci i/o space, the au1 core stalls waiting for data, and on a write, th e data flows through the write-buffer, stalling only if the write-buffer is full.
application note 17 pci bus software support for the au1500 rev. 1.3 august 2002 pci i/o space accesses may only be non-cache-able , and therefore must utilize cca encoding 2. a static, or wired, tlb entry may be desirable to reduce the possibility of tlb faults and the overhead associated with handling a tlb fault. the num ber of static tlb entries to use is application specific. 9. pci interrupts tbd 10. big-endian considerations tbd 11. satellite mode the au1500 pci controller is configured for satellite mode when the pin pci_cfg is zero. the use of a satellite-mode au1500 is very much applicati on-specific; however, there are a few guidelines to follow. the pci configuration registers at 0xb40051xx are not visible to the processor. when in satellite mode, the registers at kseg1 address 0xb40051xx are not visible to the au1 core. as such, these registers must not be accesse d during initialization of the pci controller. the pci configuration registers must be configured before clearing the pci_config[pd] bit. the pci_config[pd] prevents the au1500 pci controller from responding to accesses. the au1500 pci configuration registers must be programmed with the appropriate values, then pci_config[pd] bit cleared. by default, this bit is set so that the co ntroller does not respond to pci accesses until the pci controller is configured. the au1500 responds to configuration cycles. when in satellite mode, the au1500 pci controller does respond to configuration cycles. as such, it does appear during a normal pci bus scan. (in host mode, the au1500 pci controller does not respond to configuration cycles.) the au1500 memory window size (pci_mwmask) is reflected in the mbar during a configuration cycle access. during a pci bus scan, the auto-configuration softwa re manipulates the mbar to determine the size of the memory window. the size programmed via pc i_mwmask is reflected in the mbar during the pci bus scan so that the proper size is reported to the auto-configuration software.
18 application note rev. 1.3 august 2002 pci bus software support for the au1500 12. references [1] ?the alchemy? au1500 ? processor from amd data book?, amd, 2002. [2] ?pci local bus specification?, pci special interest group, 1998. [3] ?mips32 tm architecture for programmers ?, mips technologies, inc., 2001. [4] ?pci bios specification?, pci special interest group, 1994.

▲Up To Search▲

Price & Availability of AU1500PCIREV1

	To Download AU1500PCIREV1 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .