1
\$\begingroup\$

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?

\$\endgroup\$
  • 2
    \$\begingroup\$ Please can you put a lot more background and introduction into the line that's currently just, "I was reading a book that says...". It reads as if everyone knows the subject you're talking about. The clearer your question is, the better the quality of the answers you will attract. \$\endgroup\$ – TonyM Jan 30 '18 at 8:17
  • \$\begingroup\$ @TonyM My apologies, I edited the question to be specific. If you don't mind could you read my question once again? \$\endgroup\$ – JaeHyuk Lee Jan 30 '18 at 9:59
  • \$\begingroup\$ Much better :-) \$\endgroup\$ – TonyM Jan 30 '18 at 10:02
  • 1
    \$\begingroup\$ Thanks for the comment and sorry for my terrible mistakes. I think I was too desperate to organize the question. As a CS major student, this website really helps a lot to understand how hardware design works. I appreciate once again. \$\endgroup\$ – JaeHyuk Lee Jan 30 '18 at 10:23
4
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ So the point seems to be that CRC calculation/verification does not move/use the read pointer but happens before the packet becomes visible to the actual consumer. \$\endgroup\$ – JimmyB Jan 30 '18 at 11:12
  • \$\begingroup\$ It's difficult to tell from your question exactly what you don't understand. But there's certainly no need to Read the data to compute CRC because you already have the data - otherwise how could you write it into the FIFO? \$\endgroup\$ – Brian Drummond Jan 30 '18 at 11:16
  • \$\begingroup\$ I appreciate a nice answer @BrianDrummond. As mentioned by JimmyB, the point seems that when the data is received, another logic calculating the CRC runs in parallel with the logic writing the packet to the FIFO. Also, if my understanding is correct, by checking the read_ptr doesn't pass the rollback write pointer, we could detect if the consumer already took the packet from the FIFO that we tried to delete. Then what happens if the packet is already read from the FIFO when we try to rollback write pointer? Also, I am wondering why the rollback pointer for a read exists \$\endgroup\$ – JaeHyuk Lee Jan 30 '18 at 11:56
  • 1
    \$\begingroup\$ Minor edits to address these points. \$\endgroup\$ – Brian Drummond Jan 30 '18 at 11:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.