- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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! ThanksLink Copied

9 Replies

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Does lpmmult_acum work without a clock?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Topic Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page