[AP] Unable to Pack sparcT1_chip2_stratixiv_arch_timing Benchmark with Fixed IO Due to IO Block Overutilization

[haydar-c]

While running Titan benchmarks with fixed IO constraints, the sparcT1_chip2_stratixiv_arch_timing benchmark fails to pack due to high utilization of IO blocks.

The target utilization for all blocks is 1.00, but the actual utilization reaches 1.02 during the first packing iteration. With increased exploration using cluster attraction groups, the utilization drops slightly to 1.01, but never reaches the target. Packing halts after iteration 4 without success.

The log of packing iterations:

Packing with pin utilization targets: io:1,1 PLL:1,1 LAB:0.8,0.6 DSP:1,1 M9K:1,1 M144K:1,1
Packing with high fanout thresholds: io:128 PLL:128 LAB:32 DSP:128 M9K:128 M144K:128
    Block Utilization: 1.02 Type: io

Floorplan regions are overfull: trying to pack again using cluster attraction groups. 
0 clustering attraction groups created. 
    Block Utilization: 1.02 Type: io

Floorplan regions are overfull: trying to pack again with more attraction groups exploration. 
0 clustering attraction groups created. 
Pack iteration is 2
    Block Utilization: 1.02 Type: io

1891 clustering attraction groups created. 
Floorplan regions are overfull: trying to pack again with more attraction groups exploration. 
Pack iteration is 3
    Block Utilization: 1.01 Type: io

1891 clustering attraction groups created. 
Floorplan regions are overfull: trying to pack again with more attraction groups exploration and higher target pin utilization. 
Pack iteration is 4
    Block Utilization: 1.01 Type: io

Message: Failed to find device which satisfies resource requirements required: io: 2061, LAB: 32435, DSP: 3, M9K: 504 (available io: 2032, LAB: 58860, DSP: 432, M9K: 2398)

Possible Solution

After discussing with @AlexandreSinger, one potential solution is to attenuate the gain for IO blocks separately during candidate selection. Another idea is to avoid dropping IO candidates based on distance, similar to how APPack currently treats RAM blocks, to prevent too many RAM block creation.

[AlexandreSinger]

@haydar-c Thank you so much for flagging this! This is a long standing issue with APPack in that very sparse blocks tend to increase in utilization when the max candidate distance threshold is used. For now, I have used a hand-tuned number to select the distance threshold, but this is not a very safe approach.

My plan is to create a command-line interface to allow the user to select the max candidate distance threshold and, if none are selected, it will allow VPR to select "good" numbers; where good numbers will likely be a function of the sparsity of the logical block and the size of the device.