lpm functions with no clock

[Altera_Forum]

Hi  

 I am very new to fpga so apologise if these are dumb questions but I have searched all over and cant find any help.  We are trying to use some lpm functions concatenated together, a mult_accumulator which is then divided and then sqrt but we are struggling to get TimeQuest to verify.  The systemis running with a 125MHz clock but the data is only passed into these blocks at about 50Hz, I have found that the calculations cant all be done in time so I started to add propagation delays. Without propagation delays is it assumed that each block will take 1 clock tick when analysed in TimeQuest? The reason I ask this is that there is no clock input so how would it know which clock to associate? (It must be getting a clock from somewhere otherwise it wouldnt be failing TimeQuest). We had assumed these blocks are pure combinatinal logic if there is no clock.  When I add propagation delay, how can you know that calculation is complete? There is no done signal to be able to take the answer and clock it out to other parts of the system.  Really appreciate any help because our heads are about to explode!  Thanks

[Altera_Forum]

If TimeQuest is analyzing the paths as register-to-register (clocked) paths, then you must be feeding the input to the combinatorial logic from registers and capturing the result in registers. 

 To tell TimeQuest that the input registers will not be updated for several clocks, allowing the output to become valid, you must assign a multi-cycle constraint. For example, if you constrain just the clock (a single clock cycle for register-to-register paths) and the path fails by 2.1 clock periods, then placing a 3 clock cycle multi-cycle contraint will tell TimeQuest that this particular register-to-register path is allowed 3 times the clock period to settle. Its then up to your control logic to ensure that the inputs are held valid, and the output registers enabled 3 clocks later.  Look for multi-cycle contraints in the TimeQuest documents and in Rysc's TimeQuest guide on the AlteraWiki.  Cheers, Dave

[Altera_Forum]

Does lpmmult_acum work without a clock?

[Altera_Forum]

--- Quote Start ---  Does lpmmult_accum work without a clock?  --- Quote End ---   The MegFunction is essentailly representing a DSP block, it can work without a clock in some applications. To achieve speed to the FPGA limits, it will always refer to registered and pipelined operation. Also the other functions mentioned in the original post are more or less demanding for registered operation if perfomance is an objective.  The said data rate of 50 Hz is somehow unusual for FPGA applications. In terms of efficiency, a small 8-bit micro would be an appropriate solution for 50 Sps/s signal processing. If you want a FPGA to perform the calculations, sequential processing, e.g using a serial divider can save maybe 90 % of the fast parallel standard implementation's resource requirements.  If you want to implement pure combinational arithmetic, Quartus timing analysis will still tell you the total propagation delay you are asking for.

[Altera_Forum]

If you have a system clock, why don't you add pipelining to the lpm modules? You can specify the latency, and then you'll know how many clock ticks it'll take to compute. Sounds like you have a long time for the computation at a 50Hz data rate, so I wouldn't think the latency would be a problem.

[Altera_Forum]

Frank, 

from the doc lpmmult_accum is not a y = a*b+c operation, but it actually y = y + a*b, with y being an internal register within the function. Hence my question...  BTW, a small note:  TimeQuest represents time as a 32 bit integer number in picoseconds and can't represent time above ~4 milliseconds. When dealing with such cases (ie, a 50 Hz clock as a 20 ms period), it's necessary to lie a bit to TimeQuest.

[Altera_Forum]

--- Quote Start ---  from the doc lpmmult_accum is not a y = a*b+c operation, but it actually y = y + a*b, with y being an internal register within the function. Hence my question...  --- Quote End ---   You are right, y = y + a*b can't be implemented without a clock. Also the MegaWizard GUI doesn't have an option to omit the clock for the accumulator register. In the pdf user guide integer arithmetic megafunctions, ALTMULT_ACCUM clock inputs are designated as optional. This is probably just a typo, or referring to a special case where accumulator feedback is disabled.

[Altera_Forum]

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

[Altera_Forum]

--- 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.

[Altera_Forum]

--- Quote Start ---   We were going to add pipeline stages eventually   --- Quote End ---    Don't wait until the end, add them as you design the logic. If you are using DSP blocks, then look at their operating modes in the handbook for the device you are using, and instantiate or infer a calculation that maps to a DSP block exactly, including the pipeline registers (output registers).  You stated that you plan on operating at 125MHz. This should be easily achieved using DSP blocks and pipeline registers in Cyclone/Arria/Stratix devices.  You do not have to use LPM/MF components for DSP calculations. The Quartus handbook (and templates) and the Stratix Cookbook show various techniques for inferring logic. If you place-and-route and look at the implemented logic, you can check if your code has been inferred correctly.  Cheers, Dave