neil@formidableengineeringconsultants.com,
I'm not sure it would be possible to reset the DMA mid-transfer. The problem stems from the AXI spec itself. According to the AXI spec, every transaction *must* get a response. There's no way to drop a transaction currently in process if you want to reset things. As a result, if you have a misbehaving slave IP that drops requests--your design is likely to get stuck.
There are a couple solutions to this.
- First, there's a "AXI firewall" that you can look up. This core "Provides protection for the upstream network (SI connection) from failures of the downstream network (MI connection). When a failure is detected, the firewall becomes blocked, preventing further transfers from propagatin. When the firewall becomes blocked, the SI generates compliant responses for all outstanding and subsequent transactions. It also has separate blocks for read and write transactions.
- Alternatively, there's an open source AXI"bus fault isolator". Like the AXI firewall, it needs to be placed between the slave and the interconnect, and guarantees that a misbehaving slave still meets the rules for an AXI interface. It does this by 1) detecting a fault, and then 2) returning valid data following a fault but with the bus error flags set. That way an AXI master interacting with the core might not die, but rather detect and (recover) from an error. Also, like the AXI firewall, it will raise a flag that you can use with ILA or some other form of scope to see what caused the problem.
- Alternatively, if you set the OPT_SELF_RESET flag within the core, then the bus fault isolator will automatically issue a reset to your core to give it a chance to recover. Either way, requests will always be returned within a user-selectable timeout -- either from the original core or from the bus fault isolator.
While it's not quite what you are asking for, you may find these cores meet your needs.
Dan
