Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

18ns Path delay from reg output to output pad - Sanity check

Status
Not open for further replies.

pigtwo

Member level 4
Joined
Jul 16, 2015
Messages
70
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
2,771
Hello all,

I'm working a project that I'm trying to migrate from a Spartan 3 to a Artix 7. I'm running a quick test on a dev board to verify there are no major problems before we commit. But I'm running in to a weird problem in timing. I'm seeing really long routing delays(>18ns) for fairly short distances on a number of signals.

For example I have a 12 bit register that gives its output directly to an output. One of the 12 bits is failing timing and its coming from the net delay. See the below for an image of the timing output for this signal. For reference the clock period is 7.5ns.
delay_1.PNG

Unless I'm misreading or misunderstanding something I see an 18ns delay for just the highlighted part. See below for the path this route takes.
delay_2.PNG

That seems super short to me so I don't understand why there is such a delay.

I'm mostly looking for advice and thoughts on this. Does anyone have an idea why this might be happening? I feel like I'm just doing something wrong.

I'm very new to Vivado so I don't completely understand how to use it correctly so I might be looking at the wrong thing.

Thank you!
 

Turn on the routing in the view. There must be some issue with how the path is being routed. 18 ns incremental routing delay is excessive given the placement of the I/O and the Slice. Are you absolutely sure you've selected the correct net in for the rat's nest view (it seems like you probably did as you are looking at a slice that is x162y82?
 

I believe clicked on the correct locations. That arrow is drawn by Vivado when I click on the path in the first image(the highlighted one). Clicking 'Routing resources' in menu bar(is the way to open routing view?) shows the below:
delay_3.PNG

I believe the white line is the actual route taken. I'm thinking there is something wrong with my constraints because the route it took is crazy. It starts off right next to where it wants to go but ends up going all over the chip first.

I need to look at my constraints, I converted to XDC and I'm not very familiar with it yet. But in case it obvious to someone why this might be happening please let me know.
 

That is honestly the most ridiculous routing job I've seen in a long time working with FPGAs.

You don't by chance have some really strange XDC constraint for your I/O timing do you?

You should probably post the constraint you are using for that I/O it almost looks like it added delay to meet a minimum delay constraint for a clock to out path.

- - - Updated - - -

You should output the entire path report for this pin and post it, along with the timing constraints used for this pin.

BTW, if you came from ISE land, with UCF files, the input and output constraints are NOT the same for XDC, which uses the synopsys convention. An input constraint in UCF is the allowed delay from pin to FF inside the FPGA. for XDC it's the source's delay from the clock to the FPGA's pin (i.e. the driving components Tco + the propagation delay of the board routing between the source and the FPGA). For and output it's the routing delay + the setup time of the external device. Maybe you are using an absurd delay because it was a UCF constraint instead of an XDC (SDC) style constraint.
 

I think you're right about something in my constraints implying I need a large delay. To be honest I had to create the constraints by converting from UCF to XDC and this is my first time using these constraints in both UCF format and XDC format. So I likely did something wrong. Below is the only constraints I have on those signals.
Code:
set_output_delay -clock [get_clocks CLK] -min -add_delay -10.000 [get_ports HD_VPP]
set_output_delay -clock [get_clocks CLK] -max -add_delay 0.000 [get_ports HD_PP]

I've checked and these do seem to be the problem. If I remove this constraint is seems to pass. I actually generated these with the constraint wizard but I definitely got something wrong.

I have to redo all the timing constraints anyways so I'll just have to do a little more research first.
 

That says your device outside the FPGA has a 10 ns hold requirement and a 0 ns setup requirement, which explains the huge routing delay to meet the 10 ns hold over PVT.

Try doing a search for "set_output_delay diagram" and you should find something that shows how the statement is applied.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top