TELL1 A brief introduction to the Device Unit Panels

Stefan Koestner Tutorial - Panels January 2008

TELL1

A brief introduction to theDevice Unit Panels

http://lphe.epfl.ch/potterat/TELL1/pvss/pics/fwTell1/pages/montroing.html

http://lphe.epfl.ch/potterat/TELL1/pvss/pics/fwTell1/index.html



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: Shows the type of detector – indicates if something is

wrong with communication (e.g. subscription)Counts triggersand resets. BNCnt should runcontinuously. MEPS transm. notnecessarily sent fromGBE! MEP factorcalculated asL0Accept/MEPtransm.

Foreseen to add morecounters. pop-up

Check if versions arecompatible. If unsureask! all frmwr versionsshould have the samenumber

The monitoring rate ofthe panel’s registers canbe changed.

Click on board to evaluatethe status of Tell1 board.checks if server is running,TTC fibre plugged, portenabled but not plugged,compares values of counterregisters, if throttles are arriving and memories over-flows.

On board temperature probes.

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 addressof the event builder – otherwise packets will be lost!

Link is UP, if port is enabled and cable physically plugged.



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.



GBE:

Tx & Rx rate: percentage of link bandwidth 1Gbit/s=100%

Color code for link status

PHY chip inforead over MDIO interface – see MAC datasheets

Tx bandwidth history in Mbits/s – fullscale 1Gbit/s

TxOK:total data transmitted since start (Gbits)TxError:GBE checks the CRC check-sum. Serious communication problem if not zero!

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




TTC & Flow Ctrl:

IP packets and MEPs sent to GBE must not necessarily be sent to network!

TTC triggers and types should have the same number!

TTC Buffers for L0Accept, L0TriggerType, DestIP assignment, MEP end buffer

Throttles mainlycaused by zero suppression or GBE bandwidth!1 count = 2ms

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.

If sent by TTC, this number must be L0Accepts/MEPfactor Last received destIP

and L0EventID

Compares LSBs from TTC with internal counter

Resets sent by TTC


Throttles in a nutshell:

PP0

PP1

PP2

PP3

SLPP0

PP1

PP2

PP3

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.

LVDS

TTC Buffers for L0Accept, L0TriggerType, DestIP assignment, MEP end buffer

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!

TTC buffers should not fire because the FE derandomizers would fire already before.


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.


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:1) connect to throttle network2) sent few thousand triggers at

the rate you find a problem3) stop triggers – FIFOs must be

empty!4) If one FIFO is full – read the

tooltips to get a hint what the problem could be.



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.

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.

set the desired ECS trigger configuration and click on ‘Send ECS triggers’ to execute.

Reset for: L0FE, BCnt, L0EvCntFake throttles: to test throttle network – total throttle counter in TTC panel should increase continuously.


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?


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.

Select sub-recipes above and assemblethem with the namein 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.

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.


Recipes: Sub-recipes for common parametersand 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.


Recipes:

The interface to the user-specificrecipes have to be implemented by the sub-detectors.Meanwhile you can use the cfg file:write to hardware and save a complete recipe.


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)


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.


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!)


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.


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.

TELL1 A brief introduction to the Device Unit Panels

Documents

Transcript of TELL1 A brief introduction to the Device Unit Panels