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: 
Highlighted
Adventurer
Adventurer
1,090 Views
Registered: ‎05-27-2011

Design and Timing Closure Near FPGA Maximum Resources

Jump to solution

 

Good afternoon all,

 

We have a SerDes input design, LVDS DDR 560Mb/s using the normal SerDes input IPcores etc. In our full design, we have an embedded Micro-Blaze, various custom DSP cores, FIFOs etc etc. We are using a Spartan 6 LX45. The full design has 95,000 nets, uses 75% of the available slices, 75% of the available BRAMs, 81% of the available BUFGs, 55% of the available DSP48 slices and 60% of the total IO pins.

 - The tools obtain full timing closure with: all signals routed, all constraints met, a full set of timing and physical constraints, verification of bit-level correctness of all of the sub-blocks and produce zero errors and only warnings that can either be ignored or have nothing to do with the issue I'll mention below.

 

Issue Background:

 - When we grab SerDes input data, we achieve lock to the framing signal provided, but we do get a few single-bit errors, with perhaps an error rate of 1x10-6. This we are going to measure in more detail, but we are yet to calibrate the inputs using IODELAYs for differences in PCB routing etc.

 - But. If we do a smaller build with only SerDes inputs, a basic FIFO and a UART module (6000 nets), we obtain less bit errors. The timing constraints and routing of data clocks etc near the pad-ring SerDes reources should be the same.

 - I am currently thinking that routing congesion in the full design is impacting timing closure, perhaps not to give a setup or hole violation, but enough that various margins have decreased

 

My question:

 - Are there any specific design methodologies or items to check when a design appraches the maximum resources of an FPGA?

 

 - We purchased this specific sized FPGA as it was the largest we could afford for the system budget and had enough resources for the basic resource requirement models we had at the time. It would be tough for us to bring down the #nets without reducing functionality that was part of the specs. 

 

Any advice on parts of the reports to check or methods to aid the compiler when close to maximum resource use would be very very helpful.

 

Many thanks,

Ed

0 Kudos
1 Solution

Accepted Solutions
Scholar jmcclusk
Scholar
1,400 Views
Registered: ‎02-24-2014

Re: Design and Timing Closure Near FPGA Maximum Resources

Jump to solution

Your best bet is to figure out how much timing margin you have at the LVDS inputs..  Spartan6 is not the easiest to use, compared with Artix, for example.   In your shoes,  I'd make sure that there was an IODELAY element in front of the ISERDES elements, and then I'd vary the timing to understand where the sampling is happening in the data eye.   I'll bet it's not centered, which is why you are seeing the occasional bit error.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
5 Replies
Scholar jmcclusk
Scholar
1,054 Views
Registered: ‎02-24-2014

Re: Design and Timing Closure Near FPGA Maximum Resources

Jump to solution

I rather suspect that your higher bit error rate is caused by system noise.   What kind of package are you using?  QFP or BGA?

 

In any event, if stuffing the device full to the brim with noisy logic is raising your IO error rate,  you might have to try better filtering on the power supplies, or relocating noisy IO away from your receiver inputs.   You might want to consider using dynamic timing adjustment on the LVDS inputs, to maximize your noise margins.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Adventurer
Adventurer
1,004 Views
Registered: ‎05-27-2011

Re: Design and Timing Closure Near FPGA Maximum Resources

Jump to solution

We are using BGA, we did put down a good amount of decupling but perhaps not enough high frequency decoupling. For this design we are using 8 LVDS SerDes inputs each on Banks 0 and 2, but then also each bank has both ADC data clock and framing so a total of 20 LVDS SerDes inputs. On bank 1 we have Ethernet output to the PHY IC and on bank 3 we have a SDRAM memory controler clock (MCB) interface. In all, quite a lot of IO going at the same time.

 

Would it be worth doing a hack of the PCB with more decoupling? I expect though the the inductance of flying leads to any added caps would create further issues. The PCB power regulators are suitable, but only from a DC power prospective. The power and ground planes are all fine too, but it could well be the number of used IO.

 

Many thanks,

Ed

0 Kudos
Scholar jmcclusk
Scholar
1,401 Views
Registered: ‎02-24-2014

Re: Design and Timing Closure Near FPGA Maximum Resources

Jump to solution

Your best bet is to figure out how much timing margin you have at the LVDS inputs..  Spartan6 is not the easiest to use, compared with Artix, for example.   In your shoes,  I'd make sure that there was an IODELAY element in front of the ISERDES elements, and then I'd vary the timing to understand where the sampling is happening in the data eye.   I'll bet it's not centered, which is why you are seeing the occasional bit error.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Adventurer
Adventurer
977 Views
Registered: ‎05-27-2011

Re: Design and Timing Closure Near FPGA Maximum Resources

Jump to solution

Perfect,

 

Thank you very much.

 

Ed

0 Kudos
Adventurer
Adventurer
963 Views
Registered: ‎05-27-2011

Re: Design and Timing Closure Near FPGA Maximum Resources

Jump to solution

 

In the timing reports, it is difficult to find the value the tools have for the delay per tap. The select io user guide simply states this is in the timing portion of implementation. So far "taps", "delay", "IODELAY2" and the names of the actual input pins bring up no hits in the post PAR timing report. 

 

Does anyone have an idea where in the report the delay per tap is listed. 

 

Thanks,

Ed

0 Kudos