Fc_override Not Parsed Correctly

[WhiteNinjaZ]

The Fc override feature in vtr does not seem to be parsed when it comes to specifying ports:

1. There does not seem to be any kind of parsing on the fc_override port_overide specification. Whatever is in the string after port_name= is just taken in its raw form. For example, if the same format (i.e. multiple ports specified in a single line by separating them with spaces "clb.I clb.O clb.cin") is used in this child tag then the full list is taken to be a single port name (i.e. "clb.I clb.O clb.cin" is passed in) instead of a vector of different port names.
2. If you look at read_xml_arch_file.cpp lines 1958-1962 we see that the following if statement determines when an override should be applied:

   if (fc_override.port_name == port.name && fc_override.seg_name == segments[iseg].name) {
                           apply_override = true;
                       }

   The problem is that the port names must match exactly and there is no error checking in this if/else statement. So, if someone were to use the pretty standard way of specifying the override port as <name of tile>.<name of port> (i.e. "clb.I") the override is just ignored--no error, no warning, just flat out ignored. This also happens if a port that does not exist is specified in the fc_overide or if specific subsets of a certain port are used (i.e. clb.I[23:0]). I think this is mostly caused by the upstream parser just not doing proper error checking/parsing on the fc_override port parameter. As mentioned in the last point, whatever is in the string immediately following port_name= is just taken in its raw form.

   Expected Behaviour

   There should be proper error checking and parsing for the fc_override feature. The standard method for specifying a list of port names as well as single port names should also be followed.

[rs-dhow]

Joshua: thanks for pursuing this. We noticed as well that fc_override's weren't handled properly leading to significant extra routing resources (adding muxes for things meant to be internal or only one direction on IO slots). We never pursued this problem in detail since we switched to reading in external routing graphs, which bypasses the fc_override path to the routing generator.