1 / 8

L2 Processor Status

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

simone-hubbard
Download Presentation

L2 Processor Status

An Image/Link below is provided (as is) to download presentation 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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. L2 Processor Status Stephen Miller December 7, 2001 L2 Trigger Review

  2. 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

  3. 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

  4. 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.

  5. 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.

  6. 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

  7. 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

  8. 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

More Related