How the AXI-style ready/valid handshake works

The ready/valid hardware data transfer protocol is simple and ingenious, providing flow control with only two control signals.
The rules are very simple: data transfer only happens on the bus when both "ready" and "valid" are '1' during the same clock cycle. However, it may be tricky to implement this mechanism in VHDL.
Read the full article about the ready/valid handshake on VHDLwhiz:
vhdlwhiz.com/h...
09:17 ** Challenge: Pipelining with AXI-style ready/valid flow control
To make learning VHDL fun, I've created a coding challenge where you can practice getting the ready/valid handshake right.
In the competition, I provide a module with a self-checking testbench. The module works fine and runs through all the test cases. But the module's operation is complex and should be split over multiple clock cycles to ease timing.
Your task is to convert the example module to a pipelined design that uses three clock cycles instead of one without limiting the throughput. It should still run through the same self-checking testbench.
After one week, I will post a video explaining half of my proposed solution, which should make it easier. Finally, I will reveal my complete solution after two weeks and explain how it works.
If you are viewing this video sometime in the future, the hint and solution videoes will already be waiting for you on the challenge page. You can still join the membership and take the challenge.
Click here to read more about the VHDLwhiz Membership and join:
academy.vhdlwh...
Here's a direct link to the challenge page in the Membership portal (only accessible for members):
academy.vhdlwh...

[@user-uq6po8dv6i]

This is a great video. The AXI protocol, in general, is used ubiquitously, but no one ever bothers to dive into it and explain it. They just say, "It works, leave it at that.". But we're engineers, we can never leave it at that.

[@VHDLwhiz]

Thank! I'm glad you liked it.

[@mrsmelaniecook]

Thank you so much for this clear explanation.

[@VHDLwhiz]

You're welcome! 😊

[@diegogarridomendoza2828]

You are the man!

[@VHDLwhiz]

Thanks, Diego. 🙂

[@etherbladenet8123]

Hi Jonas, once "valid" is asserted it must remain asserted until the handshake occurs.

[@VHDLwhiz]

Yes, you are right. To follow the AXI specification 'valid' must remain high until 'ready' becomes high during the same clock cycle.

[@stevenaumov2731]

Not just the same cycle...any cycle thereafter. Once asserted,, valid must not de-assert once until a handshake occurs, no matter how many cycles it takes to occur. If this rule is violated, then you can potentially get into a situation where no transfer ever takes place because the sender and receiver can enter the "no transfer" situation you describe in your video.

[@khaaaled2007]

Thanks for the video and article, very well put, in an attempt to better understand these things I created a little project with something similar to what you have here, three modules, one reads data from a file and generates a stream, one receives the data calculates the square then streams it to the third which receives it and writes it into a file, my issue is that I don't know if what I have works as an AXI protocol or not, I have a testbench, I can see that the received data is the square of the generated data but everything is delayed by one clock cycle, does that mean I have made a mistake in implementing the AXI protocole? I guess a more speceific question would be this, does the first module (AXI Stream Source) only send data when the final module (sink) is ready, and the in between module (Multiplier) is just a mediator

[@VHDLwhiz]

First, I should mention that the AXI interface has more rules than described in this video. That's why I wrote "AXI-style" in the video. It's not the complete story. But the ready/valid handshake is useful with or without AXI.
The output data will usually be delayed by one or more clock cycles when it passes through a module that does some transformation to it. That's any process that takes the clock as an input. It adds registers (flip-flops) to the data path, thereby delaying the output.
If your multiplier module uses a clock cycle, you must ensure that the ready and valid signals on that module's input and output sides still work. All modules must conform to the flow control rules (send/accept data when ready and valid are '1').
However, if the multiplier module is combinational (doesn't use the clock), you can simply pass the ready/valid signals through this module. That's because it doesn't consume simulation time, and in the FPGA, it will just add to the combinational path between your source and sink modules.

[@khaaaled2007]

@@VHDLwhiz Thank you very much for the response, very insightful and instructive, I didn't consider the possibility of having the module be fully combinational, I'm guessing the trade off there is that the acheivable maximum frequency would be lowered but the design would require less clock cycles to run(?). The design I have is clocked so I will try to modify it to be combinational and maybe learn a thing or two by observing the frequency.

[@VHDLwhiz]

@@khaaaled2007 Yes, that is correct. But if everything were combinational, we wouldn't need flow control. Typically, we want to create data processing pipelines that split the operations over multiple clock cycles. Then we need ways to ensure that data only transfers when modules are ready to accept it. One way to fix that is to add flow control signals. For example, by using the ready/valid handshake. The number of clock cycles usually doesn't matter. It's the throughput that counts, and this will be the same, even if you add pipeline stages.

[@yuwuxiong1165]

When exactly the sending data (in green boxes) are sampled by the receiver (suppose both valid and ready are asserted)? If the receiver uses DFF to register the incoming data, I guess the sampling time is at the raising edge of the clock, which is located at the "tail" of the green boxes. In this case, the setup time (for the receiver) is long enough, while the hold time might be a concern. The wavedrom diagram always draws the green boxes a bit offset (to the right direction) of the corresponding clock cycle, probably considering the Tcd and Tpd of the sender. This offset gives a bit room for hold time for the receiver, I guess.

[@VHDLwhiz]

My intention was to show a diagram of a perfect world with regards to timing; like the waveform in a VHDL simulator. I can see the transition of the data boxes appear a little offset to the right. But for the sake of this example you can assume that any changes happen exactly on the rising clock edge and that the receiving FFs have no problem sampling the value that the data signal had just before the rising edge.
Of course, in reality, there are setup and hold time requirements that must be respected. The good thing is that in FPGA design the synthesis and PAR tools will take care of that for us if we use the same clock, or clocks with a known phase relationship, on the sender and receiver sides.
But, yes, timing is something you need to think about if that's not the case. Then I would consider a different interface like a 4-way handshake.
By the way, we created such a 4-way clock domain crossing handshake in the VHDLwhiz Membership previous month. We created clock domain crossing modules to convert between this synchronous ready/valid handshake and the asynchronous req/ack handshake.
academy.vhdlwhiz.com/membership
Click here to get to the video and downloadable if you are a member:
academy.vhdlwhiz.com/products/vhdlwhiz-membership/categories/3260833/posts/2169140370

[@joshuanuka1180]

Is it possible for D1 to be sent before D0?

[@ranjeetkumar2709]

Hellow sir, I am from india and I really enjoy the ready valid handshake data transfer scheme for AXI/AMBA Protocol .but will u please explain this in using verikog and system verikohl please

[@VHDLwhiz]

Hello, Ranjeet. The VHDLwhiz website and TH-cam channel focus on VHDL. Verilog and SV are good too, but I don't want to divert too much from the original concept.

[@brianwang5660]

You look 23 years old in this video, congratulations. 😄

[@VHDLwhiz]

Haha, thanks 😄