pkimelman-nxp
commented
5 years ago Sorry, my reply somehow got lost. Yes. You are correct. The issue is the timing and whether it is safe to try to control the store based on the combinatorial parity feed. An alternative would be to buffer (use 8 flops to hold the value pending the parity). The parity error is signaled, but I agree that it leaves your register with an incorrect value. I will look at making this an option to instantiate a buffer. This would add cost (extra flops and extra power in the double copy). I had figured parity errors are rare and should lead to the value being rewritten (GETSTATUS CCC will indicate an error occurred) but I can see the value of not risking your data. Further, if you had 4 values and the 1st two went in and then a parity error, you have a problem if the total 4 values have to be treated together. So, I use raw_fb_reg_err to recognize the update is unsafe.
In my configuration I have the register at address "0" configured to be a two byte register. I've set an I3C dynamic address. When writing the register address with bad parity all writes to the registers are ignored as expected. If I use good parity for the register address and bad parity for the first data byte (Least Sig Byte) the write to the first register is accepted (in spite of having bad parity) and the write to the second byte is ignored. If the address byte and first data byte have good parity and the last byte has bad parity then all register bytes are written. Another way to describe the effect is bad parity only has an effect on preceding bytes and not the current byte for writes.