Easy way to see number of registers along datapath in Vivado? - Page 1
Forum section: electronics / general

author: SMB784
author_rank: Frequent Contributor
timestamp: June 17, 2021, 02:36:43 pm
content: My computation pipeline has two input branches that feed into a multiplier, and currently the branches don't have the same number of registers in them. To make a well-formed pipeline, I would like the two input branches to have the same number of registers. However, counting these registers is tedious because the input branches are long. Can I have vivado show me how many registers are in each branch and preferably what those registers are?

author: dmendesf
author_rank: Frequent Contributor
timestamp: June 17, 2021, 10:06:31 pm
content: Can you feed 1,2,3,4 sincronized in both inputs and look if 1 arrives with 8 at the multiplier, for example?

author: SMB784
author_rank: Frequent Contributor
timestamp: June 19, 2021, 02:25:53 am
content: Quote from: dmendesf on June 17, 2021, 10:06:31 pmI suppose I could try stimulating it as you suggest, however that sounds like it might be prone to errors.Perhaps there is a way to get the timing analysis to tell me this?

author: hamster_nz
author_rank: Super Contributor
timestamp: June 19, 2021, 05:28:27 am
content: Quote from: SMB784 on June 19, 2021, 02:25:53 amNo, not really. Timing analysis is focused on the clock cycle, not over a number of clock cycles.IMO you should structure your code so you can't end up with mismatched latency in your pipelines. It is quite easy to do if you can get away from "I must do this in what feels like the most 'source code' efficient way" rather than a "I must do this in a way that minimises errors and adds flexibility even if it does make the code look verbose".A bit of 'scaffolding' will make this much easier. Don't plug the output of one computation onto the inputs of the next, but set up a framework and plug the calculation components onto that, then let the tools prune away unused resources. The end result will be equally efficient, or maybe even better as the optimiser may more freedom to shuffle registers around.In both cases debugging involves simulating and sending a impulse down the pipeline, and checking the results come out in the correct alignment...

author: rstofer
author_rank: Super Contributor
timestamp: June 23, 2021, 04:01:45 pm
content: Quote from: SMB784 on June 17, 2021, 02:36:43 pmYou can always look at the RTL schematic but it might not be easy to spot the pipeline.I would lay out the pipeline registers first such that all of them are clocked simultaneously. The output of one stage would then go through some logic (combinatorial) and serve as the input to the next stage. I would be very deliberate about the pipeline registers. I might even create a component composed of some variable number of flops where a generic variable specified the width. I would probably instantiate these registers with names such as 'Stage_1_FirstPath', 'Stage_1_SecondPath'...,'Stage_n_FirstPath','Stage_n_SecondPath' and so on. Hopefully, I could come up with something better than these...I would be very pedantic about the stage registers and not leave anything up to the synthesizer.It would be quite easy to spot the critical path logic between stages. Depending on the required speed, there may be a need for more stages and smaller logic steps.

author: SMB784
author_rank: Frequent Contributor
timestamp: June 25, 2021, 02:02:13 pm
content: Thanks for the suggestions guys.I ended up addressing the need to match pipeline depth for making a well-formed pipeline by starting with the lowest hierarchy modules and adding enough registers to each data path so that they would have the same length (as in the same number of registers on each path). I created a design structure according to a rule that each pipeline stage in the data paths would have its own always_ff block, in order to make sure that I matched the number of pipeline stages on all data paths.This will be what I do going forward. Thanks again!