Forum Discussion
Honored Contributorset_input_delay And set_output_delay .SDC Constraints
create_clock -period 37.037 -name clkvin;# virtual clock for input constraintset_input_delay -clock clkvin -max 25 -clock_fallset_input_delay -clock clkvin -min 10 -clock_fallalways @ (posedge CH2_BITEC_CLK) begin input_data <= CH2_BITEC_IN; end
24 Replies
Altera_ForumDid I print the demand correctly from the chart? If so, why design fail, and how can I make it work?
Thank you!- Altera_Forum
You don't look at signal tap or data integrity to check timing constraints as it is the hard way. You better check timequest waveforms on the path(report timing path in the timequest GUI)
I believe from your device diagrams that its data/clock offsets are meant to be same regardless of clock edge. So you configure device to use say rising edge as fpga then use the figures directly.i.e. 9/26 for min/max input delay sdc values & -0.5/+0.5 for min/max output delay sdc values. If timing does not pass it does not mean sdc commands are wrong. - Altera_Forum
Hello again! Kaz, I am back with the results and I think I have an obligation to share them with you and everyone else in case they prove to be beneficial.The results seem to contradict what we had established here.Here's what happened :When I configured the external device to output data on the rising edge of the clock with the input delay(min) set to 9ns and the input delay(max) set to 26ns(both w.r.t to rising edge). These are the bytes that were latched on the rising edge, with the input constraints :
Vcd File Exported from Signal Tap, displayed in gtkwave : https://www.alteraforum.com/forum/attachment.php?attachmentid=13497 Now, when I configure the external device to output data on the falling edge of the clock and remove all sdc constraints, except the clock constraints, I seem to get the correct pattern.These are the bytes that were latched when data was output on the falling edge, sampled on the rising edge, without any Input Constraints : Signal Tap File https://www.alteraforum.com/forum/attachment.php?attachmentid=13498 Please note that the correct synchronization pattern is FF 00 00 XYZ. These results were obtained using the SignalTap Logic Analyzer.The sampling clock for SignalTap is the same as the clock input from the external device(which also clocks the input register). - Altera_Forum--- Quote Start --- sorry but can you explain what you mean by "if this is right". --- Quote End --- "The two clocks are shown because of the I2C configurable latching(rising edge or falling edge for single latching mechanism).The diagram here shows dual latching (on both rising and falling edges), it basically latches twice per clock cycle, which is why the tS and tH are labelled as they are.I think the diagram just says that in the 1 ns (0.5 ns for setup and 0.5 ns for hold) around any edge(rising or falling), the data should remain constant if the dual latching mechanism is used." And yet again thank you for your patience and help! :)
- Altera_Forum--- Quote Start --- But even if this is right, it still doesn't explain why timing fails if I increase the output_delay_min beyond -3ns(like -4,-5 e.t.c). --- Quote End --- sorry but can you explain what you mean by "if this is right".
- Altera_Forum
But even if this is right, it still doesn't explain why timing fails if I increase the output_delay_min beyond -3ns(like -4,-5 e.t.c).
- Altera_Forum
I think I might know what's happening here.The two clocks are shown because of the I2C configurable latching(rising edge or falling edge for single latching mechanism).The diagram here shows dual latching (on both rising and falling edges), it basically latches twice per clock cycle, which is why the tS and tH are labelled as they are.I think the diagram just says that in the 1 ns around any edge(0.5 ns for setup and 0.5 ns for hold), the data should remain constant if the dual latching mechanism is used.
And yet again thank you for your patience and help! :) - Altera_Forum--- Quote Start --- I realize that the only requirement on the input register is that its setup time should be less than the TCO max of the device and that its hold time must be less than the TCO min. However, --- Quote End --- The wording is not right as tCO is relative to launch edge while tSU or tH are relative to latch edge. But I get what you think. The early margin of invalid window must be further from tH point and late margin must be before tSU point. --- Quote Start --- I have one final problem that I've run into.While trying to constrain the output side, (which too is at 27Mhz, I seem to have a rather strange result). Please view the attached diagrams. The setup time -minimum value is 0.5 ns.The hold time -minimum value is 0.5 ns, but the Hold Time is described wrt to the falling edge of the clock(Data at output gets latched on the rising edge of the clock).I tried to implement this constraint by setting the minimum output delay to (18.5ns + 0.5ns), but the constraints fail.I have seen you post elsewhere that the min delay should be set to -tH, but that seems to be the case when tS and tH are wrt to the same edge. Is this the correct way to constraint what is given in the diagram? --- Quote End --- You are showing two clocks; clock and its inversion and then you state that it is relative to falling edge. if your fpga launches on rising edge then you need to adjust figures or launch on falling edge to make life a bit easier or use falling_clock if available in command to adjust the figures I will assume that with respect to rising edge of device tSU = 18.5 - 0.5 = 18 & tH = 18.5 + 0.5 = 19 Then comes the entry of sdc commands. I feel both are negative now as they are behind presumed rising latch edge (or could be made positive relative to next latch) but I am not sure and you need to see what the tool does and how it interprets your entries, look at results such as output registers tCO(frm datasheet) or io path waveforms. Whether it fails timing or not is a different issue. The starting point is enter the constraints correctly.
- Altera_Forum
I found this guide by Ryan Scotville and it seems to have done the trick.With your posts here and that guide, I think I now have an understanding of how this works.I realize that the only requirement on the input register is that its setup time should be less than the TCO max of the device and that its hold time must be less than the TCO min. However, I have one final problem that I've run into.While trying to constrain the output side, (which too is at 27Mhz, I seem to have a rather strange result). Please view the attached diagrams. The setup time -minimum value is 0.5 ns.The hold time -minimum value is 0.5 ns, but the Hold Time is described wrt to the falling edge of the clock(Data at output gets latched on the rising edge of the clock).I tried to implement this constraint by setting the minimum output delay to (18.5ns + 0.5ns), but the constraints fail.I have seen you post elsewhere that the min delay should be set to -tH, but that seems to be the case when tS and tH are wrt to the same edge.
Is this the correct way to constraint what is given in the diagram? https://alteraforum.com/forum/attachment.php?attachmentid=13451&stc=1 https://alteraforum.com/forum/attachment.php?attachmentid=13452&stc=1 - Altera_Forum--- Quote Start --- Thank you for your patience! I think I have something fundamentally wrong. Let's assume that there are two registers.One is the Input Register, and the other is a simple register somewhere in the design. Now, when I set the output_delay to 26 ns, I imagine that the Input Register and the other register get clocked differently. To me, the input register gets its clock pulse at 26, 26 + 37 , 26 + 2*37 ,..........., 26 + n*37...... And the other register is clocked at 37, 37 + 37, 37 + 37. So, when I think like this, I imagine that whatever combinational logic is inserted between the register that gets clocked at 26, 26 + 37....(Input Register) and the other register which gets clocked at (37, 37 + 37), has only 37 - 26 = 11 ns to settle.If instead we used back to back registers to just crossover from the input domain to the simple register domain, we'd have the complete 37ns between clock pulses? --- Quote End --- Each register has its own tCO. In your case the external device has tCO max of 26ns and assuming it stays so at fpga pins. The fpga registers have their own tCO and a fast io register is expected to have its tCO short enough (that is why we say fast io register). The clock period is 37 ns for all paths clocked by that clock but the window available for sampling is much less on any path because it starts from max tCO moment and ends at tSU restrictions. The tCO at any register should be as short as possible without hitting back on tH of previous latch edge, and shouldn't be as long as to hit tSU of next latch edge. The fitter ensures tCO doesn't hit tH as clock is designed always faster than data(this is done at silicon level i.e. fast clock networks). The tSU will be safe from violation as long as the clock is not too fast or data delay is not too much. Long combinatorial sections mean more data delay and may violate tSU so either break it up into thinner sections or lower the clock rate. In short "enter input constraints and check timing of rtl chains in your design and if you run into trouble then you start to help the tool" by pipelining ...etc.
