Forum Discussion
Altera_Forum
Honored Contributor
Honored Contributorset_input_delay And set_output_delay .SDC Constraints
Hello! I have little familiarity with the set_input_delay and set_output_delay SDC and was wondering whether the following commands would correctly constrain the inputs as per the requirements in the attached figure.. https://alteraforum.com/forum/attachment.php?attachmentid=13431&stc=1 what the diagram shows : I have an 8-bit port on a Video Decoder which outputs data to the FPGA.The clock used in the FPGA is output from the same device.The device is configured to change its data on the falling edge of the clock.The device opertes on a 27 Mhz clock i.e a period of 37.037 ns.The datasheet lists T5 as Output Hold Time and gives a minimum Value of 10ns.The datasheet lists T6 as Output Delay Time and gives a maximum Value of 25ns.So, I conclude that with respect to the falling edge of the clock, the data begins to change 10ns the after falling edge and regains stability 15ns later.Is this what the diagram depicts?If so, I think the constrains that specify this should be :
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_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
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
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
Did I print the demand correctly from the chart? If so, why design fail, and how can I make it work?
Thank you!
