This script connects to a crate 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.
