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
Observer azad.jalali
Observer
1,240 Views
Registered: ‎10-26-2017

Spartan 6 - Map significantly slower after package change and pin swaps

Jump to solution

Hi,

 

I've inherited a fairly congested design in a CPG196 package (the smallest package at 8x8 mm), which formerly took 6 minutes to map. I've since designed a new version of the board that uses the larger CPG225 package (13x13 mm), mainly to reduce our PCB complexity. In doing so, we also swapped much of the IO around to ease routing. What has me confused is that Map takes 30 minutes for the larger package with the new pin locations, up from 6.

 

What's especially puzzling is that the FPGA is the same logic size (XC6SLX16). I would understand if PAR were significantly affected by package size and pin locations, but I would expect Map time to mostly depend on the resources available on the FPGA. Thinking that maybe there was an issue with my pin locations, I tried removing all of my LOC constraints, but it didn't seem to make a difference.

 

Is there some other factor at play that would make Map slower on a larger package, but same FPGA? The whole map process is pretty opaque so I'm at a loss at how to troubleshoot this.

 

Thanks,

Azad

0 Kudos
1 Solution

Accepted Solutions
Observer azad.jalali
Observer
1,570 Views
Registered: ‎10-26-2017

Re: Spartan 6 - Map significantly slower after package change and pin swaps

Jump to solution

Turns out this was a false alarm. The change in package coincided with me buying a new laptop. For some reason on this new laptop 64-bit ISE takes 30 minutes to map while 32-bit ISE runs at the speed I'm used to (actually it's down to 3 minutes now because of all the SmartXplorer optimizations I did!). That raises it's own questions but for now I'm just happy to have found a workaround.

0 Kudos
6 Replies
Observer azad.jalali
Observer
1,230 Views
Registered: ‎10-26-2017

Re: Spartan 6 - Map significantly slower after package change and pin swaps

Jump to solution

If it helps, the majority of compilation time occurs during Phase 1.1 Initial Placement Analysis (15 min) and Phase 5.36 Local Placement Optimization (6 min). Also here's the utilization report:

Slice Logic Utilization:
  Number of Slice Registers:                 7,344 out of  18,224   40%
    Number used as Flip Flops:               7,319
    Number used as Latches:                      9
    Number used as Latch-thrus:                  0
    Number used as AND/OR logics:               16
  Number of Slice LUTs:                      6,550 out of   9,112   71%
    Number used as logic:                    4,387 out of   9,112   48%
      Number using O6 output only:           2,896
      Number using O5 output only:             224
      Number using O5 and O6:                1,267
      Number used as ROM:                        0
    Number used as Memory:                     270 out of   2,176   12%
      Number used as Dual Port RAM:             12
        Number using O6 output only:             0
        Number using O5 output only:             0
        Number using O5 and O6:                 12
      Number used as Single Port RAM:          256
        Number using O6 output only:           256
        Number using O5 output only:             0
        Number using O5 and O6:                  0
      Number used as Shift Register:             2
        Number using O6 output only:             2
        Number using O5 output only:             0
        Number using O5 and O6:                  0
    Number used exclusively as route-thrus:  1,893
      Number with same-slice register load:  1,832
      Number with same-slice carry load:        61
      Number with other load:                    0

Slice Logic Distribution:
  Number of occupied Slices:                 1,914 out of   2,278   84%
  Number of MUXCYs used:                     2,144 out of   4,556   47%
  Number of LUT Flip Flop pairs used:        6,729
    Number with an unused Flip Flop:         1,781 out of   6,729   26%
    Number with an unused LUT:                 179 out of   6,729    2%
    Number of fully used LUT-FF pairs:       4,769 out of   6,729   70%
    Number of unique control sets:             308
    Number of slice register sites lost
      to control set restrictions:             838 out of  18,224    4%

  A LUT Flip Flop pair for this architecture represents one LUT paired with
  one Flip Flop within a slice.  A control set is a unique combination of
  clock, reset, set, and enable signals for a registered element.
  The Slice Logic Distribution report is not meaningful if the design is
  over-mapped for a non-slice resource or if Placement fails.

IO Utilization:
  Number of bonded IOBs:                        75 out of     160   46%
    IOB Flip Flops:                             45

Specific Feature Utilization:
  Number of RAMB16BWERs:                         2 out of      32    6%
  Number of RAMB8BWERs:                          1 out of      64    1%
  Number of BUFIO2/BUFIO2_2CLKs:                 1 out of      32    3%
    Number used as BUFIO2s:                      1
    Number used as BUFIO2_2CLKs:                 0
  Number of BUFIO2FB/BUFIO2FB_2CLKs:             1 out of      32    3%
    Number used as BUFIO2FBs:                    1
    Number used as BUFIO2FB_2CLKs:               0
  Number of BUFG/BUFGMUXs:                       7 out of      16   43%
    Number used as BUFGs:                        6
    Number used as BUFGMUX:                      1
  Number of DCM/DCM_CLKGENs:                     2 out of       4   50%
    Number used as DCMs:                         2
    Number used as DCM_CLKGENs:                  0
  Number of ILOGIC2/ISERDES2s:                   4 out of     248    1%
    Number used as ILOGIC2s:                     4
    Number used as ISERDES2s:                    0
  Number of IODELAY2/IODRP2/IODRP2_MCBs:         0 out of     248    0%
  Number of OLOGIC2/OSERDES2s:                  40 out of     248   16%
    Number used as OLOGIC2s:                    40
    Number used as OSERDES2s:                    0
  Number of BSCANs:                              0 out of       4    0%
  Number of BUFHs:                               0 out of     128    0%
  Number of BUFPLLs:                             0 out of       8    0%
  Number of BUFPLL_MCBs:                         0 out of       4    0%
  Number of DSP48A1s:                           16 out of      32   50%
  Number of ICAPs:                               0 out of       1    0%
  Number of MCBs:                                0 out of       2    0%
  Number of PCILOGICSEs:                         0 out of       2    0%
  Number of PLL_ADVs:                            0 out of       2    0%
  Number of PMVs:                                0 out of       1    0%
  Number of STARTUPs:                            0 out of       1    0%
  Number of SUSPEND_SYNCs:                       0 out of       1    0%

Average Fanout of Non-Clock Nets:                2.66

 

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

Re: Spartan 6 - Map significantly slower after package change and pin swaps

Jump to solution

Look for differences in your timing constraints between the two designs..   Timing constraints can have a huge affect on the run time.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Observer azad.jalali
Observer
1,206 Views
Registered: ‎10-26-2017

Re: Spartan 6 - Map significantly slower after package change and pin swaps

Jump to solution

Hi @jmcclusk,

 

There are no differences in timing constraints. I used the same .ucf, just with the pin LOC constraints changed and then eventually removed.

 

I also tried setting Map to ignore timing requirements and saw no difference. I've been playing with this all day and it's starting to look like there is something inherent about the package size being bigger that is causing this 5x increase in Map time.

 

One thing I still haven't tried is missing with the starting placer cost table. Maybe another value would be more optimal for this different package. I'll have SmartXplorer try this.

0 Kudos
Moderator
Moderator
1,158 Views
Registered: ‎01-16-2013

Re: Spartan 6 - Map significantly slower after package change and pin swaps

Jump to solution

@azad.jalali,

 

Have you tried smarXplorer? Also please compare the timing results between two runs.

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Observer azad.jalali
Observer
1,152 Views
Registered: ‎10-26-2017

Re: Spartan 6 - Map significantly slower after package change and pin swaps

Jump to solution

Hi @syedz,

 

Yes, I've tried two experiments with SmartXplorer. Last week I ran it to search for a congestion strategy but it turned out my current settings were already optimal (I went through this exercise previously when working with the original part to get the map down to 6 minutes). Every other run took 15hours+!

 

I then ran the starting cost table iteration over the weekend. None of the runs stood out as particularly fast or slow.

 

As for timing, I'm able to meet timing on all runs. PAR takes about a minute regardless of my map settings. The design runs at 20 MHz so it's pretty trivial to place and route on a -2 part. Additionally, as I mentioned before, when I instruct Map to ignore timing constraints it doesn't get any faster.

 

Thanks,

Azad

0 Kudos
Observer azad.jalali
Observer
1,571 Views
Registered: ‎10-26-2017

Re: Spartan 6 - Map significantly slower after package change and pin swaps

Jump to solution

Turns out this was a false alarm. The change in package coincided with me buying a new laptop. For some reason on this new laptop 64-bit ISE takes 30 minutes to map while 32-bit ISE runs at the speed I'm used to (actually it's down to 3 minutes now because of all the SmartXplorer optimizations I did!). That raises it's own questions but for now I'm just happy to have found a workaround.

0 Kudos