How does the rollback work in a FIFO?

Question

From reading the book titled "Advanced Chip Design practical examples by verilog", I faced some questions about when the Ethernet packet is read from the FIFO and how the rollback works for the Ethernet packet FIFO.

The chaper 8.3.4 of the book explains the reason why rollback is necessary in the FIFO in the aspects of reading a packet and processing its CRC; when the CRC calculated from the receiver doesn't match with the pre-calculated CRC attached together with the packet, it needs to rollback the current FIFO write pointer to the rollback write pointer (rollback_wrptr). Here, rollback_wrptr is the write pointer of the FIFO saved right before it starts to receive the packet.

And the book says...

At the end of the packet, when we find CRC does not match, we assert one-clock wide signal, rollback_wrptr that reloads the snapshot value to the main wrptr of the FIFO.

I am wondering why the book only mentioned about the write_ptr but read_ptr and read_ptr_rollback. To calculate the CRC, it seems that the packets should be read from the queue; it will consume some elements from the FIFO, which moves the read_ptr of the FIFO. Does the hardware logic prevent the receiver from fetching the data from the FIFO until the CRC calculation done in usual?

It seems that it should rewind the not only the write_ptr but also the read_ptr. If available, could I get some code implementing the FIFO with the rollback in verilog or VHDL?

Answer 1

I don't have the book, but it sounds as if this happens when an incoming packet is being stored in the FIFO, and the design spec calls for packets with an incorrect CRC to be discarded, so that only correct data enters the FIFO.

(Some other part of the protocol will then note the packet has disappeared, and ask for re-transmission)

So data is written to the FIFO as it comes in, in parallel with CRC computation (on the incoming stream, by dedicated hardware, no Reads involved) but you don't know it's correct until the CRC. At which point, rolling back the Write pointer is equivalent to deleting the packet by pretending it didn't exist. And future incoming data will overwrite the discarded values.

The Read process in a FIFO is entirely separate, and rolling back a Write should have no effect on it - provided the Read pointer doesn't pass the rollback write pointer. Presumably some mechanism exists to prevent that. Look at the Empty signalling mechanism : I would expect it to compare the Read pointer with the rollback Write, not the leading edge Write, to guarantee this.

(And presumably the rollback Write pointer is updated to the leading edge Write if CRC is OK).

So what would rolling back a Read be for? In this design, as long as you prevent Reading past the rollback Write, perhaps there isn't any purpose for it.

But you could imagine use cases for rolling back a Read - where, for example, one CPU core grabbed a packet then aborted processing it (signalling Rollback somehow), so you can release it to another CPU.