Time quest math operation constraint

[Altera_Forum]

I have two values that come in at most once every 500KHz, which is about 2us. I need to divide these values by the time the new values come in. That gives me 2us to do the division. The main clock is running off a 50MHz clock so what I did is just put a counter that generates an enable pulse 1us after the data comes in to capture the result in a flip-flop. 

 When I run time quest it complains telling me that the 50MHz clock is too fast and the failing paths are all in the paths from the input values to the resultant flip-flop. What method should I use to correctly tell the Timing Analyzer what I'm doing?   I'm assuming set_min delay and set_multicycle_path are two ways that would work. However, because the window is always changing I'm thinking that set_multicycle_path would not be the correct choice. I'm pretty new to this and any help would be appreciated.

[Altera_Forum]

Hi rawbus, 

 I see there two possible solution to your problem.  Either set_multicycle_path and set it e.g. to 10 clock cycles. So it is still smaller then 1 us but should be enough for the fitter and timing analyzer.  Or us another division algorithm that has a smaller delay. What about doing it with the pen and paper method so you compute 1 bit per clock but this just needs a comparator, bit shift and subtractor. This also will reduce the logic count.  Best Regards, Mathias

[Altera_Forum]

I'm not really worried about the delay in the division operation since I have 2us in the worst case to get the result. I basically then average these values over a period, i.e. slow operation. I just want to make sure Quartus knows what I'm doing so it well tell me I'm meeting timing requirements.  

 At the moment I'm using the set multicycle path commands:  set_multicycle_path -from [x] to [y] -setup -end 50  set_multicycle_path -from [x] to [y] -hold -end 49  Everything compiled and Time Quest is now telling me I meet the timing requirements. However, it also said it is adding in large delay routing in order to meet hold timing. All I'm doing is putting an enable to the register, which comes from a count delay off the main clock. This is just extending the latch edge and that's it.   Is it normal for Quartus to add large routing delays to meet hold requirements when using multicycle paths?

[Altera_Forum]

Hi rawbus, 

 just add a multicycle exception for setup. Here is an example that matches your case: timequest example: multicycle exceptions (http://www.altera.com/support/examples/timequest/exm-tq-sdc-exceptions.html)  Best Regards, Mathias

[Altera_Forum]

They don't seem to use the set_multicycle_path -hold command. Is that normal operation to not use them in pairs?  

 In the TimeQuest User guide by Rysc he mentions using them in pairs to maintain the default values.

[Altera_Forum]

Hi rawbus, 

 you are right, when you just apply a multicycle path setting for setup this also automatically shifts the hold edge. So with the multicycle path hold setting this is set back to the launching clock edge.  In this case I can't explain why the fitter adds these additional delays to meet your hold timing.  Maybe try to set your multicycle path settings to 5 or 10. I think this should give the fitter enough room to meet your timing requirements.  Best Regards, Mathias

[Altera_Forum]

Ok, thanks for the input Schmalisch. Everything seems to be working correctly.