1 / 5

Updates from B904

Updates from B904. Andrew Peck & Shayan Rastegari March 06, 2014. ALCT- Tx issues resolved… sort of See Elog : http://cmsonline.cern.ch/cms-elog/815209 Indara and I traced the issue to some problems with the compiler. Karoly soon found that:

mindy
Télécharger la présentation

Updates from B904

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. Updates from B904 Andrew Peck & ShayanRastegari March 06, 2014

  2. ALCT-Tx issues resolved… sort of • See Elog: http://cmsonline.cern.ch/cms-elog/815209 • Indara and I traced the issue to some problems with the compiler. • Karoly soon found that: • “ALCT tx/rx scan fails to find a good window if the code is compiled with g++ flag -O set to 0 (no optimization). It works with -O1, therefore optimization has now been re-enabled.” • So it works now, but something must be more fundamentally wrong. Changing compiler optimization flags shouldn’t break code.. • Chamber testing almost done: • The last two chambers were put on the table late this afternoon.. Should be done tomorrow midmorning. • Finally got Vidyo working last night… • Took way too much time • Slow Control Firmware • Joonas’ slow control firmware works, was tested on chamber. I had to hand edit the .svf file to get it to load.. Joonas is trying to duplicate in software what I changed. • Now the question of how to load the slow control firmware onto chambers. • Impossible without software modifications

  3. UCLA Test Stand at CERN • Found that IMPACT is very picky.. Version 14.1 (when installed here) only cares to work for TMB Mezzanine + Spartan 6 Mezzanine and fails when programming any other prom. Don’t know why. • Installed an old version (8.1) which we also have at UCLA. It programs everything EXCEPT the TMB Mezzanine + Spartan 6 Mezzanine... Between the two versions it is working ok though. • Found a (small) problem, with the Loopback Backplane. • Misreads one GND signal as being high • Not ideal… but its not a showstopper. Can ignore this error.. Or replace the backplane, or attempt to repair it. • Started writing a manual documenting how to setup the test stand from scratch. A few pages long now, and almost done. • Also putting together a big tar file that will have all of the drivers, proms, test software in one place. And its just small enough to put on the twiki. • Xilinx installers are too big though.. • Also updating the test manuals a little bit, clarifying some things.

  4. Muon Injection Code • Have been working on porting the muon injection tools from the UCLA test software into emulib. • The extracted software now compiles fine in Linux. • ~10,000 lines of code … • Today set up TriDAS in my LXPLUS account.. Both TriDAS and the UCLA code compile OK there.. • Started digging into TriDAS code and found some portion of the injection code is already implemented. • InjectALCT and InjectCLCT were implemented in TMB.cc but are commented out. Maybe they aren’t working? • These two functions contribute only about 6% of the trigger menu code.. So its not a huge time saver but is a very happy starting point for inserting more. • A small pain: • The UCLA code is interactive. The TriDAS code not so much.. So have to replace all the interactive prompts. With configuration files…? • Looks like maybe 350 prompts in the whole code.Okay.. Can do.

  5. Muon Injection Code (continued) • A bigger pain… but good to do.. • UCLA code explicitly writes data to registers.. emuLib uses specific functions for each purpose. E.g.: UCLA:emuLIB • Finding existing functions in emuLib, and writing new functions is straightforward but tedious. Something to do later… // Turn off CCB backplane inputs, turn on L1A emulator adr = ccb_cfg_adr+base_adr; wr_data = 0x003D; status = vme_write(adr,wr_data); // Turn off CCB backplane inputs, turn on L1A emulator DisableExternalCCB(); EnableInternalL1aEmulator();

More Related