diff --git a/libtrellis/src/RoutingGraph.cpp b/libtrellis/src/RoutingGraph.cpp
index f7ca683..84eb625 100644
--- a/libtrellis/src/RoutingGraph.cpp
+++ b/libtrellis/src/RoutingGraph.cpp
@@ -154,14 +154,9 @@
 
   if (stripped_name.find("G_") == 0 || stripped_name.find("L_") == 0 || stripped_name.find("R_") == 0 ||
       stripped_name.find("U_") == 0 || stripped_name.find("D_") == 0 || stripped_name.find("BRANCH_") == 0) {
-      //size_t sub_idx = 0;
-
-      // if(stripped_name.find("BRANCH_") == 0) {
-      //     sub_idx = 7;
-      // } else {
-      //     sub_idx = 3;
-      // }
-
+      // Global prefix detected, use the prefix and row/col to map "logical"
+      // globals on a tile basis to physical globals which are shared between
+      // tiles.
       return find_machxo2_global_position(row, col, stripped_name);
   } else {
       RoutingId id;
@@ -294,20 +289,12 @@
     // until we can determine they only truly exist in center tile (the row,
     // col, and db_name will still be enough to distinguish them).
     if(strategy == GlobalType::CENTER) {
-        // XXX: This is a MachXO2-1200HC-specific hack; VPRXCLKI0's routing
-        // config bits are split across multiple tiles. Arcs do not store data
-        // about their tile position in the routing graph (as that's the DB's
-        // responsibility). Even so, we do _not_ want the same physical arc
-        // that appears in two tiles in the DB appearing twice in the routing
-        // graph. So for now, special-case and remove the second arc at
-        // (12, 9).
-        //
-        // If more than one arc has this problem, we may need to change this
-        // function signature to be device-specific, and find a better way to
-        // store this info along with the routing graph besides special-casing.
-        if((db_name.find("G_VPRXCLKI0") != string::npos) && row == 9 && col == 12)
-            return RoutingId();
-
+        // Some arcs, like those which connect to VPRXCLKI0 in the 1200HC part
+        // may appear more than once. We assume that open tools like nextpnr
+        // are able to tolerate the same physical arc appearing twice in the
+        // routing graph without any problems. This should also make bitstream
+        // generation easier if the open tools make sure to set an arc as used
+        // in each tile where it exists.
         curr_global.id = ident(db_name);
         curr_global.loc.x = center.second;
         curr_global.loc.y = center.first;