mSGDMA stride reads/writes

Actually I mean overflows may result in data corruption. On-chip memory based FIFOs are dual port memory with head and tail addressing so if those two addresses cross, corruption will occur if the over/under flow detection is disabled in the FIFO instantiation.

For the FIFO sink (input) it drives ready high when the FIFO is not full. So when it drives ready high and your logic connected to it drive valid high the data is pushed into the FIFO.

For the FIFO source (output) it drives the valid signal high when there is data buffered in the FIFO (i.e. not empty). So when the FIFO drives valid high and your logic drives the ready signal high the data is popped from the FIFO and it's expected to be captured by your logic, if your logic isn't ready for the data then it should drive the ready signal low.

Data being valid is not determined by the ready signal, the valid signal represents when the data provided by the source port is valid. Ready is used as an indicator from the sink port to let the source port know when it's safe to move data. So you can have a source asserting valid and the sink deasserts ready and the data will remain presented until the sink is ready again. Likewise if the sink is ready but the source is not the sink will know this because the valid signal is driven low by the source port.

In your diagram you are not using the valid signal for the output FIFO. So there is no way for your custom logic to know which cycles contain valid data and which do not. That data is coming from memory so it takes a while to propogate to the source port of that FIFO so you will need to use that valid signal to know when the data is valid otherwise you'll be reading in old/garbage data sometimes.

Likewise in your diagram you show that your logic is not monitoring the ready signal of the input FIFO so in that case if the FIFO is full and data is written in anyway it will either be lost or cause corruption of the FIFO depending on whether that IP uses over/under flow protection. I don't know if the overflow protection is enabled in that IP but either way driving data into a sink port when ready is low is *not* allowed in the Avalon-ST spec and if you similated this design I suspect you'll run into an assertion due to not following the spec.