SURF/LAB4D readout weirdness, hopefully fixed

I think I’ve figured out the SURF/LAB4D weirdness.

It’s basically related to stopping SRCLK every time. The ‘load’ signal (/S) is derived from a falling edge detector on SS_INCR on the negative edge of SRCLK. On the last clock of each sample, we lower SS_INCR, which puts ‘load’ (/S) high on the first clock of the new sample, so we can just seamlessly stream out the data.

However, on the very last sample, SS_INCR still went low, because, well, it was just like any other sample. Then SS_INCR stopped. So ‘/S’ was left high that entire time, and the first new clock of SRCLK, in the next readout, caught ‘/S’ right away. Since ‘/S’ is derived from a falling edge detector, the extra clock with ‘S’ low didn’t do anything – the data just kept shifting out, and from the readout side, it just looked like everything happened a sample earlier than it really should’ve.

REGCLR wasn’t actually screwing anything up here – at reset, the SS_INCR edge-detection registers are both 0, but they take !SS_INCR as inputs. So the first falling edge SRCLK with SS_INCR low sets the first register to 1. The second register is still 0, so its Qb output is 1, giving a ’11’ input into the AND get, setting S low and /S high.

So the solution is just to not have SS_INCR go low in that last readout, and make sure that when starting a readout, the first SRCLK doesn’t actually do anything, because it takes 1 clock to actually load the shift register, like we expected. We do that by not incrementing the bit counter for the very first clock of a readout. So it looks like this.

lab4d_readout_with_srclk_stopping

Leave a Reply

Your email address will not be published. Required fields are marked *