Aha -- many thanks. I think what tripped up my test logic is that the "done" state in drs4_eval5_app.vhd that executes post-readout sets DWRITE back to 1 (drs_write_set). If one then writes to FPGA register 5 while the FSM is in the "idle" state, the conf_strobe and wsr_strobe states occur with DWRITE and DENABLE both asserted. This is if one sets the "dactive" bit in the FPGA app code, which is probably not the usual use case. Maybe using the real DRS.cpp avoids this situation. (I was simulating your FPGA code to test my understanding of what our FPGA code should do.)
Anyway, our own use case is fine: as you suggest, we leave DENABLE asserted, but we deassert DWRITE while reading out or while changing DRS4 register values.
you keep DENABLE active all the time to keep the Domino Wave running, but you deassert DWRITE if you change any register via SRCLK. There is no shadow register, just a simple shift register, but with DWRITE being low, the domino circuitry does not touch it.
We have for some time now been using custom firmware on a custom board to read waveforms out of DRS4 chips. Now we are working on cascaded readout mode, 4 channels @ 2048 samples, WSREG=0x55, in order to allow for longer trigger latency.
Doing a testbench simulation of the FPGA code raised a question for me: Do I need to deassert DENABLE while I shift a new 8-bit value into the write-shift register? What happens if, during the few-hundred nanoseconds it takes to shift 8 bits into the register, the domino wave crosses cell 768, thereby shifting the write-shift register left by one bit? Is this shifting suppressed when A=0b1101? Or does the update of the actual write-shift register occur only once, after the 8th SRCLK cycle? (Maybe one is really shifting bits into a shadow register that is copied all at once into the actual register?)
I notice in simulating your drs4_eval5_app.vhd that if one sets bit 27 ("drs_ctl_dactive") of register 0 (do not deassert DENABLE on trigger), then starts the domino wave (set bit 0 of register 0), then issues a software trigger, then later writes to register 5 (config register, wsreg, etc.), DENABLE is not in fact deasserted during the time when A=0b1100 (conf_setup, conf_strobe) or when A=0b1101 (wsr_setup, wsr_strobe).
But my simulation testbench includes a simplified Verilog model of my interpretation of the DRS4 data sheet, and my simulated DRS4 happened to cause the write-shift register to shift (256 samples before DTAP toggled) during your "wsr_strobe" FSM state, thus corrupting the value that was being shifted into the WSREG via SRIN and SRCLK.
So I'm curious: to be safe, should one deassert DENABLE before updating the write-shift register, or is it safe to update it even while the domino wave is active and looping? It seems easy enough to be safe, since we should only need to write to the WSREG once during the setup phase and then let it loop forever.