- Generated by
1.9.2
|
pflib v2.7.0-1-gd371ab6a
Polarfire Interaction Library
|
The main executable product of pflib is the pftool. This executable is designed to offer low-level through high-level interactions with the polarfire connected to HGC ROC(s). This tool opens up a rudimentary terminal with various menus and submenus with commands for configuring the chips and aquiring data.
Look at the [detector](detector) subdirectory for the detector-wide (multiple polarfire) configuration executable.
This document is meant to give an overview of its design and provide some manual documentation on its properties. We assume that pftool is already successfully built. More detail about the menu commands within pftool is given in the documentation of pftool.cc.
A successful open of the tool looks like
Notice that the firmware version is printed. This shows a successful connection to the polarfire. The indices of the active DAQ links are also printed which can help the user double-check that their pftoolrc was loaded successfully.
The listing of commands in your current menu is always printed after you execute a command. I will omit these menu printouts in this document. The commands are listed in all-caps, but the tool is case-insensitive, so I will often list the commands in all lower-case.
The pftool looks at the following locations for a RC file to load configuration options.
PFTOOLRCpftoolrc in the current directory.pftoolrc in your home directoryTip A potentially helpful alias is to prepend pftool with the environment variable so that pftool always loads the RC file in this repository.
This specific alias assumes that pftool is installed to a directory in the PATH environment variable.
uHal needs to load a set of XML files defining the IP-bus mapping. You can support this by either running pftool from within the uhal directory or by providing the full path to that directory using the ipbus_map_path parameter in the RC file.
You can leave the tool at anytime by pressing ctrl+C.
Below I list example printouts of specific commands along with follow-up comments. The tool cannot currently handle directly entering a command from a sub-menu. You will need to enter the submenu before entring the command. For example, DAQ.STATUS should be interpreted (in keystrokes) as DAQ<Enter>STATUS.
At UMN, we only have one HGC ROC and therefore only two active links. This means all of the links except for the first two are fully zero suppressed (ZS == 1).
The ID number is defined during the execution of daq.standard and is (<fpga-id> << 8) + <link>. This is the status for a "standard" setup. You can get back to the "standard" setup by running the daq commands hard_reset, standard, enable (in that order).
This sets the HGC ROC back to its power-on default state, including resetting all of its parameters. If this command is issued, any ROC parameters that were loaded (via roc.load need to be re-loaded).
This forcefully clears the event buffers as if a run wasn't started and resets any DAQ parameters.
This should show the "idle" pattern (ac cc cc cc repeated) when the link is behaving correctly.
Theses parameters help "align" the links so that they correctly show the "idle" pattern when you elinks.spy. The values should be relatively constant for a given physical chip and firmware version even if they need to be reset when the chip is restarted.
These parameters should be stable for a given setup. Across setups, the readout length should be 40. For UMN, the delay should be 15.
This can be done after a roc.hard\_reset and helps maintain link stability.
A known uMNio firmware bug (that has been patched in later versions by Jeremy), leads to an inability to read some parameters. This causes the defaults for this command to always be 0 even though the actual registers are (probably) updated successfully. Users may wish to always set these parameters on every entry into pftool just to be safe.
115 1.9.2