Adding regupdate.py script

828eb364 · Theodor-Adrian Stana · b833850c · 828eb364 · 828eb364
Commit 828eb364 authored Aug 28, 2014 by Theodor-Adrian Stana
Expand all Hide whitespace changes
Inline Side-by-side

Showing with 358 additions and 0 deletions

README software/regupdate/README +84 -0

regupdate.py software/regupdate/regupdate.py +274 -0

No files found.
--- a/software/regupdate/README
+++ b/software/regupdate/README
+This script connects to a create and checks that the values of the CHxPCR and
+CHxLTS*R registers are not written with wrong values.
+
+Basically, its purpose is to check that no 'sync' errors occur when the
+registers are read while pulses are also coming in to the PR.
+
+How-to
+======
+
+An example setup (and getting-started) to run the test:
+
+1. Grab a 3U (4-slot) ELMA crate
+2. Plug in three repeater cards (DUTs can be either BLO or RS-485, I have only
+tested with BLO), as follows:
+- slot 1: DUT
+- slot 2: BLO board with g/w v15.15 (pulsetest)
+- slot 3: DUT
+3. Make the following connections at the front panel (TTL connections)
+- slot 2 board CH1 OUT to slot 1 CH1 IN
+- slot 1 daisy-chain CH1 OUT until CH6 IN
+- slot 1 CH6 OUT to slot 2 CH1 IN
+- slot 2 board CH6 OUT to slot 3 CH6 IN
+- slot 3 daisy-chain CH6 OUT until CH1 IN
+- slot 3 CH1 OUT to slot 2 CH6 IN
+4. Run the pulsetest.py script for an amount of time of your liking, generating
+pulses out of CH1 and CH6. The frequency is at your leisure as well.
+5. Run this script (regupdate.py) for an amount of time. The script will dump
+out ERRORs and WARNINGs in case anything "funky" occurs
+
+Warnings & errors
+=================
+
+WARNING - this is not something major, it just indicates a long time between I2C
+        reads occurs
+ERROR   - this IS something major, indicating a synchronization error between
+        the loading of the registers and  a Wishbone cycle, which lead to an
+        error in the value read from the register
+
+Output format (WARNING as example, but ERROR is the same):
+
+WARNING ( <slot number> / <time at which occured>) <which reg. is concerned>:
+        (<old register value> / <new register value>)
+
+How it works
+============
+
+The script goes and reads the CHxPCR and CHxLTS*R regs and compares them to
+their values on the previous reads. As both the number of pulses received and
+_time_ are variables that increment, these registers should all increase from
+read to read (if a pulse signal is of course plugged in) and they shouldn't
+increment with more than a specific value, which is related to the pulse
+frequency and the amount of time between two I2C reads from the same register.
+
+Considering the above, this script checks that
+1. The reg values increase
+2. They don't increment with more than a predefined number of pulses, or
+seconds in the case of the TAI value registers
+
+Anything outside of that is considered a synchronization ERROR and is flagged
+accordingly, showing you also the previous and current reg value.
+
+WARNINGs are there just to signal reads take too long, probably due to the
+Ethernet frames taking too long to arrive to the crate. I have not seen up to
+now that two subsequent reads from the same register should be spaced more than
+3 secs apart, thus the selection in the TAI value. However, that's also the
+reason for printing both previous and current values, to actually determine if
+the ERROR is an ERROR or it is just another thing.
+
+Possible causes for ERRORs
+==========================
+
+1. Sync error, in which case the previous and new values should be WAY OFF 
+2. CHxPCR overflow, which I have not accounted for here. An overflow of the
+counter should take 11.94 days to occur (starting from 0 at a pulse
+repetition frequency of 4160 Hz)
+3. Something which is not actually an error (see the last paragraph in the
+previous section)
+
+Although I have considered a TAI low (first 32 bits) value overflow, it just
+dawned on me that would take ~136 years to complete. I don't think anyone will
+want to run the test that long. :)
+
+TAI high (40 bits) has not been considered to overflow. I'm pretty sure the
+board components will not last 35,000 years.
--- a/software/regupdate/regupdate.py
+++ b/software/regupdate/regupdate.py