cbx/cby muxes lose inputs if they are on same "index"

[rs-dhow]

Under vtr... there is a file rr_gsb.cpp which has the function calls sort_chan_node_in_edges(3 args) and sort_ipin_node_in_edges(3 args).

Both have an initial loop which collects in-edges into a std::map, then a second loop which steps (in sorted order) through the result.

The former uses
std::map<size_t, std::map<size_t, RREdgeId>> from_grid_edge_map;
std::map<size_t, std::map<size_t, RREdgeId>> from_track_edge_map;
which express "side --> index --> edge" and appear to properly implement the order in the comments.

The latter uses
std::map<size_t, RREdgeId> from_track_edge_map;
which expresses "index --> edge". This is NOT side-dependent.

If appears that if a CB has multiple inputs, from different sides, but all with the same track index, then the last one enumerated will overwrite the others and those overwritten others will not drive the CB in the netlist. This appears to happen in a corner IO tile (i.e. x=1 and y=1) using a read-in routing graph.

The comments for the latter function claim the same behavior as the first function, but the latter has a simpler key.

Due to the maps and how the loops work, the first function acts like a three-part key: "side then pin vs track then index". This matches its comments.

The second function seems to have "index" only as a key. If this could be extended to "index then side" that would be great. Even better would be "index then side then pin/track". For compatibility with previous behavior, it's fine to keep index first, unlike the first function.

Thanks

To Reproduce
Steps to reproduce the behavior:

1. Clone OpenFPGA repository and checkout commit id:
2. Execute OpenFPGA task or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.