How are these feedback nodes helping synchronization? - FPGA

[Shiv0921]

Context, I've inherited this code and I'm new to FPGA. I'm adding to this loop and I want to get rid of some of this pipelining because it feels like it's unnecessary. Surely building an array just to pipeline it, to then index it again doesn't make sense. And with what I need to add I really don't want to play shift register spaghetti if I don't have to. 

However before i start changing old code, I don't really know what these feedback nodes are doing and I don't want to lose any synchronisation. The comment says 'keep time synced with analogue input above'. Can someone explain how a feedback node would be used to keep synchronisation?
Is it because the data is being passed around 3 times but the timestamp only twice so it's keeping it back for a single iteration?

If I'm going to cut some of the pipelining I want to still keep these aligned, so if that is the case then I think I'll need to remove one.

For info, the loop is trying to run at 750khz. it reads analog data, filters it and passes it out. it uses the loop timer for the timestamp. I'm about to add it bringing in another dataset and filtering that too.

I've attached the current loop and an image of broadly how i want to change it. Basically I want to remove the pipeline between read and filter, so that i read the channels and then filter them,  then pipeline that round for sending.

Apologies in advance for not attaching the vi, but the whole project is a monolith which makes it hard to attach. Hopefully the screenshot will hold enough info for my question.

[raphschru]

Hi Shiv0921,

In my opinion, most of your feedback nodes / shift registers (I would even say ALL) could be removed without any functional difference.

As already explained here, these are useful for pipelining when you have a tight loop that does not meet timing conditions (either at compilation for a Single-Cycle Timed Loop or at execution for a standard While Loop), but I doubt it is your case.

Maybe you should try to answer these questions:

 - Is there a specification for the loop period / acquisition rate? What is the value of the parameter "Sample period (Ticks)"?

 - For the current code (of course with the actual hardware running, not simulated): does the measured period match the expected period?

 - After doing your simplification: does the measured period still match the expected period? If no, you may keep some pipelining to break down the processing in several steps.

Regards,

Raphaël.

[Shiv0921]

Hi Raphael, thanks yes following your advice from before i feel fairly confident that I can remove at least most of the pipelining.

My concern was just that while I can easily check whether the modified code still meets the timing expectations, I wasn't sure I'd have kept things synchronized because I'm not clear on the role of the feedback nodes. 

I feel the feedback nodes are there because the two datasets are being passed a different number of times around the loop, so the feedback node is to keep the timestamp back by one so that it stays aligned with the analog(?).

In this case I see that if i take out all of the pipelining I can remove all the feedback nodes, but I also didn't want to immediately pull out all of the pipelining because I've been told it also helps the code take up less FPGA resource(?) which we are tight on. 

So in this case if I leave a bit of the pipelining in I just wanted to be sure I've left the right number of feedback nodes in.

However following your questions (to which the answers are 1) 750khz/53 ticks, 2) yes it does 3) I'll check), I see the wisdom is probably to pull out the pipelining and the feedback nodes and see whether the code still is fast enough in which case my problem is solved. Assuming the code doesn't take up more resource because of it

[raphschru]

---

@Shiv0921  a écrit :

[...] so the feedback node is to keep the timestamp back by one so that it stays aligned with the analog(?).

---

Yes, if the data is delayed by one or several loop iterations, it seems reasonable to delay the timestamp by the same amount so that is corresponds to the moment the values were read from your IO node.

---

@Shiv0921  a écrit :

I've been told it also helps the code take up less FPGA resource(?)

---

To me, using feedback nodes / shift registers uses MORE resources because it has to store the values during one iteration. A simple wire is always more resource efficient. I'm not 100% sure, so maybe someone who has more insight could confirm this...

You could try by removing all the shift registers/feedback nodes and see if the timing is met. If not, keep one delay. If still not, keep 2 delays, etc...

Regards,

Raphaël.

[Shiv0921]

Thanks I appreciate the the clarification re the feedback nodes.

I've now removed all of the pipelining and feedback nodes and you're correct the resource utilisation has gone down. Which makes sense! This is contrary to what I'd been told repeatedly before so I'm glad to have a definitive answer on this. Comparison attached.

The previous code took 55 ticks per loop regardless of filtering being on. Without the pipelining it takes 58 without filtering on or 67 with filtering on. So I'll pipeline the filtering again and see where things are at. Thanks for guiding the thought process I need to go through on this.