120 likes | 302 Views
M. Noy 21.05.2004. Progress Report. Test Bench Architecture. Updated Architecture Improved modularity, and test separation through ABC Preprocessor reduced in complexity Added automatic report generation framework Hierarchical web pages for results and log info.
E N D
M. Noy 21.05.2004 Progress Report
Test Bench Architecture • Updated Architecture • Improved modularity, and test separation through ABC • Preprocessor reduced in complexity • Added automatic report generation framework • Hierarchical web pages for results and log info. • Added crate detection mechanism • “One click” detection of crate contents • Previous sequence architecture now loops over FEDs (detected) in crate. • Now been placed in the Fed9U project
TBTestABC • Has 4 pure virtual functions • Initialise(), Exercise(), Analyse(), Finalise() • Called in sequence during test exe. • Fin. Is like destructor, and is called in abnormal term. • Redundancy here, can use class destructor... • Static Instantiator provides handle to TB • Constructor is passed reference to test param. “bag” • User variables • FED crate entry, BA, SN of DUT • Ref to component status container -> results • Results manager -> results dir struct • req. FED SN, (request submitted to savannah)
TBTestABC contd. • Test Generation Script • Produces class skeleton • .hh, .cc, function stubs, instance macro • Test Parameters File (.tpf) • Handle for LUT (default can be changed) • Additional Makefile include search, link search, and libs • Key for the PreProcessor • tests without a .tpf file are ignored
Report Generation • Fed9UComponentStatus ABC • Each component needs a status class inheriting from this • Implement method: • virtual void fillReportElement(Fed9UReportElement &)=0 • Interface to the Fed9UReportElement • Uses component type + Fed9UAddress for unique ID • Fed9UReportElement • Interface between Comp. Stat. and Fed9UReportGenerator • Report is made from multiple elements, one for each component • Containers are standard, report generator parses the component status container, generating ReportElements, -> Report • Invoked after each FED is tested
ResultManager • Manages TB output directories • FED Ser No. key for dir struct. • Maintains test instance no. • Allows consistency for repeated tests • Helps web page hyperlink management • Used to manage local test logging • TBD, but will simply use new instance of existing TB system log (has modified streamers for time stamp, banners, etc.) • This log will have link on FED specific results page • Similar to existing system/error log.
Test Status • Written a TrimDAC test • Test Module • Fed9UTrimDACStatus • (:public Fed9UComponentStatus) • Used to test report generation • Uses ROOT fitting algo. • But have seen problems traced to root libs that cause system to behave unreliably • Slowed progress -> possible alternative...? (cernlib? suggestions welcome) • Demostration will be prepared for week of 7th June
This week... • Atomicity in BLT readout (or not) • JF, LM + MN tried readout with 2 FEDs • Problems seen when one FED reads out + 2nd FED polling for events. • Traced to conflicts between logically concurrent use of block/single accesses to the SBS • Solved using IPC semaphore • Makes event loop in Fed9USupervisor atomic • Then saw new problems with event corruption. (Wed.) • Firmware version made no difference • Switched FED off -> yesterday readout ~100000 events with no problems • ?temperature -> needs study