Regarding the latency estiamtion in the VHDL code

[Maitry07]

Hello support team,

I am using some of the xilinx ready available cores like divider generator, CORDIC etc, in which during implementation, the latency information is written inside the core. for example, divider core is having latency of 4 clock cycles. My divider core is working with a clock of 61.44 MHz.
So, latency for the core : 1/4*61.44 MHz = 4.06 nsec

But , how to estimate the latency for the own generated VHDL module. let's say I have written one vhdl code for averging.
so this code will take how much delay between its input and output? how can I estimate that in vivado? can anyone please let me know.

 

[FvM]

In my math 61.44 MHz 4 clock cycles are 65 ns.

In case of doubt, each register stage in the data path causes a latency of 1 clock cycle.

 

[barry]

I have checked FvM's math, and it is correct.

There is no absolutely no way to "estimate" the latency of your code. Run a simulation and count clock cycles.

 

[Maitry07]

Ok , so, latency formulla = (No of clock cycles)/clock

4/61.44 *10^6 = 65 nsec

--- Updated Feb 24, 2023 ---

I have one doubt then,

If my input sample rate to any IP core is let's say 20 MSPS and If I use the IP core clock to higher let's say at 122.88 MHz. then it will possible to reduce the latency, right?

 

[KlausST]

Hi,

As already mentioned there are different "latencies". The one is caused by the code and processing time, the other is caused by the filter function.
If you are interested in total signal latency - which combines both - but is dominated by filter itself.

On "symmetric" digital filters, like the averaging filter, you get a constant group delay over frequency, but unsymmetric filters will have different delay vs frequency.

You should clearly communicate which latency you are after ... and why.

Klaus

 

[Maitry07]

I am looking for the total latency of the averaging algorithm because within 2 usec , my amplitude should measured. and I have calculated used IP cores latency which are 1.4 usec. so i need to figure out the moving averaging total latency(filter delay+ processing time/code)
for the filter delay, delay is (N-1)/2 . I am using moving averaging on every 8 samples.

 

[KlausST]

Hi,

from your post#4:

4/61.44 *10^6 = 65 nsec

should be modified to:
4/(61.44 *10^6) = 65 nsec
to make it correct.

***

61.44 MHz is the sampling rate, or the core clock frequency?

For the core latency you need to use the core clock frequency,
for the filter latency (group delay) you need to use the input sampling frequency.

Klaus

 

[Maitry07]

My input sampling rate to divider core is 61.44 MSPS and I am using Divider core with the same clock freq. of 61.44 MHz . that's why I am getting one output divided sample per clock cycle.

In a similar way, my moving average filter input sample rate is 20.48 MSPS and moving average core clock = 20.48 MHz.

 

[KlausST]

Hi,

so the (logic, math) core runs with 61.44 MHz
and the average filter with 20.48 MSPS input sampling rate.
correct me if I´m wrong.

***

I just don´t understand (maybe I even don´t need to understand) why you both name "sampling rate" but one additionally as "to divider".

Klaus

 

[Maitry07]

Hello,
sorry for the confusion.

My moving averaging algorithm input sample rate = 20.48 MSPS
Core clock for the algorithm = 20.48 MHz

 

[FvM]

Latency is a necessary side effect of pipelined logic designs. Unless you are e.g. designing a controller for hardware in the loop, there's no problem with latency.

Running parts of a design at higher clock rate, preferably an integer multiple, can be useful in some cases, but requires additional means to synchronize the data path over clock domains, so it's not necessarily reducing logic utilization.

My impression is that you are still on the way to manage basic FPGA designs, no good idea to make it more complex than necessary.

 

[barry]

Theres no need to get your bloomers in a bunch over all the minutia of the design. If you want to know the latency of your design just run a simulation and measure the time between your first input sample and your first output sample. If youre a masochist, you can trace your signal path by hand, (and probably make mistakes along the way.)