190 likes | 311 Views
TELL1 A brief introduction to the Device Unit Panels. This is just a brief overview! In fact the panels itself are a tutorial: we put many info buttons and tooltips on them! (from v2r3p6 upwards) So please start exploring them after the tutorial. Overview:.
E N D
TELL1 A brief introduction to the Device Unit Panels Tutorial - Panels
This is just a brief overview! In fact the panels itself are a tutorial: we put many info buttons and tooltips on them! (from v2r3p6 upwards) So please start exploring them after the tutorial. Tutorial - Panels
Overview: Shows the type of detector – indicates if something is wrong with communication (e.g. subscription) Counts triggers and resets. BNCnt should run continuously. MEPS transm. not necessarily sent from GBE! MEP factor calculated as L0Accept/MEPtransm. On board temperature probes. Click on board to evaluate the status of Tell1 board. checks if server is running, TTC fibre plugged, port enabled but not plugged, compares values of counter registers, if throttles are arriving and memories over- flows. Foreseen to add more counters. pop-up Check if versions are compatible. If unsure ask! all frmwr versions should have the same number Link is UP, if port is enabled and cable physically plugged. The monitoring rate of the panel’s registers can be changed. Data transmission rate of well formatted data and mal formatted data sent from the SyncLink to the GBE. Dest. Mac address must be formatted with the MAC address of the event builder – otherwise packets will be lost! Tutorial - Panels
Status & Diagnostics: Each main part of the board is evaluated for functionality. (as before) It configures automatically according to board type (DACs or ORx) Data transmission between SL and PP: 100% = 3,7 Gbits/s Calls Linux command ‘ps’ Rate of assembled and linked events. MEPs scaled down by MEP factor. Read and write must be the same. L0Accept must be the same as Linker rate. Throttle: 1unit = 25 ns. Percentage is displayed red, if total used bandwidth exceeds 80%. Takes into account number of enabled ports. Each port 0.9Gbits/s. Tutorial - Panels
Color code for link status GBE: Tx bandwidth history in Mbits/s – fullscale 1Gbit/s Tx & Rx rate: percentage of link bandwidth 1Gbit/s=100% TxOK: total data transmitted since start (Gbits) TxError: GBE checks the CRC check-sum. Serious communication problem if not zero! PHY chip info read over MDIO interface – see MAC datasheets Source MAC&IP: each port supposed to be the same – strict numbering scheme! Dest. MAC address: must be configured with MAC of event builder. Dest. IP address: last two bytes assigned by TTC (or ECS). Tutorial - Panels
TTC & Flow Ctrl: If sent by TTC, this number must be L0Accepts/MEPfactor Last received destIP and L0EventID IP packets and MEPs sent to GBE must not necessarily be sent to network! Compares LSBs from TTC with internal counter TTC triggers and types should have the same number! Resets sent by TTC Do not disable – except snapshot is sent by TTC. Buffers are monitored and protected against overflow. No throttles but internal flow-control! Current signal remains logged (log) for 10us. Throttles mainly caused by zero suppression or GBE bandwidth! 1 count = 2ms TTC Buffers for L0Accept, L0TriggerType, DestIP assignment, MEP end buffer Tutorial - Panels
Throttles in a nutshell: If PP buffers on SL are almost full, a signal is sent to PP to throttle. If buffers on PP are almost full and no detector frames can be received any longer, a throttle signal is sent to the SL and further to the LVDS connector. TTC Buffers for L0Accept, L0TriggerType, DestIP assignment, MEP end buffer PP0 PP0 SL PP1 PP1 LVDS TTC buffers should not fire because the FE derandomizers would fire already before. PP2 PP2 PP3 PP3 If MEP buffer is almost full – mainly due to limited bandwidth - a throttle is sent. But please check if Dest.IP buffer is not zero. Without destIP no data can be sent from GBE! Tutorial - Panels
Process Monitoring: To be short: This is an expert panel which monitors detector frames, banks and events sent from PP and received on SL, etc. On the SL number of assembled events and MPEs written into MEP buffer are monitored. Tutorial - Panels
Buffer Monitoring: • Diagnostics of Tell1 operation – • use in counter mode in order to • see the tooltips. • FIFOs full mainly due to GBE • overload. If there is any overflow • check first if throttle is connected! • Diagnostics: • connect to throttle network • sent few thousand triggers at the rate you find a problem • stop triggers – FIFOs must be empty! • If one FIFO is full – read the tooltips to get a hint what the problem could be. Tutorial - Panels
Run Control: Operation of Tell1 – quite intuitive now… For test purposes the Tell1 can generate its own triggers: dest.IP and trigger type can be set statically via ECS. set the desired ECS trigger configuration and click on ‘Send ECS triggers’ to execute. Data generator on PP-FPGAs: data from Rx cards not accepted. Just enabled links are taken into account. For raw bank format see EDMS note: 565851v.5 Raw-data format. error banks can be disabled. Reset for: L0FE, BCnt, L0EvCnt Fake throttles: to test throttle network – total throttle counter in TTC panel should increase continuously. Tutorial - Panels
The User Specific Part: Last 4 MEPs are read from MEP buffer. Visualization for the various banks to be written by users. Monitoring of user-specific registers. Probably with buttons and pop-up panels? Tutorial - Panels
Recipes: If this happens you are in trouble! e.g. recipe types will not be recognized,… Sub-recipes for common, network and user-specific parameters. Configure is the same function as in the FSM: It resets the Tell1, applies hard coded sequences and the recipe selected in the combo box. Select sub-recipes above and assemble them with the name in combo box. Registers can be read directly from hardware and stored as recipe. You can write the cfg file before. Recipes are stored with hardware name. You can export and import them between different Tell1 boards. Tutorial - Panels
Recipes: Sub-recipes for common parameters and network parameters: Panels are similar and intuitive. Load recipe means that values are taken from DB & written to widgets. Save recipe means that values from widgets are stored in DB. Tutorial - Panels
Recipes: The interface to the user-specific recipes have to be implemented by the sub-detectors. Meanwhile you can use the cfg file: write to hardware and save a complete recipe. Tutorial - Panels
Conclusion: Many panels – try to use them and understand them. Make use of the tooltips and info-buttons. If you are lost please ask. The time to change them is the next 3 weeks then we have to ‘attack’ (together) the next topic: FSM Please use this time to give suggestions for potential improvements – after this it will be handed over to (?) the users(?) (at least no Cedric and no me) Tutorial - Panels
In case there are bugs: Do not just think on what is not working – try to see also what is already working well. It was a long way to go (many layers) - suggestions for improvements always welcome! I hope this common approach could save a lot of time for the entire collaboration. In fact it was much more than our actual responsibility was. Please come to the Thursday meetings – or at least look at the slides afterwards. Tutorial - Panels
Goals till mid of February: All sub-detectors know what to do and how to operate the boards. The development on common-panels will be frozen. All sub-detectors can configure properly their boards and know how to verify this via command line tools. Confusions with firmware releases and wrong addresses should not happen anymore! (I know some sub-detectors have passed these milestones already…don’t worry we will continue soon. But I really prefer to focus now together on a few topics at a time and have a coherent field of users!) Tutorial - Panels
Important Note • Cedric will also be not available anymore – • and he has done already a lot of work: • - defined all recipes for all sub-detectors and did also the graphical representation. (this is a tricky part, so it was done by us) At least use the panels and test them. • for the Data Monitoring: the last 4 MEPs are read. ST and Velo • got a graphical representation. The others have to parse the strings according to the protocol. (if they wish so) • - specific panels: Again VELO and ST got a special service. If the others want to see their parameters feel free to add your panels. Tutorial - Panels
Next Step: Velo will already work and gain experience with a more sophisticated FSM. (maybe Calo wants to join?) I could not test it in December and had just a quick look yesterday in order to recapitulate what I have done. I will put it on the web but don’t bother. This will be done properly once I will be back. With proper testing it could become already beginning of March. Tutorial - Panels