Logic Block Pin Mapping should Synchronize with Post-Packing/Routing Results

[tangxifan]

1. When users define equivalent pins in architecture, such as
   <input name="I" num_pins="10" equivalent="full"/>,
   VPR's router is allowed to swap the nets that are mapped to these pins during packing stage.
   This enables more optimization space for routers, when resolving routing congestion and also for tight timing constraints.

However, when routing is finished, the swapped nets will mismatch the packing results, potentially leading to wrong bitstream generation or timing analyses.
To avoid this bug, users may not define equivalent pins, which limits the QoR of VPR.

2. VPR's packer is allowed to swap the nets that are mapped to LUT inputs during packing.
   This will cause the truth tables of the LUT from original netlist to mismatch the packed LUTs, when doing post-routing simulation

Proposed Behaviour

1. After routing is done, we should synchronize the routing results into the packing results.
   During this stage, the swapped nets should be annotated in the packing results.

2. After packing is done, we should consider the swapped nets and fix-up/adapt truth tables.

Current Behaviour

None of such synchronization has been done currently.

Possible Solution

This fix-up has been done in the OpenFPGA framework.
Source codes are available at post-routing fix-up

and post-packing fix-up

The swapped nets are annotated in a separate database than the VPR's PackerContext.

Two pull requests can be made to merge this effort from OpenFPGA to VPR, one for the post-routing fix-up and the other for the post-packing fix-up.

I would like to learn advice from VPR developers on the following aspects:

• When to call this fix-up function? Currently, it is executed after routing is completed in OpenFPGA.

• Should we overwrite the PackerContext when synchronizing?
  For LUT truth tables, I would suggest keeping the original data while creating a new database.
  For pin swapping during routing, I would suggest fix on the PackerContext directly.

• We will test this feature to ensure a correct fix-up?

  • Output in blif and run ABC formal verification: does vtr_flow script support this?
  • Could also simulate output .v in an HDL simulator. If it has hard blocks, you’d need to write or link in simulation models for those hard blocks.
    For HDL simulator, we can use the iVerilog in CI. But, iVerilog runtime will be very long for large benchmarks, we may only consider small benchmarks in this case.
  • Test cases should include
    (i) LUTs rotated by clustered,
    (ii) logically equivalent pins changed by router (e.g. due to within block crossbars) and (iii) LUT rotation by router (because LUT pins are directly connected to cluster inputs and are equivalent). (i) and
    (ii) would be tested by many VTR architectures, including most commonly used architecture while (iii) would be tested by Artix7 symbiflow, or possibly a Lattice-style architecture which models a Lattice-style architecture. The lattice-style architecture for
    (iii) might need some more info added to show that the pin equivalence is due to LUT equivalence though (rather than small crossbars) so we may need some more architecture syntax to make it clear the LUT truth tables should be fixed up to deal with input rotation.

Once these are clear, I should be able to create a pull request very quickly.

Context

This issue will cause wrong bitstreams to be generated.

[github-actions]

This issue has been inactive for a year and has been marked as stale. It will be closed in 15 days if it continues to be stale. If you believe this is still an issue, please add a comment.

[github-actions]

This issue has been marked stale for 15 days and has been automatically closed.