"THE" Card VME Interface ------------------------ Original: 11-APR-1995 Latest: 8-JAN-1999 ------------ Introduction ------------ This document is intended to describe the VME Interface of THE card. The VME Interface performs the following functions: (1) VME A24/D16 slave-only interface with interrupt generation (2) THE card's Board-Level Registers These two functions of this FPGA are largely separate from each other. The On-Card Bus Interface module of this FPGA differs from the OCB Interface found on every other FPGA on THE Card in only 2 ways: - some On-Card Bus connections (e.g. Register Address, Chip Select*) are made internally to this FPGA to reduce I/O pin count - some "private" wires are used to convey information between the Board-Level Registers and the VME Slave Interface There is only ONE flavor of the VME Interface FPGA for all species of THE card. This FPGA then provides the features for all possible species of THE card. The configuration of this FPGA is stored in a serial EEPROM on THE card, and not downloaded via VME (for obvious reasons). --------------------------- VME Interface Functionality --------------------------- Overview -------- The VME Interface FPGA connects the VME Bus to the On-Card Bus. The VME Bus is specified in the VMEBus Specification Rev. C document. The On-Card Bus is specified in this document, in the On-Card Bus Specification section. The VME interface has the following characteristics: - Slave only interface, supports both read and write - A24 addressing mode only - D16 data transfer mode only - generation of level 4 interrupts - NO block transfers To support these functions, the VME Interface monitors and/or drives the following signals: A01:A23 (monitor only) AM0:AM5 (monitor only) LWORD* (monitor only) IACK* (monitor only) WRITE* (monitor only) DS0*:DS1* (monitor only) D00:D15 (monitor and drive) AS* (monitor only) DTACK* (drive only) SYSRESET* (monitor only) IRQ4* (drive only) IACKIN* (monitor only) IACKOUT* (drive only) BG(3:0)IN* are passed to BG(3:0)OUT* to allow bus master negotiation - this could be done with jumpers on the backplane if we thought that made sense for some reason SYSRESET* is used to force both state machines (described later in this document) in the VME Interface FPGA back to their Quiescent states. Additionally, the ACFAIL* VME signal is used to initiate configuration of the VME Interface FPGA, therefore the ACFAIL* signal is monitored by this FPGA. The VME Interface does NOT interfere with the other VME signals present on the P1 backplane: BR(3:0)* BERR* BBSY* BCLR* IRQ(7:5,3:1)* SERCLK SERDAT* SYSFAIL* SYSCLK Finally, note that the Run II Framework backplanes use a 5-row connector P1 backplanes, so plugging a standard VME card into this backplane requires a 3-row to 5-row adaptor card. See the file USE_OF_P1_BACKPLANE.TXT for more details. VME Addressing -------------- As stated above, the VME Interface only responds to A24/D16 accesses. The Address Mode is specified by AM5-AM0. The legal Address Modes are: A A A A A A M M M M M M hex Address mode 5 4 3 2 1 0 code ------------ ----------- ---- Standard Non-Privileged Data Access 1 1 1 0 0 1 39 Standard Non-Privileged Program Access 1 1 1 0 1 0 3A Standard Supervisory Data Access 1 1 1 1 0 1 3D Standard Supervisory Program Access 1 1 1 1 1 0 3E The data mode is specified by DS1*, DS0*, A01, and LWORD*. The supported data modes are: data access mode DS1* DS0* A01 LWORD* ---------------- ---- ---- --- ------ double-byte [BYTE(0-1)] 0 0 0 1 double-byte [BYTE(2-3)] 0 0 1 1 Note that all D16 accesses must occur at EVEN VME byte addresses (cf. VMEBus Specification Rev. C). The 24-bit VME address space is subdivided into Card, Chip, and Register Addresses as follows: A A A A A A A A A A A A A A A A A A A A A A A A 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 ----------------------------------------------- | Card | Chip | | Register | 0 0 0| Address | Addres |*| Address |+ Notes: * : 9th Register Address bit. This bit must be held LOW. It is reserved for future possible expansion of the Register Address space. + : VME A00 must be held LOW. THE Card only supports word-aligned 16-bit transfers. Each instance of THE Card in a VME Crate is assigned a unique 6-bit Card Address (allowing the maximum of 21 THE Cards in each Crate to be assigned "2-bit-different" Card Addresses). Each THE Card responds to any valid (e.g. A24/D16) VME access corresponding to its Card Address, regardless of the Chip or Register Address (even if an unused Chip/Register combination is selected). The Card Address is selected via hex rotor switches on THE card. By convention, Card Addresses of THE Card (although not necessarily standard VME cards) will be associated with particular slots in the Backplanes (e.g. all instances of THE Card in slot 3 of any Backplanes will have the same Card Address, see the table below). Each Chip (either FPGA or other on-card addressable object) has a unique 5-bit Chip Address. This allows 32 addressable Chips per card. Chip Address 0 is assigned to the VME Interface FPGA. Chip Addresses 1-16 are assigned to the 16 Main Signal Processing Array FPGA's. Chip Address 17 is assigned to the Board Support Functions FPGA. Chip Address 18 is assigned to the the JTAG Scan Path Controller Chip. Chip Addresses 19 through 30 are currently unassigned. Chip Address 31 is used only for FPGA configuration, as described below. Each Register in a chip has a unique 8-bit Register Address. This allows up to 256 (16-bit) Registers per Chip. Not every Chip uses all 256 Registers (and in fact the Register usage per Chip varies across Chip types and species of THE Card). species of THE card). The most significant 3 bits of the VME Address must be LOW when addressing an instance of THE Card. This leaves 7/8 of the VME A24 address space available for commercial off-the-shelf VME modules which may be used in the crates. As noted above, VME A09 and A00 must also be held LOW. The mapping of Backplane slots to Card Base Addresses is as follows: Card Card Addr Addr Card Base Slot Dec Hex Address Comment ---- ---- ---- --------- ------- 1 1 $ 01 $008000 typically a Vert Inter, not a THE Card 2 4 $ 04 $020000 3 7 $ 07 $038000 4 10 $ 0A $050000 5 13 $ 0D $068000 6 16 $ 10 $080000 7 19 $ 13 $098000 8 22 $ 16 $0b0000 9 25 $ 19 $0c8000 10 28 $ 1C $0e0000 11 31 $ 1F $0f8000 12 34 $ 22 $110000 13 37 $ 25 $128000 14 40 $ 28 $140000 15 43 $ 2B $158000 16 46 $ 2E $170000 17 49 $ 31 $188000 18 52 $ 34 $1a0000 19 55 $ 37 $1b8000 20 58 $ 3A $1d0000 21 61 $ 3D $1e8000 The mapping of Chip Addresses to VME address byte offsets within a given THE Card is as follows: VME Byte Address (in HEX, offset Chip from Card Base Addr Address ---- ---------------- 0 $0000 - $01ff VME Interface FPGA 1 $0400 - $05ff Main Signal Processing Array FPGA # 1 2 $0800 - $09ff Main Signal Processing Array FPGA # 2 3 $0c00 - $0dff Main Signal Processing Array FPGA # 3 4 $1000 - $11ff Main Signal Processing Array FPGA # 4 5 $1400 - $15ff Main Signal Processing Array FPGA # 5 6 $1800 - $19ff Main Signal Processing Array FPGA # 6 7 $1c00 - $1dff Main Signal Processing Array FPGA # 7 8 $2000 - $21ff Main Signal Processing Array FPGA # 8 9 $2400 - $25ff Main Signal Processing Array FPGA # 9 10 $2800 - $29ff Main Signal Processing Array FPGA #10 11 $2c00 - $2dff Main Signal Processing Array FPGA #11 12 $3000 - $31ff Main Signal Processing Array FPGA #12 13 $3400 - $35ff Main Signal Processing Array FPGA #13 14 $3800 - $39ff Main Signal Processing Array FPGA #14 15 $3c00 - $3dff Main Signal Processing Array FPGA #15 16 $4000 - $41ff Main Signal Processing Array FPGA #16 17 $4400 - $45ff Board Support Functions FPGA 18 $4800 - $49ff JTAG Scan Path Controller Chip 19-30 $4c00 - $7bff Currently Unassigned 31 $7c00 - $7dff FPGA Configuration Addresses The address map of the VME Interface FPGA is defined later in this document. The address maps of the other FPGA's are defined in their respective driver documents. The VME Interface FPGA is the only FPGA that is allowed to load the VME Bus. It directly drives the On-Card Bus control signals (32 Chip Selects, 8 Register Address bits, Direction, and Write Strobe*). It drives the VMEBus DTACK* and IRQ4* signals through external open-collector drivers. It drives the VMEBus IACKOUT* signal through an open-collector driver with a 1k ohm pull-up resistor to VCC. The VME Data signals are connected to the On-Card Bus Data signals via 74F245 transceivers, which are controlled by the VME Interface FPGA. Since a standard VME Master interface chip is used to drive the VME Bus, no "custom" VME cycles are allowed. Note that this idea was used in the Run I CBUS equipment. ------------------------- On-Card Bus Specification ------------------------- The On-Card Bus is THE card's local bus. It connects to the VME Bus via the VME Interface FPGA. The On-Card Bus is composed of the following signals: (The following signals assume a quiescent state when the card is not being addressed): (1) N individual Chip_Select* signals (N < 32) These signals are the decoded Chip Address (VME A10-A14) signals. Only one of these signals may be active (LOW) at a time (except for the special case of simultaneously configuring multiple FPGA's, described below. The decoding occurs in the VME Interface FPGA. These signals are distributed "radially" to all Chips on THE Card. The quiescent state of these signals is all HIGH These signals are driven by the VME Interface FPGA. (2) 8-bit Register_Address These signals are the Register Address signals. They are derived from the VME A08-A01 signals. These signals are bussed to all Chips on THE Card. The quiescent state of these signals is all LOW. These signals are driven by the VME Interface FPGA. (3) Direction This signal differentiates writes from reads on the On-Card Bus. It is LOW for write cycles and HIGH for read cycles. It is derived from the VME WRITE* signal. This signal is bussed to all Chips on THE Card EXCEPT the JTAG Scan Path Controller Chip. The quiescent state of this signal is LOW (WRITE) to avoid possible contention between the 'x245 drivers and chip data output drivers during the address phase of the VME cycle. This signal is driven by the VME Interface FPGA. (4) Write_Strobe* The leading (falling) edge of this active-low signal stores data in the selected register during write cycles. This signal is not asserted during read cycles. It is derived from the VME DS0* and DS1* signals. This signal is bussed to all Chips on THE Card EXCEPT the JTAG Scan Path Controller Chip. The quiescent state of this signal is HIGH. This signal is driven by the VME Interface FPGA. (5) 16-bit Data These signals convey the written data from (or read data to) the VME Bus. These signals are bussed to all Chips on THE Card. The quiescent state of this signals is the contents of the Status/ID Register. This is done to simplify the VMEBus Interrupt Acknowledge handling. Note that if any 8-bit devices are attached to the On-Card Bus, they should be connected to the least significant 8 bits of the On-Card Data bus. During WRITE cycles these signals are driven by the F245 Data Transceiver. During READ cycles these signals are driven by the selected FPGA (or other on-card resource). When the card is not being addressed, they are driven to the quiescent state by the VME Interface FPGA. (The following signals DO NOT assume a quiescent state when the card is not being addressed): (6) N individual Chip_Status* signals (N < 32) These signals convey chip status information from the individual FPGA's to the VME Interface FPGA. They can be used to generate VME Interrupts (see the Board Condition for more information). Note that these signals are active LOW. These signals are distributed "radially" on THE Card. These signals are driven by the individual FPGA's. (7) Main_Signal_Array_FPGA_Output_Enable* This signal is used to enable the output of the Main Signal Array FPGA's. The typical use of this signal is to disable all Main Signal Array FPGA outputs until all FPGA's on THE Card are configured. A LOW level on this signal enables the FPGA outputs. This signal is bussed to all Main Signal Array FPGA's on THE Card. This signal is driven by the VME Interface FPGA. (8) Board_Support_Function_FPGA_Output_Enable* This signal is used to enable the output of the Board Support Function FPGA. The typical use of this signal is to disable all Board Support Function FPGA outputs until all FPGA's on THE Card are configured. A LOW level on this signal enables the FPGA outputs. This signal is distributed only to the Board Support Function FPGA on THE Card. This signal is driven by the VME Interface FPGA. (9) Main_Signal_Output_ECL_Driver_Enable This signal is used to enable the outputs of the off-card Main Signal ECL 100324 output drivers. Recall that when the outputs of these chips are disabled they actually present a valid differential ECL LOW. Note that the Global I/O ECL lines are not affected by this signal, but rather are controlled via the Board Support Function FPGA. A HIGH level on this signal enables the ECL outputs. This signal is bussed to all Main Signal Array ECL Output Drivers on THE Card. This signal is driven by the VME Interface FPGA. (10) JTAG_Scan_Path_Controller_Enable This signal is used to enable the outputs of the JTAG Scan Path Controller Chip. A HIGH level on this signal enables all outputs and bi-directional pins (on both the scan path target interface and the On-Card Bus) of the JTAG Scan Path Controller Chip, while a LOW level tri-states these pins. This signal is distributed only to the JTAG Scan Path Controller Chip on THE Card. This signal is driven by the VME Interface FPGA. (11) JTAG_Scan_Path_Controller_Test_Logic_Activate This signal is used to enable the JTAG Scan Path Controller "target interface" logic. A HIGH level on this signal enables this logic, while a LOW level on this signal causes the JTAG Scan Path Controller to place the Scan Path targets in the Test-Logic-Reset state. Note that disabling the Scan Path Controller Chip (via JTAG_Scan_Path_Controller_Enable) is dominant over this function (i.e. if the Scan Path Controller is disabled, the target interface output pins will all be tri-stated regardless of the level on JTAG_Scan_Path_Controller_Test_Logic_Active. This signal is distributed only to the JTAG Scan Path Controller Chip on THE Card. This signal is driven by the VME Interface FPGA. (12) N individual Configure_Chip* signals (N < 32) These signals are used to initiate FPGA configuration for FPGA's which are configurable via VME. See the FPGA Configuration section below for the detailed description of these signals. These signals are distributed "radially" to all FPGA's on THE Card which can be configured via VME. These signals are driven by the VME Interface FPGA. (13) N individual Chip_Configured signals (N < 32) These signals are used to indicate the configuration status of all configurable chips on THE Card. A HIGH level on these signals means that the chip is configured. These signals are distributed "radially" to all FPGA's on THE Card which can be configured via VME. These signals are driven by the individual FPGA's. Additionally, to support the TI 74ACT8990 JTAG Scan Path Controller Chip (which is not directly compatible with the On-Card Bus specification), the following signals are derived within the VME Interface FPGA from standard On-Card Bus signals: (1) JTAG_WR* The trailing (rising) edge of this active-low signal stores data in the selected register of the JTAG Scan Path Controller Chip during write cycles. This signal is not asserted during read cycles. It is derived from the Chip_Select(18)* and Write_Strobe* signals. Note that the data is latched on the trailing edge of this signal (which is generated by the trailing edge of Write_Strobe*), unlike a normal On-Card Bus register access write, but like an On-Card Bus configuration write. This signal is distributed only to the JTAG Scan Path Controller Chip on THE Card. The quiescent state of this signal is HIGH. This signal is driven by the VME Interface FPGA. (2) JTAG_RD* The active LOW level of this signal enables the JTAG Scan Path Controller Chip to drive the contents of the selected register on to the On-Card Bus Data signals during read cycles. This signal is not asserted during write cycles. It is derived from the Chip_Select(18)* and Direction signals. This signal is distributed only to the JTAG Scan Path Controller Chip on THE Card. The quiescent state of this signal is HIGH. This signal is driven by the VME Interface FPGA. (3) JTAG_DIR* This inverted form of the Direction signal is used to set the direction of the IDT 74FCT16245T 3V/5V data transceivers. This signal is distributed only to the IDT 74FCT16245T logic-level converting transceivers. The quiescent state of this signal is HIGH. This signal is driven by the VME Interface FPGA. (4) JTAG_RDY* The active low level of this signal indicates that the JTAG Scan Path Controller Chip is ready to be read from or written to. It is visible in the Board Condition Status Register. Note that this signal is NOT used in VME DTACK* generation. This signal is driven by the JTAG Scan Path Controller Chip. --------------------- Board-Level Registers --------------------- The VME Interface FPGA provides several Board-Level Registers which allow the TCC to control board-level functions and also to retrieve board-level information. These Registers are as follows: VME Byte Address Offset (in HEX, Reg from card base Register Addr Access address) Contents ---- ------ -------------- -------- 0 R $000 Board Species ID 1 R/W $002 Board Interrupter ID 2 R/W $004 Board Condition Status Register 3 --- $006 unused (BCSR expansion space) 4 R/W $008 Chip 15:0 Configuration Enable Reg. 5 R/W $00a Chip 31:16 Configuration Enable Reg. 6 R $00c Chip 15:0 Configured Register 7 R $00e Chip 31:16 Configured Register 8 R/W $010 Chip 15:0 Interrupt Enable Register 9 R/W $012 Chip 31:16 Interrupt Enable Register 10 R $014 Chip 15:0 Status Register 11 R $016 Chip 31:16 Status Register 12 R $018 Chip 15:0 Interrupt Request Reg. 13 R $01a Chip 31:16 Interrupt Request Reg. 14-15 --- $01c - $01e Unused 16-31 R/W $020 - $03e 16 words of Scratch RAM Except as noted below, any writable bit in a writable register will be CLEARED when the VME Interface FPGA "wakes up" after configuration, and the CLEARED state is the more harmless state. The idea is to wake up from configuration in a controlled fashion. Occasionally, for the above reason or simply to present a uniform programming interface, a value in a Board-Level Register is inverted when driven onto or received from the On-Card Bus. When this occurs, it is clearly noted in the documentation. For an example, see the Main Signal Array FPGA Output Enable below. Contents of each register: The Board Species ID Register is a 16-bit read-only register which contains the Board Species ID, which is encoded in the VMEIF configuration. The Board Interrupter ID Register is a 16-bit read/write register which contains the Status/ID code which this card will use when performing a VMEBus Interrupt Acknowledge cycle. This code is programmed by TCC after the VMEIF is configured. The Board Condition Status Register is a 16-bit register which collects various board-level control and status signals. The usage of bits in this register is as follows: Bit Access Contents --- ------ -------- 0 R/W Global Configuration Enable (must load '0' then '1', then '0' again to enable configuration) 1 R/W Global Interrupt Enable ('1': interrupts enabled, automatically set to '0' upon VMEBus Interrupt Acknowledge) 2 R/W Main Signal Array FPGA Output Enable ('0': MSA FPGA outputs disabled '1': MSA FPGA outputs enabled note: inversion between the CSR and the On-Card Bus) 3 R/W Board Support Function FPGA Output Enable ('0': BSF FPGA outputs disabled '1': BSF FPGA outputs enabled note: inversion between the CSR and the On-Card Bus) 4 R/W Main Signal Output ECL Driver Output Enable ('0': MS ECL outputs forced to diff ECL '0' '1': Main Signal ECL outputs enabled) 5 R/W JTAG Scan Path Controller Enable (Connected to 74ACT8990 TOFF*) ('0': JTAG Controller outputs disabled '1': JTAG Controller outputs enabled) 6 R/W JTAG Scan Path Controller Test Logic Activate (Connected to 74ACT8990 TRST*) ('0': JTAG Scan Path in Test-Logic-Reset '1': JTAG Scan Path active note: subordinate to JTAG Scan Path Controller Enable) 7 R JTAG_RDY* ('0': JTAG Controller ready '1': JTAG Controller not ready) 8 R/W VMEIF Re-configured Flag (automatically set to '1' after VMEIF Re-configure, must be manually cleared to '0' by TCC) 9 R/W VMEBus Error Flag (automatically set to '1' after any VMEBus error or VMEIF Re-configure, must be manually cleared to '0' by TCC) 10 R On-Card Interrupt Request Flag ('1': a Chip which is enabled to request interrupts currently is holding its Chip Status* signal LOW [signal is set regardless of the Global Interrupt Enable) 11 R Configuration Error Flag ('1': one of the MSA FPGA's or the BSF FPGA has sensed a configuration error note: inversion between CSR and OCB note: this flag will always be LOW on the Foundation Module) 12 R VMEBus Interrupt Request Flag ('1': this Card is currently requesting a VMEBus Interrupt) 15:13 Unallocated The Chip Configuration Enable Register is a 32-bit register (split across 2 16-bit registers) which contains the per-Chip Configuration Enable signals. Configuration in this sense means programming the FPGA functionality, not writing to registers in a configured FPGA. Note that this control is meaningless for Chips which cannot be configured via the VMEBus (for example, Chip 0, the VME Interface FPGA, will NOT be written to during Configuration writes even if bit 0 is set in the Configuration Enable Register). Within each register, the LSB controls the lowest Chip Address and the MSB controls the highest Chip Address. A bit of value '1' in this register means that VMEBus writes to the FPGA Configuration Address of this card will be configuration writes to the corresponding FPGA. The Chip Configured Register indicates, for each Chip, whether the Chip is configured or not. These read-only signals are meaningless for Chips which are not configurable, and also for Chip 0 (the VME Interface FPGA). Once again, the LSB maps to the lowest Chip Address. A bit of value '1' means that the FPGA is configured. The Chip Interrupt Enable Register controls, for each Chip, whether a LOW level on the corresponding Chip Status* line will result in a VME IRQ4* Interrupt request. A bit of value '1' means that the Chip can request a VME Interrupt. The Chip Status Register indicates, for each Chip, the current state of the Chip Status* line. A bit of value '0' means that the corresponding chip is holding its Chip Status* line LOW. This register is read-only. Note that the Chip Status* line is pulled high by unconfigured FPGA's. Also, during FPGA configuration, this register shows the RDY/BUSY* status of each VME-configurable FPGA. During this time, a bit of value '0' means that the corresponding FPGA is NOT ready for the next configuration byte. The Chip Interrupt Request Register indicates, for each chip, whether it is currently requesting a VMEBus Interrupt. This register is the bitwise AND of the Chip Interrupt Enable Register and the NOT of the Chip Status Register. Note the inversion between the Chip Status Register and the Chip Interrupt Request Register. The Scratch RAM can be used for general purpose information storage. It does not control anything nor does it report the status of anything. After reconfiguration of the VME Interface FPGA, the contents of the RAM are undefined. ----------------- VMEBus Interrupts ----------------- Any chip on THE Card may have a Chip Status* signal which it sends to the VMEIF. A LOW level on any Chip Status* signal will cause the VMEIF to generate a VMEBus level 4 Interrupt Request, if: - the chip is enabled to request VMEBus Interrupts (via the Interrupt Enable Register), AND - the card is enabled to request VMEBus Interrupts (via the Board Condition Status Register) The VMEBus Specification describes a VME Interrupt Request and Acknowledge cycle, but does NOT define either the on-card interrupt request logic or the interrupt service processing performed by the Interrupt Handler. The portion of these functions which is common to all instances of THE Card are specified here: - once a chip has asserted its Chip Status* signal, it MUST continue to assert the signal until the signal is cleared by TCC (typically via a VMEBus write to some particular Register Address on that chip) - multiple chips MAY assert their Chip Status* signals simultaneously--only one VMEBus Interrupt Request will occur - chips MAY assert their Chip Status* signals while a VMEBus Interrupt Request is pending--the VMEBus Interrupt Request in progress will not be modified nor will a new VMEBus Interrupt Request be scheduled, however the Chip Status Register and the Interrupt Request Register will be updated to reflect the change - chips MAY assert their Chip Status* signals while either the individual chip or the entire card is disabled from generating interrupts--if the Chip Status* signal is still asserted when the chip/card is re-enabled to generate interrupts, a VMEBus Interrupt Request will immediately occur - the VMEBus Interrupt Request and Interrupt Acknowledge will be as described in Chapter 4 of the VMEBus Specification Rev. C - the Interrupter only requests Interrupts at level 4 - the size of the Status/ID word is D16 - the contents of the Status/ID word are described above - the Interrupter is a Release-on-Acknowledge type - upon a VMEBus Interrupt Acknowledge, the VMEIF will automatically disable the card from generating more VMEBus Interrupt Requests by loading '0' into the appropriate bit of the Board CSR, and terminate the VMEBus Interrupt Request. Note that the VMEBus Interrupt Acknowledge cycle is OPTIONAL. - at a minimum, the interrupt servicing routine performed by TCC MUST: - use the Status/ID word (if a VMEBus Interrupt Acknowledge cycle is performed) or scan the Board Control Status Registers of all Cards in the requesting Crate to determine which Card requires interrupt servicing. - read the Interrupt Request Register of the appropriate Card to determine which Chip(s) require servicing - perform the Chip-specific log and/or repair of the problem, possibly including reading Chip-level status registers to determine the nature of the problem - clear the Chip Status* signal(s), most likely via a VMEBus write to a chip-level condition/status register - verify that the Interrupt Request Register of the appropriate Card is all '0' - re-enable the appropriate Card to request VMEBus Interrupts ------------------ FPGA Configuration ------------------ With respect to configuration, there are 2 types of FPGA's on THE card: those are configured via VMEBus and those which are configured via on-card serial EEPROM. The only example of the latter is the VME Interface FPGA itself. (1) Configuring the VME Interface FPGA The VME Interface FPGA is configured in Master Serial Mode, in which it reads its configuration from an on-card serial EEPROM. The configuration may be triggered in either of two ways: - it will occur automatically at power-up - it will occur on the trailing (rising) edge of a low pulse on ACFAIL* Note that, after configuring the VMEIF, all registers on THE Card must be considered suspect, as the On-Card Bus is uncontrolled before the initial VMEIF configuration and also during VMEIF re-configuration. (2) Configuring all other FPGA's All other FPGA's on THE card are configured in Asynchronous Peripheral Mode, in which the configuration is delivered one byte at a time via VMEBus writes. On THE Card, FPGA's may be either be configured one-at-a-time or in parallel. Note that it is only possible to configure FPGA's in parallel if all of the FPGA's being configured have IDENTICAL configurations. The steps for configuring either a single FPGA or multiple FPGA's in parallel are: - disable the outputs of all FPGA's on the card by setting the Main Signal Array FPGA Output Enable and the Board Support FPGA Output Enable to value '0' in the Board Condition Status Register. - enable the configuration of the desired FPGA(s) via the Chip Configuration Registers by setting the appropriate bit(s) to value '1'. - program the Board CSR to globally enable FPGA configuration by cycling the Global Configuration Enable bit from '0' to '1' and back to '0'. - download the configuration, one byte at a time, to any Register Address in the FPGA Configuration address range. o these must be D16 writes, but only the 8 LSB's carry configuration information. o any attempted "register access" VMEBus write to any of the FPGA's being configured will corrupt the configuration. o VMEBus write to FPGA's NOT being configured, or VMEBus reads of any FPGA's (whether or not they are currently being configured) will not corrupt the configuration but are nevertheless NOT recommended. o The VME FPGA's Chip Status Register indicates whether each FPGA being configured is ready for the next configuration byte. - verify that the FPGA is configured by examining the Chip Configured Registers. - protect the configuration of the FPGA(s) via the Chip Configuration Registers by setting the appropriate bit(s) to value '0'. - re-enable the MSA and BSF FPGA outputs via the Board Condition Status Register. The configuration writes are standard VMEBus D16 write cycles (although, as noted above, each write only contains 8 bits of useful configuration information). Certain On Card Bus signals on downloadable FPGA's must be placed on specific FPGA pins to allow configuration in Asynchronous Peripheral Mode via the VMEBus: FPGA pin name OCB signal FPGA pin # Notes ------------- ---------- ---------- ----- M0 VDD 60 1 M1 GROUND 58 1 M2 VDD 62 1 CS0* OCB_Chip_Sel*(x) 142 2 CS1 MSA_FPGA_OE* 187 2, 3 WS* OCB_Write_Strobe* 183 2 RS* HSRO_Data(11) 153 4 PROG* Config_Chip*(x) 122 DONE Chip_Configed(x) 120 CCLK (unused) 179 RDY/BUSY* Chip_Status*(x) 174 5 D0 OCB_Data(0) 177 D1 OCB_Data(1) 173 D2 OCB_Data(2) 159 D3 OCB_Data(3) 152 D4 OCB_Data(4) 148 D5 OCB_Data(5) 141 D6 OCB_Data(6) 129 D7 OCB_Data(7) 123 HDC HSRO_Token_Out* 64 6 LDC* (unused) 68 8 INIT* HSRO_Token_In* 89 4 DOUT HSRO_Data(0) 178 6 TDO 181 7 TDI 6 7 TCK 7 7 TMS 17 7 Notes: (1) This connection of M0, M1, M2 selects Asynchronous Peripheral Configuration Mode (2) The trailing edge of CS1 AND CS0* AND WS* is used to accept configuration data. This means that the data will be latched on the trailing (rising) edge of Write_Strobe*, unlike a standard On Card Bus write. The data is guaranteed to be stable for BOTH transitions (3) CS1 must be HIGH for configuration to occur. Wiring it to MSA_FPGA_OE* enforces the rule that all MSA FPGA's must have their outputs disabled during configuration of any MSA FPGA. (4) RS* and INIT* should remain HIGH during configuration. This wiring performs that function even if the BSF FPGA has its outputs disabled. (5) RDY/BUSY* is thus visible in the Board Level Chip Status Register. Note that either the FPGA being configured (or the whole card) must not be enabled to generate VME Interrupts during FPGA configuration. (6) This wiring avoids driver contention during configuration. (7) These pins are connected as a normal JTAG interface. (8) LDC* could be used as an output. ---------------------------------------------------------- Appendix A: The Slave's View of a VME Data Transfer Cycle ---------------------------------------------------------- The standard read or write VME cycle (from the view of a Slave) is as follows: (0) The default state of the control lines are: On-Card Bus Chip Selects and Register Addresses: all LOW On-Card Bus Direction: LOW (WRITE) On-Card Bus Write Strobe*: HIGH Data x245 Transceiver Direction: VME->On-Card Bus (WRITE) Data x245 Transceiver OE*: LOW (outputs tri-stated but pulled HIGH on the On-Card Bus side with resistors) (1) The Master drives AS* low to indicate to the Slave that valid address information is present on the bus. The falling edge of AS* strobes the following lines to the slave: A01-A24, AM0-AM5, LWORD*, IACK* The slave must: - check to see if this card should wake up for this cycle: - IACK* must be HIGH (indicating normal cycle as opposed to an interrupt acknowledge cycle) - LWORD* must be HIGH (indicating a NON-D32 cycle) - AM5-AM0 must match one of the 4 valid modes ($39, $3A, $3D, $3E) - A23-A21 must be LOW - A20-A15 must match this card's 6-bit Card Address - if so: - drive the appropriate Chip Select and Register Address to the On-Card Bus - leave the On-Card Bus Direction LOW and Write Strobe* HIGH - leave the Data Transceiver Direction as VME->On-Card Bus - set the F245 Data Transceiver OE* HIGH (i.e. drive the [currently undefined] Data onto the On-Card Bus) (2) The Master drives DS1* and DS0* both LOW to indicate the beginning of the data phase of the 16-bit transfer. For WRITE cycles, the falling edge of DS1* and DS0* indicates that the Master has placed valid data on the bus. For READ cycles, the falling edge of DS1* and DS0* indicates that the Slave is free to place data on the bus. The falling edge of DS1* and DS0* strobes the following line to the slave: WRITE* The Slave must: - drive the On-Card Bus Direction line to the appropriate level (based on the VME WRITE* signal) - drive the Data Transceiver Direction to the appropriate level (based on the VME WRITE* signal) - leave the Data Transceiver OE* HIGH - if this is a WRITE cycle, wait a fixed time for the On-Card Bus Data and Direction signals to settle, and then drive the On-Card Bus Write Strobe* signal LOW - wait a fixed time and then assert DTACK* - for WRITE cycles, the falling edge of DTACK* indicates that the Slave has received the data (and the Master may remove it from the bus) - for READ cycles, the falling edge of DTACK* indicates that the Slave has placed data on the bus (but the Slave must continue to drive the data to the bus until the rising edge of DS1* and DS0*) (3) The Master will then drive DS1* and DS0* both HIGH to indicate the end of the data transfer phase. The Slave must: - return all signals to their default states (as in item (0)) (4) The Master will then drive AS* HIGH to indicate the end of the VME cycle. The Slave does not need to take any action at this time. ------------------------------------------------------ Appendix B: VME Data Transfer Interface State Machine ------------------------------------------------------ The VME Data Transfer Interface logic is implemented as a Mealy state machine. The state diagram is as follows : address match .-> Quiescent ------------------. .---. | ^ | ^ V V | DS[1:0]* <> 00 | `--' `-- Error <------- Wakeup -' | no AS* = 1 | | address | DS[1:0]* = 00 | match V | Begin_Data_Phase | | | | WRITE* = 0 | | WRITE* = 1 | V V | Strobe_OCB Read_Wait | \ / | \ / | \ / | || .--. DS[1:0]* <> 11 | VV V | or | DTACK -' AS* <> 1 | | `-------------------------------' DS[1:0]* = 11 and AS* = 1 NOTE: "address match" means: AS* = 0 IACK* = 1 LWORD* = 1 AM[5:0] = 111001 or 111010 or 111101 or 111110 A[23:21] = 0 A[20:15] = Card_Base_Address A[9] = 0 The inputs of the state machine are: Used in Used in Input State Trans. Output ----- ------------ ------- AS* X IACK* X LWORD* X AM[5:0] X A[23:15] X A[9] X DS[1:0]* X WRITE* X X The outputs of the state machine are: Board Select (used to gate OCB Address, Data, and F245 OE*) Error Detected (used to record a VME Error in the BCSR) OCB Direction OCB Write Strobe* VME DTACK* Enable Address Latch The outputs for each state are listed below (note: ALL outputs listed for Quiescent state, but only the outputs different from their quiescent values are listed for all other states): Quiescent: Board Select: LOW OCB Direction: LOW (WRITE) OCB Write Strobe*: HIGH VME DTACK*: HIGH Error Detected: LOW Enable Address Latch: HIGH This is the "nothing is happening" state. At this time, the OCB Chip Select* signals are forced HIGH, the OCB Register Address signals are forced LOW, and the OCB Data signals are forced to the Status/ID value. The F245 data transceivers have their outputs disabled. The state machine remains in this state until this card is accessed via VME, at which time the state machine progresses to the Wakeup state. Wakeup: Board Select: HIGH At this time, the Address is driven to the On-Card Bus, and the 245 drivers are enabled. The On-Card Bus Direction remains at the default direction of WRITE. The state machine remains in this state until either a D16-style data transfer phase is begun, at which time the state machine progresses to the Begin_Data_Phase state, OR the VME cycle is concluded, at which time the state machine progresses to the Error state. Error: Error Detected: HIGH At this time, the VME cycle has concluded without including a valid D16 data transfer. The Error Detected signal is set, and an error is registered in the Board CSR. The state machine remains in this state for a single clock cycle and then progresses to the Quiescent state. Begin_Data_Phase: Board Select HIGH OCB Direction: derived from VME WRITE* Enable Address Latch: LOW At this time, the On-Card Bus Direction is driven to the level specified by the VME WRITE* signal. For WRITE cycles, the On-Card Bus Data is being driven by the Master, and for READ cycles it is being driven by the selected FPGA. Also, all VME input signals except AS* and DS*[1:0] will NOT be sampled for the remainder of this VME cycle. The state machine remains in this state for a single clock cycle. For WRITE cycles, the state machine progresses to the Strobe_OCB state, and for READ cycles the state machine progresses to the Read_Wait state. Strobe_OCB: Board Select: HIGH OCB Direction: derived from VME WRITE* OCB Write Strobe*: LOW Enable Address Latch: LOW At this time, the On-Card Bus Write Strobe* is asserted. The state machine remains in this state for a single clock cycle, and then progresses to the DTACK state. Read_Wait: Board Select: HIGH OCB Direction: derived from VME WRITE* Enable Address Latch: LOW At this time, the On-Card Bus is waiting for the data to be read from the selected resource. The state machine remains in this state for a single clock cycle, and then progresses to the DTACK state. DTACK: Board Select: HIGH OCB Direction: derived from VME WRITE* VME DTACK*: LOW At this time, the VME DTACK* signal is asserted. The state machine remains in this state until the VME cycle is concluded, at which time it progresses to the Quiescent state. Note that this synchronous state machine has ASYNCHRONOUS inputs. Therefore the possibility of capturing the inputs while they are unstable exists. This presents the possibility of error if multiple coordinating inputs are required to change states, and ALL of the coordinating inputs may change "simultaneously." The following transitions are potentially therefore problematic: (1) Quiescent -> Wakeup The VME signals AS*, A[23:13], IACK*, and LWORD* are used to make this transition. The VME Specification requires Masters to allow all signals strobed by AS* to settle for 35 ns before asserting AS*. This transition is therefore guaranteed safe by the VME Specification. (2) Wakeup -> Begin_Data_Phase The VME signals DS[1:0]* are used to make this transition. These signals may change "simultaneously." However, assuming that only possibility is that one falls before the other, then the state transition is simply delayed by one clock cycle. There is another very unlikely possibility. If the Master attempts a D8 transfer, but glitches both DSx* lines low, and this glitch is caught by the state machine clock, then THE card will perform a D16 transfer when the Master only expects a D8 transfer. The cycle would complete "normally." Only extremely poor Masters would glitch the DSx* lines, and in any event D8 accesses to THE card should not be attempted as they are not supported. (3) DTACK -> Quiescent The VME signals DS[1:0]* and AS* are used to make this transition. These signals may change "simultaneously." The worst case possibility is that the state transition is delayed by one clock cycle. Finally, note that asserting VME SYSRESET* will return the state machine to the quiescent state from any other state. ------------------------------------------ Appendix C: VME Interrupter State Machine ------------------------------------------ The VME Interrupter logic is implemented as a Moore state machine. The state diagram is as follows : IR = 1 .-> Quiescent ---------. .---. | ^ | ^ V v | else | `--' `----- Interrupt_Requested -' | else IR = 0 | ^ | | | | | | IACK cycle AND | | | IACK cycle AND else | A[3:1] = 100 | | | A[3:1] <> 100 .---. | v | v v | | IACK_My_Interrupt | IACK_Downstream_Interrupt -' | | | | | else | | | AS* = 1 AND | .--. | `----' DS[1:0]* = 11 | | v v | `- DTACK_My_Interrupt | | `------------------' IACK* = 1 AND IACKIN* = 1 AND AS* = 1 AND DS[1:0]* = 11 NOTE: (1) "IACK cycle" means: AS* = 0 IACK* = 0 IACKIN* = 0 DS[1:0]* = 00 (2) Interrupt Request is generated as follows: .----. Chip Status(31:0)------------|bit | .----. .----. |wise|-/---| OR |--| | Chip Interrupt_Enable(31:0)--|AND | 32 `----' |AND |-- Interrupt_ `----' | | Request Global_Interrupt_Enable-------------------------| | `----' The inputs of the state machine are: Used in Used in Input State Trans. Output ----- ------------ ------- Interrupt Request X AS* X IACK* X IACKIN* X X A[3:1] X DS[1:0]* X The outputs of the state machine are: VME IRQ4* VME IACKOUT* VME DTACK* Disable Interrupts Drive Status/ID The outputs for each state are listed below (note: ALL outputs listed for Quiescent state, but only the outputs different from their quiescent values are listed for all other states): Quiescent: VME IRQ4*: HIGH VME IACKOUT*: IACKIN* VME DTACK*: HIGH Disable Interrupts: LOW Drive Status/ID: LOW This is the "nothing is happening" state. The state machine remains in this state until the on-card logic requests an interrupt by asserting Interrupt Request, at which time the state machine progresses to the Interrupt_Requested state. Note that while the state machine is in this state, it must propagate any IACKIN* falling edges to IACKOUT*. Interrupt_Requested VME IRQ4*: LOW VME IACKOUT*: HIGH At this time, the state machine is requesting a VME level 4 Interrupt. The state machine remains in this state until either a VME level 4 Interrupt Acknowledge cycle is begun, at which time the state machine progresses to the IACK_My_Interrupt state, or a VME non level 4 Interrupt Acknowledge cycle is begun, at which time the state machine progresses to the IACK_Downstream_Interrupt state, or the Interrupt Request is de-asserted, at which time the state machine progresses to the Quiescent state. IACK_Downstream_Interrupt VME IRQ4*: LOW VME IACKOUT*: LOW At this time, the state machine is propagating a VME Interrupt Acknowledge to a downstream Interrupter. The state machine remains in this state until the VME Interrupt Acknowledge cycle ends, at which time the state machine returns to the Interrupt_Requested state. Note that the earliest opportunity is taken to return to the Interrupt_Requested state (the state machine does not wait for IACK* and IACKIN* to return high). This is done to maximize exposure to the VME level 4 Interrupt Acknowledge which the state machine is expecting. IACK_My_Interrupt VME IRQ4*: LOW VME IACKOUT*: HIGH Drive Status/ID: HIGH At this time, the state machine is responding to the VME level 4 Interrupt Acknowledge cycle directed to this card. The 16-bit Status/ID word is being driven onto the VME Data bus. The state machine remains in this state for a single clock cycle, after which the state machine progresses to the DTACK_My_Interrupt state. DTACK_My_Interrupt VME IACKOUT*: HIGH VME DTACK*: LOW Drive Status/ID: HIGH Disable Interrupts: HIGH At this time, the VME DTACK* signal is asserted. Also, the VME IRQ4* is removed, and this card is disabled from generating a new VME level 4 Interrupt (the Global Interrupt Enable flip flop is reset by the Disable Interrupts signal). The state machine remains in this state until the VME Interrupt Acknowledge cycle ends, at which time it returns to the Quiescent state. Again, it is important to verify that no erroneous state transitions can occur. (1) Interrupt_Requested to IACK_My_Interrupt/IACK_Downstream_Interrupt This transition is "safe" due to the VMEBus specification guarantee that the falling edge of AS* will trail the assertion of A(3:1). (2) IACK_Downstream_Interrupt to Interrupt_Requested The thing to be concerned about in this transition is the potential danger of missing it in back-to-back Interrupt Acknowledge cycles, where the second Interrupt Acknowledge cycle is intended for this card. The VMEBus specification guarantees that the minimum turn-around from AS*/DS* high back to AS*/DS*/ IACK*/IACKIN* low is 40 ns. This is not overly generous, so we should prohibit back-to-back Interrupt Acknowledge cycles or verify that there is more slack in the timing of the Vertical Interconnect. (3) DTACK_My_Interrupt to Quiescent The worst case with this transition is simply a one-cycle delay in returning to the Quiescent state. Finally, note that asserting VME SYSRESET* will return the state machine to the quiescent state from any other state.