setup and hold time with set_input_delay

It's often good practice to get exact delays.

I STRONGLY recommend documenting your .sdc. You can just do comments like:

# The PPC datasheet has a clock Tco of 6-8ns from datasheet dated July 2007,

# And the board delay is 1ns +/-50ps from board layout, so adding those together...

or you can do equations in Tcl:

set ppc_max_tco 8.0 ;# PPC datasheet July 2007

set ppc_clk_max 1.05 ;# Max board delay Dave told me when doing board sims..

set max_ppc_clk [expr $ppc_max_tco + $ppc_clk_max]

That way the constraints are documented. I can't tell how many times I've seen people with a "well, the Tsu constraint is 4ns, and someone else did it and I have no idea how they came to that, but I have to meet that. And if we change the board layout I'm not sure what to do, or if we get different speed grade parts I'm not sure...."

That all being said, you have LOT of margin. Source synchronous interfaces run very fast(think 200MHz DDR, or a 400Mbps is pretty common). So you could just throw in something big. Then try to see if something's available from the datasheet, or measure it, or just say, hey that should be more than enough. Remember at one point you weren't constraining this at all, so you need to balance the amount of time it takes to get it exact(you could do HSPICE modeling and all sorts of other stuff, but if you meet timing by ns, why spend the time). If you upgrade to a faster interface, then maybe you'll want to refine it, but if it's documented how you got the numbers, you have a good starting point.

Thank you Rysc for your reply, things are certainly much clearer now.

I was having a read of the datasheet of the PowerPC and on the I/O specifications chapter there is a spec given for "Valid Delay Tov max" which from looking at timing diagrams seems to be the max delay between the rising clock edge and the time at which the referenced signal is stable on the putput of the PowerPC.

In the case of the databus the max delay is 6.6ns and the min 0ns.

Given that the setup relationship is 7.5 ns, it looks like this presents a problem.

Anyway I am thinking that multicycle constraints will be nessesery here. I may have to have the PowerPC configured to prolong the transfer and present the data for a longer period. eg 1 cycle more that it is currently set for. By setting placing a multicycle on the register which latches the data I should be able to succesfully meet timing.

I am resonably familiar with multicycles and from having a quick look around the forum there seem to be plenty of threads on this topic which I can study.

Really I was just wanting to know if my thinking was right on this, or indeed if there is another/better solution when this problem arises.

Many thanks for the help.

First off, make sure the spec is what you're saying. Outputs are often spec'd in terms of the input clock, i.e. the data is valid between 0 and 6.6ns after the input clock. This, by itself, is useless, since we want to know what the data output is in relation to the clock output. So if the clock output, in relation to the clock input, was 0 to 6.6ns, then we could figure out the skew between these.

Or is the spec saying the data comes out anywhere between 0ns(with the clock) up to 6.6ns after the clock? I don't know the answer, but it naturally makes a big difference. And skewed by anywhere between 0 and 6.6ns is a pretty big number(but not impossible).

Now, your setup requirement is 7.5ns. So that only leaves 0.9ns of skew inside the FPGA. First, if using a PLL in source synchronous mode, it's possible that you can meet that. Secondly, don't forget that you have -7.5ns of hold to work with. So if you're just barely meeting setup timing and have tons of hold timing, then Quartus might be able to reduce the data delay to borrow some of that hold timing. Or, you can add a positive phase shift of a few nanoseconds to your capture clock. (And you would add a multicycle -setup of 2 between the external clock and the PLL clock to get the correct requirement).

Bottom line is you still might meet timing, so give it a try. I do not think you need to go to a slower data rate.

Thanks again Rysc for your reply.

I am fairly sure that the delay of 6.6 ns specified is the max delay between the rising edge of clock leaving the PowerPC and the time the data bits are stable. I have attached the datasheet and on page 78 these details are given. Perhaps you could have a quick look at this if you had time. On page 69 there is a timing diagram where the tov max delay term is used and it seems to refer to what I think.

Anyway I took your advice and used a PLL to shift the clock and I have been able to meet timing. I had to shift the clock by +5ns to meet timing. I now have a worst case setup time of 0.790ns and a worst case hold time slack of 2.123ns.

I have not included board trace delays in the input_delay constraints, its something I will add later, but I am assuming that they would typically quite low in the order of 100´s of ps?

I am also receiving some warnings about no clock uncertainty assignment on the clocks. From looking at the attached datasheet on page 67 it specifies the max and min high and low time for PerClk (the clock in question). The values given are that the clock can be high for between 7.5 and 9.9ns (50-66%)of a 15 ns cycle and low for between 4.95ns and 7.5 ns (33-50%) on a 15 ns cycle.

Does the potential difference in duty cycle represent clock uncertainty or am I misunderstanding clock uncertainty?

If my understanding is correct, then between the 6.6ns delay on the databus and the difference in potential duty cycle, it would make meeting timing even more difficult.

Do you have any thoughts on this?

Many Thanks

I think it just means to add the following line to your .sdc:

derive_clock_uncertainty

(That should be in all .sdc files for devices 65nms and newer...)

And note that, even though your slack is getting tight, if you meet timing, and if everything is correct, then you're in good shape. I've seen designs meet timing by a few picoseconds.

hello Everyone,

Sorry for posting question in middle of no where, I did not find how to start new thread,Ok anyways

My question is,

The LPM Ram or Ram created thr MEGAWIZARD has a input latch and an output latch, because of which we are getting the 2 cycles delay in the output, which is very crucial in our design, how to over come the delay caused by the RAM, Cant we overcome this latch, if so how do we do it.

Thanks for the reply, It indeed allows to uncheck latches for the RAM, but i'm not sure weather it also allows for CYCLONE 3 FPGA.

It indicated some error when i did,and tried to compile.