[CI] Added Quick Titanium S10 Tests

[AlexandreSinger]

The titanium benchmarks were not being tested by the CI. Added the Titanium benchmarks which could be run in under around 2 hours to NightlyTest7.

5 circuits in this benchmark set currently fail through VTR. The failures are mainly in the initial placer, which is struggling to create an initial placement when logical blocks can be placed into different physical block types which are constrained resources.

[AlexandreSinger]

@vaughnbetz I have added the working Titanium circuits to NightlyTest7 with this PR. I will raise an issue on the failing tests. I found that the failing tests were, in fact, running 2 iterations of the initial placer (which is correct). I think the issue with the initial placer is that the logical blocks which can be placed in either LABs or MLABs may be placed too early and are taking the resources of logical blocks which must be placed in LAB tiles or must be placed in MLAB tiles.

[vaughnbetz]

Thanks @AlexandreSinger ! Is this with an auto sized device? If so, it is strange. @amin1377 : I think you landed some initial placement changes a while ago. Do blocks eventually do an exhaustive search?

[AlexandreSinger]

Thanks @AlexandreSinger ! Is this with an auto sized device? If so, it is strange. @amin1377 : I think you landed some initial placement changes a while ago. Do blocks eventually do an exhaustive search?

Hi Vaughn, yes, this is with an auto-sized device. I raised an issue on this topic which provides a bit more information: #3105

I think a "simple" solution would be to place the logical blocks which can only be placed in one and only one physical tile first (since they are more constrained), and then placing the more free logical blocks second. We could add a third iteration of the initial placer which does this, which would prevent this update from affecting other benchmarks. Initial Placement is quite quick, so running 3 iterations of it is not crazy in my opinion.

[amin1377]

@vaughnbetz: You’re right; if centroid placement fails, it will eventually fall back to an exhaustive search to find a location for the blocks.

I'm not sure if this is related to what Alex is observing, but I recall that Sara encountered a similar issue two years ago. In her case, it was caused by DSP chains: although the number of resources was sufficient, the column height had to be increased beyond what seemed necessary in order to fit the chains properly.

[vaughnbetz]

@AlexandreSinger : your proposed fix makes sense to me. Here's a tweak that could also help: detect what kind of block failed to place and move it to the front in later iterations (we already detect blocks that failed, but we could generalize that to put blocks that failed to place first in the second iteration, and block types that failed right after the blocks that failed). We should also check that those terms swamp any "connected to placed blocks" terms so they dominate in later iterations. Anybody want to try coding a fix?

[vaughnbetz]

LGTM