Hi,
I was annoyed with the unclear specification of the NI 4-Wire handshaking protocol for usage inside single cycle timed loops.
Being used to the excellent AXI4-Stream protocol spec, I tried to provide a similar quality spec for the NI protocol:
In-official description of NI 4-Wire handshake protocol
For a connection from node A to a downstream node B:
- B.
ready for input : out std_logic
( meaning: B will be ready for handshake on next clock cycle )
B.ready for input is asserted if and only if the downstream node B can accept data on the next clock cycle.
The downstream node B must not wait for B.input valid to be asserted before asserting B.ready for input.
B.ready for input is usually a combinational output (inside SCTLs), often driven via combinatorial logic from B.input valid.
Whether the downstream node B may deassert B.ready for input without B.input valid being asserted is unspecified.
- A.
ready for output : in std_logic
( meaning: A is allowed to complete the handshake on the current clock cycle )
A.ready for output is asserted if and only if the downstream node B can accept data during the current clock cycle.
It is usually driven by the output of a feedback node with B.ready for input as source, i.e., it is a registered version of B.ready for input.
- A.
output valid : out std_logic
( meaning: handshake happened/completed within the current clock cycle )
A.output valid is asserted if and only if the upstream node A presents new valid data at its output AND if a handshake has been completed with the downstream node B via the assertion of A.ready for output during the current clock cycle.
A.output valid is usually a combinational output with a direct combinatorial path from A.ready for output.
While A.output valid usually reacts to A.ready for output, it is not clearly specified that it must only be asserted during/after the assertion of A.ready for output, although examples imply this behavior.
Asserting A.output valid without receiving A.ready for output and holding it asserted until A.ready for output is received may also be possible, but is not recommended.
- B.
input valid : in std_logic
(meaning: handshake happened during the current clock cycle)
B.input valid is asserted if and only if the upstream node A provides new valid data AND completes/accepts the handshake for the current clock cycle, offered by B.ready for input on the previous clock cycle.
B must accept the new and valid data at its input on the assertion of B.input valid during the current clock cycle if and only if B.ready for input was asserted on the previous clock cycle.
It is unspecified whether B may choose to accept data if B.input valid is asserted without having had B.ready for input asserted on the previous clock cycle. Thus, asserting B.input valid without an assertion of B.ready for input on the previous clock cycle may be considered a protocol error.
Common wiring for Node A -> Node B
A.output valid -> B.input valid
A.ready for output <- feedback-node <- B.ready for input
(A.data out -> B.data in)
Please feel free to provide improvements or list corner cases.
A gotcha I found myself is the Global initialize setting of Feedback Nodes, which often has to be changed to Initialize on Compile or Load if an initial value is wired to them and they are placed inside sub-VIs.
