[Question] Regarding FcAxiFilterDaiAccessError_A assertion

[pchunghoon]

Hello calipra team,

I have found FcAxiFilterDaiAccessError_A assertion error during caliptra_ss_fuse_ctrl_axi_id test when a valid write follows a discard write.

caliptra-ss/src/integration/asserts/caliptra_ss_top_sva.sv

Lines 75 to 78 in 28ef1ce

	`CALIPTRA_ASSERT(FcAxiFilterDaiAccessError_A,
	`FC_PATH.discard_fuse_write ##1
	`FC_PATH.otp_operation_done[->1] |=>
	`FC_PATH.u_otp_ctrl_dai.error_o == {AccessError})

I think that discard_fuse_write signal remains asserted for two more cycles after otp_operation_done toggles, so the assertion impacts on the next valid write as well.
Therefore, I’ve just tried it as below.
I’d appreciate your feedback on these changes.

`CALIPTRA_ASSERT(FcAxiFilterDaiAccessError_A,
               dai_write_req ##1       // <=== add
               `FC_PATH.discard_fuse_write ##1
               `FC_PATH.otp_operation_done[->1] |=>
               `FC_PATH.u_otp_ctrl_dai.error_o == {AccessError})

Regards,

[rswarbrick]

My intention with this assertion was something like: "If discard_fuse_write is true, then wait for the next cycle where otp_operation_done is true. On the cycle after that, we expect the DAI module to assert an AccessError in its error_o port".

If I've understood correctly, your proposed change is essentially conditioning the thing above with "And dai_write_req was true on the previous cycle". Obviously, that's only going to have an effect if there's a situation where discard_fuse_write is true when dai_write_req wasn't true on the previous cycle.

That signal depends on the cycle before that(!), and comes from the discard_fuse_write signal (which I think means that there was a read or write request that shouldn't be allowed).

Eugh: this is rather fiddly to debug (or indeed to guess a spec for). Could you give a screenshot of the waves that show the problem? There's a good chance my guessed assertion was wrong, but I'm not convinced another guess will be right without some help :-D

[pchunghoon]

Thank you so much for always getting back to me so quickly.
I think the issue seems to occur when a normal write happens immediately after a discard_fuse_write condition.

                       clk   |   |T0 |   |   ......   |   |   |   |*T1|*T2|   |   |   |   | ......|   |*T3|   |   | ......|   |   |   |*T4|   |

                                      ____________________________________
         discard_fuse_write _________|                                    |________________ ......__________________......_____________________
         
                                                              ___                                                                  ___
         otp_operation_done _________________________________|   |_________________________ ......__________________......________|   |________

                            _______________________________________________________________ ......__________________......______________________
      u_otp_ctrl_dai.error_o               NoError               | AccessError                             AccessError                | NoError
                            --------------------------------------------------------------- ......------------------......----------------------
                                 ___                                                                   ___ 
              dai_write_req ____|   |______________________________________________________ ...... ___|   |________ ......______________________


                                                                      ^                                                                   |
FcAxiFilterDaiAccessError_A                                           |                                                                   V

When the write that occurs at T0 is a discard_fuse_write, the assertion passes normally at T1.
However, as mentioned earlier, discard_fuse_write remains asserted even after otp_operation_done(T1&T2), causing it to fire again. As a result, when a valid write occurs afterward at T3, the assertion fails at T4.
Therefore, I think it would make sense to include a signal like dai_write_req(or `FC_PATH.dai_req) in the assertion’s trigger condition.
Regards,

[rswarbrick]

Ah, now I understand. Thank you so much for the careful description and picture: that would definitely have been difficult to follow without the ASCII art :-)

I've just filed something that I think should fix things properly.