MASTER End Vertical Interconnect ------------------------------------- Original Rev. 8-NOV-1998 Most Recent Rev. 6-APR-2007 Setup of the MASTER end Vertical Interconnect for use in the Run II Trigger Framework. The idea is to have all of them setup in a standard way. No MC68153 installed at U25 ! No MIZAR installed at U20 ! AM7968 TAXI chips installed at U21, U22, U23, and U24 AM7969 TAXI chips installed at U31, U32, U33, and U34 The 3 quad PALs (U13, U37, and U39) plus the 6 dip PALs (U38, U40, U41, U46, U48, and U49) are all installed. Switch SW1 For the Master end VI the first 6 keys of SW1 pick the base address of the 64 mega byte block used by the Master end VI module. Key #1 is the MSB. In Run II we map a Master VI to each rack. See the file MSUTRGROOT_II: [HARDWARE.COMM_CRATE]VME_COMMUNICATION_CRATE.TXT for background information. SW1 Key Number ----------------- 1 2 3 4 5 6 - - - - - - 0 0 0 1 0 0 Rack M122 (Scalers) 0 0 0 1 0 1 Rack M123 (L1FW) 0 0 0 1 1 0 Rack M124 (SCL + VRB) 0 0 0 1 1 1 Reserved - - - - - - A A A A A A 3 3 2 2 2 2 1 0 9 8 7 6 ----------------- High Order VME Address So the highest 4 bits of the VME address are always 0001. Close the switch key to select a 0 in the VME address. For our use we will just close the last 3 keys on SW1, i.e. key 7,8,9. They have to do with selecting the Master's I/O only when A31 through A16 is all $FFFF. J1 through J8 all have jumpers ! Cable Shield is grounded at master end J9 jump pin 9 to 10, jump pin 11 to 12, jump pin 13 to 14, jump pins 15 to 16. ! This passes all 4 levels of VME Bus Request through this card. J10 open ! SYSCLK NOT Enable. J11 jump ! BERR Enable Enable BERR onto the Module (if not slot 1 controller) or onto the VME Bus (if slot 1 controller) jump --> enable J12 all open ! This card does not request the VME Bus. J13 jump ! Enable this card to be the VI master end. With proper PALs installed then this jumper makes this card a VI master. J14 open ! Enable Priority If the arbiter is enabled (J15) then J14 picks the type of arbitration jump --> priority open --> round robin. J15 open ! Enable the arbiter and other slot 1 functions. jump --> enable J16 open ! Enable transmission violations to halt the on going cycle in the slave crate jump --> enable. The examples of Master end VI modules that I have seen have two wire wrap wires on the solder side in the neighborhood of U41 to U48. I do not know what these wires do or if they are necessary for a versions of pcb and/or PAL code. 29-SEPT-2000 The URL for the Vertical Interconnect document is: http://www-linac.fnal.gov/LINAC/hardware/vmesys/boards/vi/viInfo.html 6-APR-2007 Generating a VME SysReset* in the Slave Crate The following are notes from April 2007 about how to talk to the VI Master so that it will cause a VME SysReset* to be issued in the Slave Crate. In the beginning we could make this work when we were using a 68k cpu module as the Bus Master and as the initiator of the VME Cycles in the Master Crate. The target Slave Crate was Slave 0 of Master 0, i.e. TFW M122 Top. If the 68k did a D16 Write cycle to $ffff1018 then we would see SysReset* asserted low for 400 mill sec in the Slave Crate. - The 68k cpu module is setup so that when addresses in the range $ffffxxxx are used in VME cycles then the cpu module will assert the A16 Address Modifiers for these cycles. - During a write to $ffff1018 I looked at the Master VME Crate Address Lines and in fact the 16 high order address lines were High. - It appears that the way that a 68k cpu module works is that, if it is Bus Master, then the 68k address bus is just always being broadcast on the VME Address Bus Lines. There is constant movement of the VME address lines but only once in a while do you see an AS* on the VME bus which indicates a real VME cycle. - As a test I wired to Gnd address line A18 in the Master VME Crate. This is a high order address line that was normally Low (while the 68k bug monitor was running around doing things) and it appeared that A18 only went High for the write to $ffff1018. When I forced A18 Low then the VI Master did not respond to the cycle, i.e. the cycle timed out, and there was not a SysReset* in the Slave VME Crate. This proved that the VI Master is paying attention to the 16 high order address lines even during an A16 cycle. - We had assumed from the VME specification that with an A16 cycle that only the low order 16 address lines were used (should be used) to select the target VME module. But it is clear that the VI Master decodes all 32 address lines even during an A16 cycle. We now tried to make this work using a Bit-3 618 pci to VME card pair. Initially we could not make this work. The way to make it work is the following: - set the address to $ffff1018 (not to $00001018) - Set A16 - Set D16 - Set the API interface to the Bit-3 This works OK and you see the SysReset* asserted for 400 mill sec in the Slave Crate. It does not work if you pick the DMA interface to the Bit-3. I have some concerns about getting all versions of Bit-3 to generate these unusual VME cycles, i.e. A16 cycles with a specific value on the 16 high order address lines. Some versions of Bit-3 Driver software may not pass the high order address information to the Bit-3 hardware when the user asks for an A16 cycle. Some version of Bit-3 hardware may not even drive anything on to the 16 high order address lines when the user asks for an A16 cycle. Do all version of VI work the same way ? Do all version of VI make a 400 mill sec asserted SysReset* ?