Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
L2 Processor Status Stephen Miller December 7, 2001 L2 Trigger Review
L2 Processor Status • Hardware Status • 5 RevD Production boards • 1 in use at B0 since the summer • 2 in use at B0 for last 1-2 months • 2 in Michigan being debugged • 1 identified problem on each board • 5 Rev C Production Boards • 1 Pre-production board used at B0 since January • 4 production boards at Michigan with bad vias. • Would require different amounts of time to make functional. • 1 board was at B0. New bad vias every few months. • This design requires wire mods to run in fully optimal mode • Don’t plan on making these boards functional • 2 Prototype Boards • 1 functional board used in tests at Michigan
L2 Processor Status • Board performance • Boards work very reliably • Used in lots of runs (including tagging mode this summer) • Control firmware and software works well • No problems receiving data from interface boards • Multi Alpha Tests • Cosmic runs with 3 alphas have been run at 20KHz • 1 Alpha reads data loaded in other alphas to check for errors • Need to improve code for reliably running multiple Alphas
L2 Processor Status • Board performance cont… • Reading Reces over Magicbus • Alpha reliably reads Reces in standalone tests • During running, reading Reces leads to DoneTimeout Errors from Crate • Conflict is with VME read of Alpha immediately following an Alpha read of Reces • Problem is due to how PIO fpga terminates the PCI transaction in the Alpha • Having the crate controller retry several times on a VME Berr alleviates the problem • Will study the problem in a teststand at Michigan to fix the PIO firmware • MBus arbitration problems reading Reces can be solved by checking that interface boards have sent data. • Makes processing time for that event > loading time for next event. • Alpha to Alpha reads/writes • PIO firmware was improved to allow Alpha to Alpha writes over MagicBus. • Alpha to Alpha read functionality still needs to be fixed. • This is not a requirement for CDF or D0 operations.
Improving Performance • Board improvements • Improved control firmware • All control functions currently done by software read/writes to fpga registers • Includes getting L1A, configuring DMA buffers, sending startload, checking mod_done bits, sending decision to the Trigger Supervisor. • Each PCI transaction takes about 150 to 200ns. • There is 5 to 10 us of overhead each event for these transactions. • Much of this functionality has been put into fpga firmware (work by Josh Davis at Michigan) • Will reduce overhead to 1 to 2 us per event. • Potential for even further improvements, but would need new firmware • Firmware needs further testing at B0 and new control code debugged. • Optimized software will also give some improvements.
L2 Processor Tests at B0 • Additional Multi-Alpha tests • Need to improve Alpha software • Test with beam at high rates • Tests of Reading Reces • Once new firmware is ready can test with Cosmic run • New Firmware tests • Need tests with interface boards sending data • Cosmics tests sufficient to verify operation • Testing of spare Alphas • Need to fix remaining 2 Alpha boards at Michigan
Maintaining Boards • Documentation • Extensive documentation for the AlphaPC164 motherboard and Alpha CPU • Document written specifying functionality of FPGAS • Need to provide document for general L2 expert • Schematics exist at B0 and as postscript. Will put files on B0 web page • Debug Software • Some test utilities part of the EBSDK code • Alpha based program for VME and MagicBus tests with 1 or more Alphas • Standalone C programs on Linux boxes • Used to read registers/status of Alpha • Provides standalone tests of interface boards with the Alpha • Need to organize code in CVS
Summary • Alpha boards function very well • Have provided reliable operation at B0 • Focus now shifting to trigger algorithm code (see other talks) • Several improvements needed for fullest functionality • Reces Readout with improved firmware • New control firmware for higher rate operation • Improved software for Multi-Alpha running • Can do tests without beam, but will need Cosmic tests with system