I added a -part partName option to tincr::write_rscp and tincr::write_design info. In my partial device project (where I create a device file that is only contains the tiles of a reconfigurable partition of a design), I create new device files that aren't standard part names. In order for RS2 to know what device file to use, it looks at the part identifier in the design.info in generated RSCPs. This option allows you to manually specify the part name when creating an rscp. If no part name is specified, the part is obtained from the design as normal.
When working with out-of-context designs, it is possible to have nets where the source of the net is a hierarchical port (placed or unplaced port with no driver). Vivado does not allow you to set the route strings for these nets and gives a warning similar to this:
"WARNING: [Designutils 20-949] No driver found on net led[0]"
The net is then left partially routed. As a workaround, I find nets with hierarchical source ports and have Vivado route them. This is also what was done for differential pair nets. Ideally, we wouldn't have to do this, but I know of no other solution at the moment.
There are 2 parts to this PR.
I added a -part partName option to tincr::write_rscp and tincr::write_design info. In my partial device project (where I create a device file that is only contains the tiles of a reconfigurable partition of a design), I create new device files that aren't standard part names. In order for RS2 to know what device file to use, it looks at the part identifier in the design.info in generated RSCPs. This option allows you to manually specify the part name when creating an rscp. If no part name is specified, the part is obtained from the design as normal.
When working with out-of-context designs, it is possible to have nets where the source of the net is a hierarchical port (placed or unplaced port with no driver). Vivado does not allow you to set the route strings for these nets and gives a warning similar to this:
"WARNING: [Designutils 20-949] No driver found on net led[0]"
The net is then left partially routed. As a workaround, I find nets with hierarchical source ports and have Vivado route them. This is also what was done for differential pair nets. Ideally, we wouldn't have to do this, but I know of no other solution at the moment.