Feature: Backpressure on ready

[davekeeshan]

Hi there

This is a feature request, not a bug.

When testing I like to stress the legality of my interfaces up to their limit.

On this interface having a random backpressure feature to enable, so that the ready whould drop out from time to time. This is legal in the protocol and I find that testing in this area is usually where some bugs appear.

[aignacio]

Hey @davekeeshan,

are you looking for backpressure as a slave pulling hreadyout == 1'b0? if that is the case, check here how random bp is applied by an emulated SRAM.

[davekeeshan]

@aignacio No i was thinking more on the master side. The hready_in goes and stays low just as the transaction starts, it is a rare event, but I believe it is legal. It is usually in this area (more in AXI land) that I have seen interfaces I want to test fail.

This is the type of code I was thinking about, as a proof of concept, but I am not 100% happy with it:

[aignacio]

@davekeeshan

Unfortunately, this is a bit tricky behavior to emulate, let me explain why.

1. The hready_in is an input that only exists in a DECODER -> to -> SLAVE AHB, i.e the master does not drive hready_in as such. It exists in the VIP because a lot of AHB slaves are typically designed to be connected to an AHB Decoder / Bus Matrix. Thus optional.
2. When hready_in == 0, this means that the previous txn has not yet completed and the AHB Slave needs to wait (even if it's selected through HSEL) before sampling the address phase signals (addr, trans, mode...).
3. Once the Slave is selected through HSEL, the hready_in should mirror the hreadyout as displayed in the diagram below. Currently, this VIP does not mirror the hready_in == hreadyout due to some limitations.

Overall, the only time I see you could put bp from a master side (decoder in this case) is when the master is trying to indicate that the previous transaction hasn't been completed yet i.e in the first address phase of the selected slave. Because in the data phase it needs to follow hready_in == hreadyout.

Considering that a bad slave would only sample address phase signals when hready_in == 0, and this might only happen in the transition from it being selected, a simple test could easily force the hready_in == 0 and check whether the AHB slave is decoding the request. Thus modeling this on the VIP side seems tricky while compared with a simple dedicated test.

[davekeeshan]

@aignacio I think I understand what you are saying, but I don't know if I have conveyed what I want to achieve, for context I have 25+ years of ASIC verification experience and this comes from things I have seen (and bugs that got as far as silicon, ugh).

Maybe using the word master is confusing, usually what happens is that a master talks to a slave, then the operation is obvious and clear. In the example you describe I don't want to emulate the master I want to be emulating the thing talking to the slave, so in the diagram one port out of the multiplexor, because I am testing the slave. If there is a legal condition when the ready can be gone, and the ready is an input to the slave, then that is what I want to test. Typically I will have mainly normal transactions and every so often pepper in the unusual ones. Having them randomized (constrained random etc etc) and running in the background of every test gives fantastic coverage over time.

I respect that it is a tricky case, and that is usually where bugs hide, because they are tricky, hence my desire to hit this.

If you feel it is not of interest to implement that's OK, I just felt it was good practice to suggest potential improvements, I got stung around and AXI version of this problem a while back. I have a semi working case, which isn't the way I like it, I will probably proceed with that, I will make it available should you find it of benefit.