Fix RPT extraction on older targets

[UnsignedByte]

Older targets, such as the zynq 7020 have different table names for LUT counts, namely that they group LUTs by slice rather than CLB. Usually, the extraction script errors here as it is unable to find the right tables and rows.

The try catch method is sort of janky, maybe someone has a better idea?

Here is an example on the zynq:

1. Slice Logic
--------------

+----------------------------+-------+-------+-----------+-------+
|          Site Type         |  Used | Fixed | Available | Util% |
+----------------------------+-------+-------+-----------+-------+
| Slice LUTs                 | 48018 |     0 |     53200 | 90.26 |
|   LUT as Logic             | 45075 |     0 |     53200 | 84.73 |
|   LUT as Memory            |  2943 |     0 |     17400 | 16.91 |
|     LUT as Distributed RAM |     0 |     0 |           |       |
|     LUT as Shift Register  |  2943 |     0 |           |       |
| Slice Registers            | 70984 |     0 |    106400 | 66.71 |
|   Register as Flip Flop    | 70984 |     0 |    106400 | 66.71 |
|   Register as Latch        |     0 |     0 |    106400 |  0.00 |
| F7 Muxes                   |     0 |     0 |     26600 |  0.00 |
| F8 Muxes                   |     0 |     0 |     13300 |  0.00 |
+----------------------------+-------+-------+-----------+-------+

[rachitnigam]

I think we should do a couple bigger changes and separate out the synthesis and implementation (place&route) results into separate results.

{
  "synth": { ... },
  "place_and_route": { ... }
}

We should also describe different extract methods to extract information for different target boards (7-series, Ultrascale, Versal). If the user provides a particular part name, then we extract using that part. Otherwise we extract using all possible parts and leave it up to the user to decide which one to pick.

{
  "series7": { "synth": { ... }, ... },
  "ultrascale": { ... },
  "versal": { ... }
}

[UnsignedByte]

@rachitnigam What about the whole registers/muxes thing that is pulled from runme.log? Should we just drop it entirely? I really don't know what it is meant to measure. As a reminder, it takes the following information:

---------------------------------------------------------------------------------
Start RTL Component Statistics 
---------------------------------------------------------------------------------
Detailed RTL Component Info : 
+---Adders : 
	   3 Input   25 Bit       Adders := 148   
	   2 Input    9 Bit       Adders := 796   
	   3 Input    8 Bit       Adders := 296   
	   2 Input    8 Bit       Adders := 28    
	   2 Input    7 Bit       Adders := 2     
+---XORs : 
	   2 Input     32 Bit         XORs := 74    
+---Registers : 
	               48 Bit    Registers := 84    
	               32 Bit    Registers := 1356  
	               25 Bit    Registers := 148   
	               24 Bit    Registers := 1776  
	               23 Bit    Registers := 56    
	               18 Bit    Registers := 28    
	                9 Bit    Registers := 1056  
	                8 Bit    Registers := 824   
	                7 Bit    Registers := 2     
	                4 Bit    Registers := 148   
	                2 Bit    Registers := 148   
	                1 Bit    Registers := 3894

and adds all the numbers after :=.

[rachitnigam]

Yes, that seems nonsensical. Let's remove it. Can we commit a simplified RPT file to test the extraction of various numbers from impl and synth files while we're at it?