Showing results for 
Search instead for 
Did you mean: 
Registered: ‎05-23-2017

How to solve the huge input slack?

We have an internally generated clock "clk_main" which is generated by MMCM.

This clock is fed into all our system logic inside FPGA.

In order to synchronously communicate with an external USB device, we added ODDR (

We set the timing constraints as below. 

create_generated_clock -name clk_usb -source [get_pins oddr_inst/C] -multiply_by 1 [get_ports clk_usb]
set_input_delay -clock [get_clocks clk_usb] -max 7.000 [get_ports {USB_FLAGD}]
set_input_delay -clock [get_clocks clk_usb] -min 2.000 [get_ports {USB_FLAGD}]

Now, please look at the figures below.

As you can see, the huge slack (-3.166ns) occurs between USB_FLAGD (input pin) and usb_patial_empty(internal register), even though there is nothing between them.

I've been suffering for two weeks already. 

Please help us.


Thank you.


0 Kudos
1 Reply
Registered: ‎01-23-2009

Re: How to solve the huge input slack?

I have already answered this question from you in this post.

With your device consuming 5ns of of the clock period in uncertainty (min=2, max=7), it is questionable if this  interface is implementable with a 10ns period.

Your timing would be slightly better if you forced the capture flip-flop in the IOB using

set_property IOB true [get_ports USB_FLAGD]

but the difference will be nowhere near enough to make this work. As I mentioned in the referenced post, there is no way you can capture the returning data with the same clock that is generating the forwarded clock.

First lets look at whether this is possible. Ask the tool

report_timing -hold -from [get_ports USB_FLAGD] -name my_hold

If the hold time slack from this report is less than +3.166, then this interface cannot be implemented - the uncertainties are too large for this to work at 100MHz. Again, the IOB flip-flop might help, as might increasing the drive strength of the OBUF driving the clock. But if, after doing this, the sum of the setup slack (which is currently negative) and the hold slack is less than 0, then this interface can't be done this way.

If the sum of the slacks is positive, then you need to place the capture clock at exactly the right place - this can be done with another output of the MMCM driving another BUFG. The new MMCM output would need to be phase shifted forward by at least the value of the negative slack of the setup check (currently 3.166ns). Ideally you should set it so that the setup and hold slack are balanced -  the phase shift should be (hold_slack - setup_slack)/2. So, if, for example the hold slack is 3.6ns and the setup slack is -3.166ns, then the ideal phase shift is (3.6-(-3.166))/2 = 3.383ns.


0 Kudos