cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
1,686 Views
Registered: ‎03-12-2018

Artix 7 Design has HUGE routing delays

Jump to solution

We are targeting an Artix 7 part (xc7a15tftg256-1L) and have noticed some really large net routing delays, like 25ns large.

 

Our design utilization is not super high. When we examine some of the long routes it seem like they are going all over the chip, even where there are no populated cells.  I have attached some images to show what we are seeing. The schematic shows a selected net that is failing timing. When we look at it in the device view we see the trace going all over the chip.

 

 

Is there some optimization we should be using?  Why do the routes go all over like this?

 

Thank you for your help.

 

rreport_route_status -verbose
Design Route Status
                                               :      # nets :
   ------------------------------------------- : ----------- :
   # of logical nets...........................:       30029 :
       # of nets not needing routing.......... :       11566 :
           # of internally routed nets........ :       11347 :
           # of nets with no loads............ :         219 :
       # of routable nets..................... :       18463 :
           # of fully routed nets............. :       18463 :
       # of nets with routing errors.......... :           0 :
   ------------------------------------------- : ----------- :

Utilization.PNG
Schematic.png
Trace.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
2,086 Views
Registered: ‎01-23-2009

Re: Artix 7 Design has HUGE routing delays

Jump to solution

We did not have an output constraint for the InOutData,

 

This is not true - I don't know where the requirement came from, but there is one. The timing report which ends at

 

io_EIMInOutData[11]   (output port clocked by EIMBurstClk

 

Has an output delay of 2ns

 

Output Delay    2.000ns  

 

This can only happen due to a set_output_delay that applies to this port.

 

 

2. We did not have, or see at least, any hold violation. The only thing the tools reported were setup violations. All our hold times were reported as in the "blue".

 

I wasn't asking about a hold violation, I was asking for the detailed timing report on the hold check for this path. I expect that the tool added all the delay to fix an incorrect hold requirement - it succeeded, but at the cost of a huge setup violation. Looking at the hold check directly can confirm that this is the case, and help figure out why.

 

Avrum

View solution in original post

8 Replies
Highlighted
Guide
Guide
1,664 Views
Registered: ‎01-23-2009

Re: Artix 7 Design has HUGE routing delays

Jump to solution

Most often when you see things like this it is because you asked for them...

 

If Vivado sees a timing path with a hold time failure, it will fix it by adding additional routing to the path. Hold time fixing takes priority over setup time problems, so it will continue to add delay to fix hold time issues even if it results in a horrible setup time failure. This is made worse due to the variation in delay over process/voltage/temperature (PVT) - for every 1ns of additional routing delay it uses to fix a hold time at fast PVT, this results in an extra approximately 3ns of delay at slow PVT on the setup check.

 

Almost always, bad hold time problems like this are the result of incorrect constraints, or incorrect paths due to bad clock crossing.

 

In this case, the path appears to be a combinatorial path through the FPGA (which are odd, and generally have terrible timing characteristics). What are your constraints that apply to this path? Do you have a set_max_delay on the path? set_input_delay that covers the input? set_output_delay on the output? Show us those, and we may be able to find the problem (and/or post the detailed timing report for both setup and hold on this path).

 

Avrum

0 Kudos
Highlighted
1,594 Views
Registered: ‎03-12-2018

Re: Artix 7 Design has HUGE routing delays

Jump to solution

avrumw, Thank you again for chiming in on one of our issues.

 

The signals of which we are talking are part of a memory interface between an i.MX6 Arm processor and our FPGA. In this scenario our FPGA is acting as the memory device where the FPGA is writing configuration to the FPGA registers and reading processed data from the FPGA. (See the figures for more clarity)

 

Our constraints that relate to this interface are shown below.

 

# INPUT_CLK goes into a MMCM to create our 128 MHz SysClk

create_clock -period 41.667 -name INPUT_CLK -waveform {0.000 20.834} [get_ports i_ClockIn]

create_clock -period 22.000 -name EIMBurstClk [get_ports i_EIMBurstClk]

 

#should be ready 2ns prior to the rising edge and be held for at least 2 ns after rising edge
set_output_delay -clock [get_clocks EIMBurstClk] 2.000 [get_ports o_EIMWait]


set_input_delay -clock [get_clocks EIMBurstClk] -min 9.610 [get_ports {i_EIMChipSelect i_EIMOutEnable i_EIMWriteEnable i_EIMAddressValid}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 13.110 [get_ports {i_EIMChipSelect i_EIMOutEnable i_EIMWriteEnable i_EIMAddressValid}]

set_input_delay -clock [get_clocks EIMBurstClk] -min 9.610 [get_ports {io_EIMInOutData[*]}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 13.110 [get_ports {io_EIMInOutData[*]}]

set_input_delay -clock [get_clocks EIMBurstClk] -min 9.610 [get_ports {i_EIMAddress[*]}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 13.110 [get_ports {i_EIMAddress[*]}]

 

We have played around with the timings and tried our best understand the timing diagrams and the constraints.  This just must be beyond our understanding at the current time.

FpgaMemInterface.png
iMx6Timing01.PNG
iMx6Timing02.PNG
IMX6DQRM_MemoryTiming.png
0 Kudos
Highlighted
1,596 Views
Registered: ‎03-12-2018

Re: Artix 7 Design has HUGE routing delays

Jump to solution

Avrumw,  I made a lengthy reply but the system deleted it as spam?  Maybe it will get restored.  In the meantime here is the timing report for one of the paths that fail along with our current constraints. NOTE: We did have negative values for the input delay mins originally but we tried Positive values (even though it didn't make complete sense to use to do that) just as a test.

 

# The FPGA system clock is a 128 MHz clock that is not synchronous to the EIM Burst Clk.

create_clock -period 22.000 -name EIMBurstClk [get_ports i_EIMBurstClk]

 

#should be ready 2ns prior to the rising edge and be held for at least 2 ns after rising edge
set_output_delay -clock [get_clocks EIMBurstClk] 2.000 [get_ports o_EIMWait]

set_input_delay -clock [get_clocks EIMBurstClk] -min 9.610 [get_ports {i_EIMChipSelect i_EIMOutEnable i_EIMWriteEnable i_EIMAddressValid}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 13.110 [get_ports {i_EIMChipSelect i_EIMOutEnable i_EIMWriteEnable i_EIMAddressValid}]

set_input_delay -clock [get_clocks EIMBurstClk] -min 9.610 [get_ports {io_EIMInOutData[*]}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 13.110 [get_ports {io_EIMInOutData[*]}]

set_input_delay -clock [get_clocks EIMBurstClk] -min 9.610 [get_ports {i_EIMAddress[*]}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 13.110 [get_ports {i_EIMAddress[*]}]

 

                   
Summary                    
Name    Path 81                
Slack    -19.377ns                
Source    i_EIMChipSelect   (input port clocked by EIMBurstClk  {rise@0.000ns fall@11.000ns period=22.000ns})                
Destination    io_EIMInOutData[11]   (output port clocked by EIMBurstClk  {rise@0.000ns fall@11.000ns period=22.000ns})                
Path Group    EIMBurstClk                
Path Type    Max at Slow Process Corner                
Requirement    22.000ns (EIMBurstClk rise@22.000ns - EIMBurstClk rise@0.000ns)                
Data Path Delay    29.732ns (logic 3.742ns (12.586%)  route 25.990ns (87.414%))                
Logic Levels    3  (IBUF=1 LUT2=1 OBUFT=1)                
Input Delay    9.610ns                
Output Delay    2.000ns                
Clock Uncertainty    0.035ns                
                    
Data Path                    
Delay Type    Incr (ns)    Path (ns)    Location    Netlist Resource(s)    Partition
(clock EIMBurstClk rise edge)    (r) 0.000    0.000            
input delay    9.610    9.610            
    (f) 0.000    9.610    Site: G5    i_EIMChipSelect    
net (fo=0)    0.000    9.610        i_EIMChipSelect    
IBUF (Prop_ibuf_I_O)    (f) 0.953    10.563    Site: G5    i_EIMChipSelect_IBUF_inst/O    
"net (fo=4, routed)"    22.759    33.322        i_EIMChipSelect_IBUF    
LUT2 (Prop_lut2_I1_O)    (f) 0.124    33.446    Site: SLICE_X14Y74    io_EIMInOutData_IOBUF[31]_inst_i_2/O    
"net (fo=32, routed)"    3.231    36.677        io_EIMInOutData_IOBUF[11]_inst/T    
OBUFT (TriStatE_obuft_T_O)    (r) 2.665    39.342    Site: D16    io_EIMInOutData_IOBUF[11]_inst/OBUFT/O    
"net (fo=1, unset)"    0.000    39.342        io_EIMInOutData[11]    
            Site: D16    io_EIMInOutData[11]    
Arrival Time        39.342            
                    
Destination Clock Path                    
Delay Type    Incr (ns)    Path (ns)    Location    Netlist Resource(s)    Partition
(clock EIMBurstClk rise edge)    (r) 22.000    22.000            
clock pessimism    0.000    22.000            
clock uncertainty    -0.035    21.965            
output delay    -2.000    19.965            
Required Time        19.965            

FpgaMemInterface.png
0 Kudos
Highlighted
Guide
Guide
1,576 Views
Registered: ‎01-23-2009

Re: Artix 7 Design has HUGE routing delays

Jump to solution

The constraints you sent clearly aren't complete - there is no set_output_delay on io_EIMInOutData, which is the endpoint that is currently failing. However, I will assume it is set to 2 like o_EIMWait.

 

The set_output_delay on o_EIMWait is simply "2" - there is no min/max. This means that the min and max are the same; the data is required to be valid no earlier than 2ns before the clock edge and must remain (2ns setup) and has a -2ns hold time, which means that as long as it doesn't change before 2ns before the clock edge (for the next change) then the data is valid - essentially, you are saying that your device is sampling the output of the FPGA instantaneously - as long as the data is valid instantaneously at 2ns before the rising edge of the clock then it is OK.

 

Second, you are only showing me the setup failure - I really need to see the hold failure...

 

Third, you need to send me consistent sets of data. The path you are showing has a set_input_delay -max 9.610, but your constraints are showing this for the min, not the max (so the path report and the constraints are not from the same trial).

 

Finally, if you really had a set_input_delay -min with a negative number that was greater than 2, then you would be creating a hold time failure that the tool has to fix (and hence would give you the results you showed originally).

 

So...

 

Clean everything up. From the same run, show me

  - the constraints

  - the failing setup path

  - the failing hold path

  - while not necessary, the schematic and the device view (with routing resources shown) of the failing path

 

With a consistent set of information, we can look at the problem again. But - it seems like you aren't clear on how to constrain this interface, and you need to get the constraints right...

 

Avrum

0 Kudos
Highlighted
1,568 Views
Registered: ‎03-12-2018

Re: Artix 7 Design has HUGE routing delays

Jump to solution

avrumw,

 

So we will work on getting a full set of what you asked for.  We have actually been trying things to understand this issue better, based on some of your comments, and so the code is not in the exact same state as it was when we posted the question.

 

Answer some of you questions you mentioned in your reply:

1. The constraints we sent you were our complete set, related to these signals. We did not have an output constraint for the InOutData, which in hindsight, does make sense to have.

 

2. We did not have, or see at least, any hold violation. The only thing the tools reported were setup violations. All our hold times were reported as in the "blue".

 

3. The reason we used negative numbers for the minimum initially was that timings in the spec were referenced from the first BCLK and therefore the address was indeed valid before the first edge and therefore a negative number.  We ran it with the  -min and -max set to values that were equivalent values only referenced to the next clock edge (all values positive) and the tools reported the same timing problems as with the negative values referenced to the first clock edge.

 

We can tell the spec is trying to define a valid window, with respect to the BCLK, over which the signals are valid but we get confused as to which edge the tools will interpret the timings. We have watched the videos and read the documentation but it is still unclear to us at times (obviously).

 

4. The Wait signal is an output from the FPGA and the data sheet shows the following (see image below). It only specifies a min (not a max) for both setup and hold. So, after thinking about this, do would we use something like:

 

set_output_delay -clock [get_clocks EIMBurstClk] -min 2.000 [get_ports o_EIMWait] # Hold 2ns after edge?

set_output_delay -clock [get_clocks EIMBurstClk] -max 2.000 [get_ports o_EIMWait] # Valid 2ns before edge?

EimWriteTimingExample.PNG
EimBusTimingTable.PNG
0 Kudos
Highlighted
Guide
Guide
2,087 Views
Registered: ‎01-23-2009

Re: Artix 7 Design has HUGE routing delays

Jump to solution

We did not have an output constraint for the InOutData,

 

This is not true - I don't know where the requirement came from, but there is one. The timing report which ends at

 

io_EIMInOutData[11]   (output port clocked by EIMBurstClk

 

Has an output delay of 2ns

 

Output Delay    2.000ns  

 

This can only happen due to a set_output_delay that applies to this port.

 

 

2. We did not have, or see at least, any hold violation. The only thing the tools reported were setup violations. All our hold times were reported as in the "blue".

 

I wasn't asking about a hold violation, I was asking for the detailed timing report on the hold check for this path. I expect that the tool added all the delay to fix an incorrect hold requirement - it succeeded, but at the cost of a huge setup violation. Looking at the hold check directly can confirm that this is the case, and help figure out why.

 

Avrum

View solution in original post

Highlighted
1,533 Views
Registered: ‎03-12-2018

Re: Artix 7 Design has HUGE routing delays

Jump to solution

avrumw,

 

After looking at your responses and experimenting/researching with how the constraints work I think we finally have it figured out.  The initial question was answered by you in explaining why we would see such a huge net delay.  We believe that initially we had our input_delay -min value as a negative value which we now understand would cause this kind of an issue. Once we changed those to proper non-negative numbers things stopped acting so strange.  You also helped point us in the right direction with some constraints that we missed and getting us to think about what they really mean and do.

 

The constraints we have now that seem to "solve" the issue we were having are as follows:

 

#EIM Signals:
#Note: io_EIMInOutData has an input and an output component so both set_output_delay and set_input_delay are used

#should be ready 2ns prior to the rising edge and be held for at least 2 ns after rising edge
set_output_delay -clock [get_clocks EIMBurstClk] -min 2.000 [get_ports o_EIMWait]
set_output_delay -clock [get_clocks EIMBurstClk] -max 2.000 [get_ports o_EIMWait]

set_output_delay -clock [get_clocks EIMBurstClk] -min 2.000 [get_ports {io_EIMInOutData[*]}]
set_output_delay -clock [get_clocks EIMBurstClk] -max 2.000 [get_ports {io_EIMInOutData[*]}]

set_input_delay -clock [get_clocks EIMBurstClk] -min 10.110 [get_ports {i_EIMChipSelect i_EIMOutEnable i_EIMWriteEnable i_EIMAddressValid}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 9.610 [get_ports {i_EIMChipSelect i_EIMOutEnable i_EIMWriteEnable i_EIMAddressValid}]

set_input_delay -clock [get_clocks EIMBurstClk] -min 10.110 [get_ports {io_EIMInOutData[*]}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 9.610 [get_ports {io_EIMInOutData[*]}]

set_input_delay -clock [get_clocks EIMBurstClk] -min 10.110 [get_ports {i_EIMAddress[*]}]
set_input_delay -clock [get_clocks EIMBurstClk] -max 9.610 [get_ports {i_EIMAddress[*]}]

 

At this point I don't think showing the previous timing results of the issue are too fruitful unless someone wants to see what an problem like this looks like.

 

Thanks again.

0 Kudos
Highlighted
Guide
Guide
1,519 Views
Registered: ‎01-23-2009

Re: Artix 7 Design has HUGE routing delays

Jump to solution

The constraints we have now that seem to "solve" the issue we were having are as follows:

 

While these constraints may pass, they are clearly incorrect...

 

As I mentioned earlier, a set_output_delay with a min and max that are the same means that the receiving device needs no data valid window. Your set_output_delays say that the receiving device needs 2ns of setup time and -2ns of hold time, thus being able to instantaneously sample the data at exactly 2ns before the clock edge - this is not realistic.

 

Furthermore (and probably more importantly), your set_input_delay values are impossible; the -min must always be smaller than the -max. As written, you have told the tools that the device will not start making a change before 10.110ns after the clock, but will complete the change (and be stable) by 9.610ns, thus essentially telling the tool that each data is valid for 0.5ns longer than a complete clock cycle (which is clearly not possible).

 

Avrum

0 Kudos