--- Quote Start ---
Hi All,
Thanks for the feedback I really appreciate it.
We are clocking in the data to the ALTMULT_ACCUM but the rest of the lpm functions that are attached (without a clock) are pure combinational with the final result (output of the SQRT) not actually attached anywhere yet. So, I can see the initiation of the calculation being from a register but not the result, is this still classed as a clocked register-register system? even though the result doesnt end up at a register?
We were going to add pipeline stages eventually but I prefer to understand the problem and knowing how/what I am fixing rather than just adding what seems to me to be a delay for no reason. I guess somehow we have implemented a register-register system without realising.
Also on systems like this how can you best account for the length of time the calculations will take if they dont have some kind of DONE signal out? Do you have to account for the delay yourself in clock ticks and assume the result is ready?
Finally is there an alternative to these lpm functions? I read somewhere that they should only be used in older designs.
Thanks
--- Quote End ---
Timing analysis is only reported for paths between two registers inside fpga or at one io register if you set delay figures in the statements set_input_delay/set_output_delay as then an external register path is known to the tool.
Regarding finishing combinatorial results in one clock period then the tool looks at any given path between two registers and defaults to one clock period and issues timing failure if it can't push new result within one clock period less timing window. If your data rate is lower than system clock then you can either tell the tool to change default to some multicycle at specific paths with the design being aware of that or use clock enable and apply multicycle to all clockenabled paths which is safer.
Honored Contributor
