SimuCam readout timing is not matching LESIA timing expectations nor theoretical timing

The HW timing generation was verified and errors were located with the source code. The configuration for the line delays was wrong and some of the adc delay states transition were badly executed. A correction for the timing generation was created and simulated, in 5f57da8dd362bd1ae544082bbc6479c19f7b35a0, and synthesized for tests in HW V20, in commit 4b551861dadf203ffcb4ed3c6f03ee44bc6efc3e.

Change Log:

The delay configurations for the line delays were corrected.
The states transition in the masking machine were corrected to aways configure and pass trough the appropriated delay sequence (line -> column -> adc) or (column -> adc).

Remaining:

@ericolucasm to test the HW V20 to check if the timing machine is now corrected and giving a transmission time closer to the theoretical time of 3.87 s.

Test Procedure:

[ ] Check if all the 638 read-out cycle packages are still being transmitted in a sync period [if not, a bug was introduced in the system];
Then, time all the 638 read-out cycle packages and check if it's being transmitted:
[ ] Too fast [the bug was not fully corrected];
[ ] Too slow [the bug changed but was not corrected];
[ ] With the correct timing [bug corrected. The issue can be closed in this case].

Hardware Programming File:

SimuCam_V20_20190223_HW.sof: https://github.com/NSEE/SimuCam_Development/blob/4b551861dadf203ffcb4ed3c6f03ee44bc6efc3e/G3U_HW_V02_2GB/Quartus_Project/output_files/SimuCam_V20_20190223_HW.sof

NSEE / SimuCam_Development_NFEE

SimuCam readout timing is not matching LESIA timing expectations nor theoretical timing #20