From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

[FPGA] Pipeline convention for 4-wire protocol?

Hi,

 

I'm looking to implement some VI's using the 4-wire handshaking protocol as part of a current project. These need to operate inside a 120MHz loop in line with a bunch of pre-existing 4-wire VIs, so I assume some pipelining will be required. I can imagine maybe placing flip-flops (feed-forwards) at both the input and output to my VI, so as not to 'steal' propagation delay from the surrounding VIs in the sequence, but if these also do the same it is a bit wasteful.

 

Is there any design convention, such as 'always place the flip flops at the input' I should be following, or better yet some templates? I have done some searching but can't find an example.

0 Kudos
Message 1 of 5
(3,419 Views)

The convention I generally use is to put flops at the end. Also, to help you out, if you're implementing 4-wire on your own, things can get a little bit hairy. I'd start from these templates (if you aren't already):

FPGA Design Patterns and Templates

 

 

Cheers!

TJ G
Message 2 of 5
(3,380 Views)

Thanks T-REX$.

 

I happened across that page but drew the conclusion it didn't really address the pipelining issue. Probably would have been wiser to actually download the templates and take a look! Believe me, as a beginner in high throughput FPGA, the term 'hairy' is one I've been using a lot recently. 🙂

 

Cheers!

0 Kudos
Message 3 of 5
(3,375 Views)

The document T-REX$ pointed out should be useful. It is common practice in hardare design to register outputs so users of your library know they don't need to register their inputs which can be really hard to deal with in some algorithms/implementations. 

 

With the 4-Wire protocol the tricky one is Ready for Input because it is an output but is a next-cycle value. In other words, the value for Ready for Input says the block will be ready for input on the next cycle. This design was intentional as the acyclic nature of LabVIEW dataflow requires the user to put a feedback node / shift register between the blocks (among other more subtle benefits). So, the rule still applies if you can register Ready for Input (predictive) but if you can't that is OK since a register will in most cases be required immediately outside the node.

 

Also, remember that in general all the general dataflow inputs and outputs to a node are controlled by the same 4-wire set of terminals. Any pipelining should be balanaced such that the data on the outputs is always valid on the same cycles and when Output Valid is true.

 

This can be pretty complicated, so please keep asking questions : )

Message 4 of 5
(3,358 Views)

Thanks Dragis.

 

"So, the rule still applies if you can register Ready for Input (predictive) but if you can't that is OK since a register will in most cases be required immediately outside the node.

 

First off, to clarify some nomenclature, I use 'feed forward', 'feed back' and 'flip flop' interchangeably. By register are we talking about the same thing? Also, what do we mean by 'node? Is that a single 4 wire VI or some part inside that VI?

 

So I understand that 'Ready for Input' applies to the succeeding cycle because it is always passed through a feedback outside the function. I don't get this bit "but if you can't that is OK since a register will in most cases be required immediately outside the node." If I don't predict the high, I lose a cycle, right? (which may be okay but limits input and potentailly throughput as a result).

 

 

0 Kudos
Message 5 of 5
(3,331 Views)