Parallelize Router Preprocessing

[abutt-amd]

For some large designs router preprocessing takes longer than actually routing the design. This PR parallelizes the bottlenecks of router preprocessing where possible. Before these changes preprocess takes 243 seconds on a design that nearly fills 2 SLRs on the V80, and after these changes preprocess takes 74 seconds (a 3.3x speedup). Performance comparison run on my VDI with 8 threads.

[clavin-xlnx]

Thanks for improving this! Looks like there might be some regression failures you'll need to sort out.

[abutt-amd]

This is passing test cases locally but is now dependent on an update to the rapidwright api.

[abutt-amd]

Ok I think this should be in a reasonable place now. There's definitely some more performance that could be squeezed out by adding thread-safe APIs to design and net instead of the coarse grain synchronization I have now but experimentally this seems to only create a few seconds of overhead at most. Combined with a few additional optimizations the total runtime is now around 65-70s (~3.5x speedup).

[clavin-xlnx]

I've looked over the code and don't have any major comments. But I think I will defer to @eddieh-xlnx as I think he might be able to provide more substantial feedback on the parallelization techniques.

[eddieh-xlnx]

Look at using computeIfAbsent here. Otherwise, you're doing 4 lookups.

[eddieh-xlnx]

Actually, can you convince me that Map<EDIFHierPortInst, Cell> cellCache adds anything here? Since you're iterating over physPins, is it expected that you will ever lookup one of those pins more than once?

I could maybe see value in Map<EDIFHierCellInst, Cell>, but even then, how often does the same pin connect to the same cell? I'd need to see some data.

[eddieh-xlnx]

1. Why do you need to synchronize on the cell here? I don't think any pin mappings need to be modified in this method, nor do cells need to be created.
2. Why is it necessary to lookup the cell again here?

[eddieh-xlnx]

joinFirst() is for when you want to get the result from the first Future that completes so that it can be operated on. You want this instead:

Suggested change

	while (!futures.isEmpty()) {
	ParallelismTools.joinFirst(futures);
	}
	ParallelismTools.join(futures);

[eddieh-xlnx]

You'll probably need to change futures to a List too.

[eddieh-xlnx]

I'm not convinced this is necessary. My quick take is that this Map is only used by each Net (i.e. createMissingSitePinInsts(Design, Net, ...), getRoutedSitePinFromPhysicalPin(Cell, Net, ...), getAllRoutedSitePinsFromPhysicalPin(Cell, Net, ...)) which indicates to me that a global map (keyed on SiteInst) is not the best thing to do.

[eddieh-xlnx]

Depending on how many things you have to rename (admittedly, there shouldn't be many), this might be quite slow as you're essentially enforcing an atomic section here on the design singleton. It's likely better to save everything you need to rename into a concurrent collection (e.g. ConcurrentLinkedQueue) so that the actual renaming can happen outside of the parallel section.

Same for the movePinstToNewNetDeleteOldNet() call below.