Myron, Stephen Here are some of my notes from Wednesday March 11, and a bit from discussions afterwards. Myron/Stephen to do: ------------------------------ Fred is 16 in + 16 out bits would be fine. Input bit format would be nice to be compatible with single-ended TTL; output bit format whatever you find convenient. web location of CDF VME crate spec [I found http://www-ppd.fnal.gov/ett_www/CDF_docs/CDF2388/CDF2388.htm is this the right one?] Power supply requirements for Alpha Place docs on web and notify Jim to update pointer page: MBus updated logical specs, timing diagrams, electrical, etc... Block Transfer I/O description talk, specs, performance measurements, user manual... Programmed I/O same Address-space information details, PCI setup specs for all UM additions needed if we are to help with bootup/initialization code. Equipment list for Alpha checkout stand including VME to MBus cards (built by U Mich) Cache to 2MB if possible. Some D0 users might thrash cache without this. Raise broadcast address lines from 8 to 10. Will let you know asap if need for more might arise. Pursue set up of interrupt generation on Alpha board: We intend to use one reset and 2 interrupts; we discussed only a) and c) today. a) Hardware reset(from VME data cycle initiated outside the Alpha card, via Tundra) to initiate reloading of executable; same functionality as hitting RESET on front panel. MSU to modify flash rom code to automate reloading of executable. So this is not really an interrupt strictly speaking. If this is CDF's SYSRESET, we still need an alternate means to activate this function--don't have your controllers. b) VME-sourced interrupt to announce trigger control computer message. Administrator will look across VME to a multiport memory to see what the message is. Need a mechanism for this externally-generated VME interrrupts to be distinguishable from c). c) second distinguishable interrupt generated as described below to notify completion of loading of an event from MBus via DMA. D0 input protocol with MBT's: (one event is input at a time) ------------------------------------------------------------ Administrator sends GO to MBT (via either MBus message to MBT register, or rising edge of MBus START_LOAD) MBT recognizes all data for a new event available, begins block transfers to sequence of broadcast addresses MBT raises level MBT_end_event (DONE_OUT on MBus?) All participating Alphas signal AP_FIFO_EMPTY (open collector) At AND of MBT_end_event and AP_FIFO_EMPTY, an interrupt is generated on all participating Alphas In Interrupt routine, translation buffers changed for next event on each Alpha Administrator Alpha again sends GO to MBT, which drops MBT_end_event (before AP_FIFO_EMPTY drops) So the elements are an Alpha can have its contribution to AP_FIFO_EMPTY turned on or off an Alpha can have its generation of interrupt from AP_FIFO_EMPTY turned on or off thus allow removing of an alpha from data flow I believe you suggested implementing this as a writeable mask of elements contributing to an interrupt. Does the mask include just MBus lines, or perhaps control lines from the DMA controller as well, allowing local running with local FIFO_EMPTY rather than sensing the state of AP_FIFO_EMPTY? Jim to do: verify if need for more than 10 address lines verify if need for more than 1MB cache [2MB preferred] specify how many test stands needed check out whether CDF or VMEforPhysics crates needed, and how many [may need consulting to understand how/whether Alpha needs these signals] arrange manpower for checkout of production D0 alphas put more of MSU software notes on web (e.g. how to do C++) MSU to help writing user manual for Alpha, especially bootup and download description. Info from the day: cost est 10K/board for prototypes, 7K for final roughly 50K development (plus similar amount engineering?) sharing: 50% development, per-card on prototypes and production schedule May 1st prototype at U M MSU participates in boot-up, contributing software to set up PCI etc June 1 Alpha checked out at UM; MBus characterized D0 assist in MBus tests and/or Prog I/O performance tests +1 wk 7 prototypes built by Adco U M leads checkout; D0 participation July 3 MBus crates under way Aug D0 receives UM VME/MBus test cards end year production of Alphas D0 bought commercial test stand equip D0 checks out D0 Alphas UM is making a VME to MBus translation card for initiating single MBus cycles MBus arbitration scheme requires jumpering all non-MBus slots MBus terminators in VME slots 3 and 21 in scheme with 1,2 reserved terminators are transition cards 10ns memory not equivalent to 12 ns cache: extra address decoding, possibility of PCI conflicts CDF prefers to load its executable from a hard drive rather than ethernet CDF intends to develop an emulator with a shared memory environment so that online code runs unaltered: the PCI memory locations will be mapped to a shared memory area so that a second process can interact to simulate MBus interfaces and assist in debugging of the realtime aspects of the code. Under Alpha control, subsets of the data are read for an event: all data is not necessarily read for every event. CDF has 4 buffers in its interface cards, but effectively only 2 in the Alphas: an event loads while the second is processed. The Alpha polls for transfer completion on finishing event processing rather than depending on interrupts. CDF performs partial trigger decisions in 4 alphas (j, e, mu, misc), with results being combined by the trigger supervisor. CDF I/O requirements are estimated to be 27 MB/s; CDF acquires some data by DMA in block transfer mode, and other data by programmed I/O. The best guess for programmed I/O speed is 16MB/s If a MBus cycle fails, i.e. DStrobe w/o DDone, only way out is MBReset MBReset will be generated from a from PCI timeout for coupled cycles and needs TOY interrrupt or other means for uncoupled cycles [Is the PCI timeout just another interrupt, or has something special been done to hook it up to MBReset?] MBus arbitration took 10-15 ns last run [ECL Run I; CMOS Run II]