Floating point IP cores Latency problem

[Soh_bhat]

I have a pretty much complex project. I have used floating point IP cores for that. But the problem is when generating the result, it is not showing the exact answer. I was wondering about the latency. When I take the latency of 0, it is giving the exact answer. But when I am using latency of 3-4 or more, it is showing some garbage answers. My point is that, what is this latency in IP cores? Is it worth it to take those values to 0? I have floating point operations like add, sub, mul, fused -add. My answer is coming with latency 0, that's why thinking if it is true logically in terms of the vivado vhdl floating point operations.
Please reply. It's urgent.

 

[kaz1]

I have a pretty much complex project. I have used floating point IP cores for that. But the problem is when generating the result, it is not showing the exact answer. I was wondering about the latency. When I take the latency of 0, it is giving the exact answer. But when I am using latency of 3-4 or more, it is showing some garbage answers. My point is that, what is this latency in IP cores? Is it worth it to take those values to 0? I have floating point operations like add, sub, mul, fused -add. My answer is coming with latency 0, that's why thinking if it is true logically in terms of the vivado vhdl floating point operations.
Please reply. It's urgent.

Latency is telling you when result is ready(after how many clocks).
it could be that zero latency worked for you if you are cascading many functions. but people prefer nonzero latency for fmax. In that case you take control of how to cascade modules and when to expect results.

 

[FvM]

Sounds like your code is designed to work with zero latency IP functions. Most basic arithmetic IP functions can be implemented with zero latency, but as kaz1 told, only with reduced fmax. You should know if it's an issue for your design.

The usual procedure goes the other way. Know the target fmax of your design, choose IP latency necessary to achieve it, construct respective pipelining for the datapath.

 

[Soh_bhat]

Latency is telling you when result is ready(after how many clocks).
it could be that zero latency worked for you if you are cascading many functions. but people prefer nonzero latency for fmax. In that case you take control of how to cascade modules and when to expect results.

Thanks for the reply. Is it wrong to use zero latency?

--- Updated Mar 28, 2023 ---

Sounds like your code is designed to work with zero latency IP functions. Most basic arithmetic IP functions can be implemented with zero latency, but as kaz1 told, only with reduced fmax. You should know if it's an issue for your design.

The usual procedure goes the other way. Know the target fmax of your design, choose IP latency necessary to achieve it, construct respective pipelining for the datapath.

Is it wrong to use zero latency for floating point operations?

--- Updated Mar 28, 2023 ---

Latency is telling you when result is ready(after how many clocks).
it could be that zero latency worked for you if you are cascading many functions. but people prefer nonzero latency for fmax. In that case you take control of how to cascade modules and when to expect results.

I have other questions regarding this like how is this latency tied into the number of cycles for each operation.How to synchronize between different modules using latency?
Please reply.

--- Updated Mar 28, 2023 ---

Sounds like your code is designed to work with zero latency IP functions. Most basic arithmetic IP functions can be implemented with zero latency, but as kaz1 told, only with reduced fmax. You should know if it's an issue for your design.

The usual procedure goes the other way. Know the target fmax of your design, choose IP latency necessary to achieve it, construct respective pipelining for the datapath.

I have other questions regarding this like how is this latency tied into the number of cycles for each operation.How to synchronize between different modules using latency?

Please reply.

 

[dick_freebird]

I would be surprised if any but the simplest math ops were single
cycle ("0") latency. Back when I cared about FPUs I saw some of the
more complex functions taking tens of clocks. You can parallel some
stuff, I am unconvinced that anyone can fully parallel it all to get
single cycle execution of every funky function.

Perhaps your "zero latency" data was left over from the last "pull"
and your 3, 4, 5... latency is coming out "half baked" for not enough
cycles to get it done?

I'd be looking for some vendor data on this, and maybe take the
most "leisurely" one and do your own testing - run from 0 to
"over the top" logging results (maybe ping-pong between two
"calcuations" of different, known outcomes, so you know where
any result came from and when) and see where you get repeatable
and correct results, and where not.

 

[dpaul]

@Soh_bhat
I agree with with dick_freebird writes above...

You also need to supply us with more info from the IPs UG regarding the latency of the core if you wish a better answer.