open-source-silicon.dev

here is a trick I tried, used that unknown address in slave 30000220. I can read from the address but firmware cannot write. at this point its a guess work

<@U053UFMPKDW> Line 107 of your C firmware (in your screenshot) is probably what you are seeing happening in your VCD trace. `0x88` is being shifted left twice by that function, to become `0x220`, which that function adds to `0x30000000` -- I would expect that it works in the screenshot above (see how it is writing data `0x7`) because you modified your code to successfully ACK a write to that address 0x30000220 *in this case* but: (a) until you made that modification in your Verilog, line 107 was instead timing out due to line 205 of your Verilog (i.e. no ACK); and (b) after you made the change, C line 113 would instead be the one timing out for the same reason (i.e. it's writing to an address that your Verilog doesn't handle, so again no ACK).

I think it would be a good idea to consider deleting line 205 (so line 193 can always ACK a valid WB transaction), and for the sake of your testing maybe replace line 205 with something that allows you to sense that this condition has occurred, e.g. you could do something like:
```rdata &lt;= 32'hDEADC0DE;
some_reg_linked_to_an_LA_pin_used_for_flagging_a_bad_address &lt;= 1'b1;```

The timeout doesn't happen when we follow the instructions provided above. Now we will investigate why our IP is not providing the ack signal at the correct address, or at least implement some kind of error handling like the 0xDEADC0DE thingy. Thanks!