Time quest math operation constraint

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

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?

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

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.

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