UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
387 Views
Registered: ‎01-18-2019

one-flip-flop project with timing violations

Jump to solution

Hi All,

I have set out a goal, a challange:  to synthesize and implement a project with absolute no warnings or errors. Well, not easy. I tried this very simple design for an Artix-7 35T FPGA  under Vivado 2019.1:

always @ (posedge clk_port) LED4 <= BTN0;

Yes, an input should be forwarded to an output. I called them Button and LED, and this is what I have on the Arty7 board, so the set_input_delay and set_output_delay constriaints are actually meaningless here, still. Without them there is no problem. However, there should not be a problem with them either.

'BTN0' and 'LED4' could be pins on other ICs running on the same 100MHz oscillator. Synthesis is fully OK (except the unremoveable "[Constraints 18-5210] No constraints selected for write" message, (anyone knows how to get rid of it?) ). But implementation gives me timing violation.

Is it realistic that a 100MHz clock is too high for such a 'complex' logic and the output data cannot be there on time?

 

create_clock   -name clk_name    -period 10 -waveform {0 5} [get_ports clk_port]    
set_input_delay  -clock clk_name -max 2 [get_ports BTN0]
set_input_delay  -clock clk_name -min 0 [get_ports BTN0]
set_output_delay -clock clk_name -max 2 [get_ports LED4]  
set_output_delay -clock clk_name -min 0 [get_ports LED4]

Here is what I get:

btn_w_led_schematic.PNGbtn_w_led_timing_violation.PNG

Please help. I have made a number of designs in my life and although timing report was not always OK, they always worked in hardware. What misconception am I in?

Thank you very much.

Miklos

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
352 Views
Registered: ‎01-23-2009

Re: one-flip-flop project with timing violations

Jump to solution

What the tool is telling you is correct. What you are asking it is:

  • Bring a clock in from a (presumably clock capable) pin
  • Route it through the (mandatory) input buffer
  • Route it to a global clock buffer (BUFG) using the dedicated route
  • Place it on the global clock network
    • The global clock network fans out to every clocked cell on the device with a small skew
  • Clock a flip-flop using that clock
    • This flip-flop is in the FPGA fabric
  • Drive that to an OBUF
    • The OBUF is likely has the "default" attributes, which is LVCMOS25 with slow slew and 12ma drive
  • Drive it out of the FPGA

And you are asking for all this to be done in 8ns (10ns if you change the set_output_delay -max to 0). It can't.

Some of these delays are really big

  • The delay of the global clock network is large since it needs to fan out to the entire FPGA (1.625ns)
  • The OBUF is very slow - as configured it takes 3.525ns

In addition, you are using a fabric flip-flop for this output - you should be using an IOB flip-flop (by setting the IOB property)

set_property IOB TRUE [get_ports LED4]

So it isn't surprising that you can't do this path in 8ns (or 10ns).

But you can fix that. By adding an MMCM on the clock path, you can remove the majority of the "Source Clock Delay" - the delay of the IBUF, the route to the BUFG and the global clock network) - with this done, you should easily meet timing at 10ns.

And by the way, you can see all of this through the datasheet. This configuration (clock capable clock input to BUFG to IOB flip-flop and out the OBUF) is described by the parameter Tickof (DS189 Table 39). This specifies the time when using SSTL15 (which is a faster I/O standard), and for this device is 6.61ns for a -1 speedgrade - since your IO standards are slower (and you aren't using the IOB flip-flop), this grows to what you see - 10.7ish.

If you use the MMCM to remove the clock insertion, you get the timing shown in the Tickofmmcmcc, which is only 1.00ns for the same -1 speedgrade - clearly much faster (although you may have trouble with a 0ns hold time requirement with the MMCM).

Avrum

View solution in original post

6 Replies
Highlighted
Adventurer
Adventurer
373 Views
Registered: ‎01-18-2019

Re: one-flip-flop project with timing violations

Jump to solution
Update: If the delay constraints are set to -min 0, -max 0 I still get 0.719ns, exactly 2ns less than in my opening post, which is perfectly understandable. Does this mean, everything is OK and data cannot be sent from one pin to another under 10ns?
0 Kudos
Explorer
Explorer
364 Views
Registered: ‎03-31-2016

Re: one-flip-flop project with timing violations

Jump to solution

Your timing report shows a lot of clock skew.  Typically you would use a MMCM or PLL to generate the internal clocks which gives the tools a lot of ways to adjust the clocking.

 

Your IOBUFs are adding a lot of delay.  The IOSTANDARD applies matters a lot of input and output timing.

 

Your constraints may not be correct, UG949 gives some good information on how to constrain IO.   For real designs, they really should be derived from the datasheets of the connected compoents and PCB routing delays not just some "best guesses".  For a button you would want to use small min and max input delays as this gives the most time for setup of the register.  For LED  outputs you want a small maximum as that basically the required setup time of the device but the min should be set to some large positive number as it is the hold time allowed for the FPGA.

 

Designing the IO, especially at faster speeds, is actually some of the most difficult portion of FPGA design.

Historian
Historian
353 Views
Registered: ‎01-23-2009

Re: one-flip-flop project with timing violations

Jump to solution

What the tool is telling you is correct. What you are asking it is:

  • Bring a clock in from a (presumably clock capable) pin
  • Route it through the (mandatory) input buffer
  • Route it to a global clock buffer (BUFG) using the dedicated route
  • Place it on the global clock network
    • The global clock network fans out to every clocked cell on the device with a small skew
  • Clock a flip-flop using that clock
    • This flip-flop is in the FPGA fabric
  • Drive that to an OBUF
    • The OBUF is likely has the "default" attributes, which is LVCMOS25 with slow slew and 12ma drive
  • Drive it out of the FPGA

And you are asking for all this to be done in 8ns (10ns if you change the set_output_delay -max to 0). It can't.

Some of these delays are really big

  • The delay of the global clock network is large since it needs to fan out to the entire FPGA (1.625ns)
  • The OBUF is very slow - as configured it takes 3.525ns

In addition, you are using a fabric flip-flop for this output - you should be using an IOB flip-flop (by setting the IOB property)

set_property IOB TRUE [get_ports LED4]

So it isn't surprising that you can't do this path in 8ns (or 10ns).

But you can fix that. By adding an MMCM on the clock path, you can remove the majority of the "Source Clock Delay" - the delay of the IBUF, the route to the BUFG and the global clock network) - with this done, you should easily meet timing at 10ns.

And by the way, you can see all of this through the datasheet. This configuration (clock capable clock input to BUFG to IOB flip-flop and out the OBUF) is described by the parameter Tickof (DS189 Table 39). This specifies the time when using SSTL15 (which is a faster I/O standard), and for this device is 6.61ns for a -1 speedgrade - since your IO standards are slower (and you aren't using the IOB flip-flop), this grows to what you see - 10.7ish.

If you use the MMCM to remove the clock insertion, you get the timing shown in the Tickofmmcmcc, which is only 1.00ns for the same -1 speedgrade - clearly much faster (although you may have trouble with a 0ns hold time requirement with the MMCM).

Avrum

View solution in original post

344 Views
Registered: ‎06-21-2017

Re: one-flip-flop project with timing violations

Jump to solution

And if I may add to the advice given by @avrumw, that is not the correct way to forward a clock from the FPGA.  You should use an ODDR register clocked by your clock.  One data input of the ODDR should be tied high and the other low.  The choice of which one is high and which one is low is dependant on your desired output phase of the clock.

Adventurer
Adventurer
280 Views
Registered: ‎01-18-2019

Re: one-flip-flop project with timing violations

Jump to solution
Thank you Avrum, and necare81, and Bruce, for your quick and thorough reply. It takes a little time to digest and experience, but now I know in which way to go. Kudos to all of you!
0 Kudos
Adventurer
Adventurer
265 Views
Registered: ‎01-18-2019

Re: one-flip-flop project with timing violations

Jump to solution

@bruce_karaffa wrote:

.. that is not the correct way to forward a clock from the FPGA.  You should use an ODDR register clocked by your clock. 

Actually I was not to forward the clock at all, I was hoping to be able to use the FPGA in a way that the source IC (here BTN) and the destination IC (here LED) all use one common clock from an oscillator on the PCB.  But now I am starting to realize the importance of generated clocks inside the FPGA to eliminate clock buffer delays, and also that what I wanted is not the intended use for FPGAs.  FPGAs are more like standalone logic that are to communicate with other ICs thru dedicated interfaces and protocols..

0 Kudos