handshacking between modules, best practices ?

Last weekend, I was continueing on my small project to use a FPGA as
DAC. I now use a hardware DAC (tlc5615).
So I have two modules, a top-level module for the DDS and an additional
module to drive the TLC. I have two signal for handshacking ("load" and
At a certain point, I had the problem that one of the signals wasn't
dropped fast enough, which resulted in a weird timing-issue.
In the end, I managed to fix my particular by adding a state with a
small delay in my FSM, but -looking back- it is probably also possible
to have done this with some additional checks in the state-machine.
Question: are there known "best practices" when designing a
handshacking-protocol between different modules in a FPGA design?
Is there documentation about this? Or text-books?
My question is not about this particular bug but a generic question on
"do-s" and "do not-s" in general.
Reply to
Loading thread data ...
I like the handhaking done in the various AXI like protocol's from ARM - basically "VALID", "READY" signals. The key to making things work is there's NO combinational paths between a VALID and a READY port i.e. the protocol is fully synchronous with all module I/O registered.
Asynch handshaking is another beast altogether. I'm assuming you're not talking about that.
Do a web search on the AXI protocols. ARM's specific document is titled "AMBA AXI and ACE Protocol Specification". The handshaking is described in section A3.2.1
Reply to
Mark Curry
Hi Mark,
Thanks for the link. Very interesting reading.
Yes, the handshaking protocol I used was syncronised, but I only used the positive edge of the clock.
The AXI protocol used the positive edge of the clock to set the control-signals and the negative edge of the clock to clear them.
That's indeed a good idea. I'll try to use this in my handshaking mechanism to try to make it more robust.
Reply to
I've not used handshakes very often. What would be going on that a handshake is required? Are you talking about clock domain crossing? Or are you talking about two FSMs talking to each other. In both cases I use a direct handshake where one signal does not change state until the other "sees" it and acknowledges the previous change.
0,0 -> 1,0 -> 1,1 -> 0,1 -> 0,0
This has no opportunity for a race or timing problem. Is there something I am missing?

Rick C
Reply to
Looking at section A3.2 I don't see any signals changing state on the falling edge of the clock. Where do you see this? It is *very* hard to design synchronous logic that operates on both edges of the clock. The two sides of an interface can operate on different clock edges, but this only gives half a clock cycle for timing.
Am I completely missing something?

Rick C
Reply to
The AXI handshake protocols DO NOT do that. They are, like all good synchronous logic should be, sensitive only to the rising edge of the clock.
What the AXI handshake protocol does is use the concept of "mutually agreed upon". If at the rising clock edge a) the master has already asserted VALID and b) the slave has already asserted READY, then the information present on all the rest of the wires is agreed to have been handed off from the master to the slave. Otherwise, that information (if available) is still the master's responsibility.
The point is that there's no need for a recovery cycle. The master can leave VALID asserted and change to new valid data. The slave can leave READY asserted if it doesn't need to wait while it processes the data that it just picked up, and the next information can be transferred on the very next rising edge. But this comes with the requirement that whether the master's data is valid is entirely uninformed by whether the slave is ready for it and vice versa.
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi
Hi Rob,
Hum. You are correct (as also noted by Rick). I misread the timing. My error. My appologies.
Well, what I had was a bit like that.
I have a signal "load" (equivalent to "valid" in the AXI handshake) and "done" (equivalent to "not ready" in AXI).
The master is the top-level module: the DDS module The slave is a a module that writes out a value to the SPI interface.
The problem I had (at least in the simulator), was a timing-issue:
- In the AXI process, when the slave has received its data, it drops the "ready" line, indicating that the slave is still working on the data it has justreceived (in my case, it is still sending it out the SPI interface).
In the simulation of my design, this "drop ready line" event took 1 clock-cyclus. (the slave need to detect this bit-change, clear the "ready" line and sends this signal back to the master)
- However, by the time that this signal did arrived at the master, the master module had gone to the next steps in its FSM: "wait for the slave to indicate it is ready to receive new data (i.e. ready is high), if ready: continue".
As the "not ready" signal of the slave had not yet arrived, the top-block happily said "ready line is high, so the slave is ready, so let's go on".
And, and additional issue, as the FSM of the master had just checked the "ready" signal, it simply went on to calculate the next DDS value and then the "trigger the slave to read the next value" stage, all this without without checking that signal again.
In short, the bug was the result of this assumption: "When the slave notifies that the master that is not-ready to receive any more data, this signal arrives in time for the state-machine of the master to process it correctly."
In my case, that assumpion turned out to be wrong.
In my case, I fixed this with a small delay in the FSM, but I guess it makes more sence to always do a "check if slave is ready" JUST BEFORE sending the data to it.
Therefor my question for "do's and dont's" when designing a protocol that controls dataflow between two modules.
I guess -especially if you are designing modules that get on github and will be used by others- it is logical to apply more "strict" rules to these parts of the code that interfaces with code written by other people.
Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.