Improve support for contant generators

[kmurray]

Expected Behavior

If supported by the target architecture, VPR should make use of programmable pins which can be tied to vcc/gnd to specify constants.

Current Behavior

Currently VPR treats nets named 'vcc' and 'gnd' as a special case, treating them as global nets in the CLB netlist, which causes them not to be routed. The constant LUT driver from the BLIF remains in the netlist.

This is an inaccurate (since the nets are not routed) and fragile workaround (since it does not handle constants not named 'vcc' or 'gnd).

Possible Solution

1. Extend the architecture description to support specifying pins which can be tied to vcc/gnd. For example as an attribute on a pin (e.g. tieable):

   <pb_type name="clb" area="53894">
      <input name="I" num_pins="40" equivalent="true" tieable="vcc,gnd"/>
      ....
  </pb_type>

2. Update the packer to make use of tie-able pins when connecting to constants in side a logic block
3. Since not all (or perhaps any) pins in an architecture may be tie-able, some pins will need to be connected to a constant driver (e.g. constant LUT) via a routed net.
4. As a further optimization we could consider making use of unused (but tie-able) pins in place of constant LUTs. It may also be possible to transform the single-source/multi-sink routing into a multi-source/multi-sink routing which could be more efficient (but may break some of the router's internal assumptions).

[kmurray]

As an update VPR no longer treats vcc and gnd nets specially, but simply detects them as constant nets.

292 added support for controlling whether VPR routes constant nets or not.

However the long-term solution of describing tie-able pins in the architecture and making use of them remains open.

[litghost]

I believe solving the VCC/GND in the packer is insufficient for the general case. In the case of the 7-series routable VCC and GND signals enter a routing node that can support a constant signal or can route high fanout non-constant signals. In the case of the 7-series constant support there are two "types" of constant signals supported:

1. Routable constants sources. These sources are available in the routing network, and I believe should they should not require packing or placement. These are pure routing resources.
2. pb_type internal constant sources. These could be modeled as tieable signals

I believe support for both is required. Thoughts?

[kmurray]

I can envision 3 potential ways to handle constant nets:

1. A LUT which generates a constant 1/0, whose output is routed wherever that constant is needed. This is currently supported by vpr (if --constant_net_method route is specified). I believe this is the most general solution, since it doesn't put any requirements on the architecture supporting tie-offs. (Of course from an implementation quality perspective this is likely sub-optimal if the architecture does have tie-offs.)

2. There are dedicated constant generators embedded in the routing network. It would make sense to model these as SOURCEs in the RR graph. I agree they wouldn't need to be packed/placed, just special cased within the router. To support this would require:

   • Some method to identify which SOURCEs are actually constant generators, and what value they generate.
   • Special logic in the router to pick appropriate SOURCE(s) when routing a constant net.
   • There are also potential further optimizations including: multi-source routing, combined routing/merging of constant nets driving the same value.

3. There are dedicated constant generators embedded within the blocks. These could be modelled the same way as (2), but within the pb_type rr graph. Currently there is neither support for modelling these (e.g. a tieable='vcc,gnd' attribute), nor for using them in the intra-cluster router.

I believe solving the VCC/GND in the packer is insufficient for the general case.

I agree that modelling tie-offs solely within the packer is likely insufficient. However with (1) I believe we cover the general case**, and methods (2) and (3) are simply optimizations aimed at reducing wirelength.

Depending exactly whether an architecture supports (2) or (3) there may be some optimizations which are possible/not possible. For instance, if there is a dedicated tie-off in the RR graph, but no block-internal tie-offs, the external source could be used to route the constant into all the blocks which need it -- meaning the dedicated constant LUT used by (1) would be redundant.

However these are pretty small details which likely just don't matter very much, so it may not be worth the time to support/exploit them fully.

** Making reasonable assumptions, like a fully connected routing network where a LUT output is routable to any other pin in the device.

[litghost]

methods (2) and (3) are simply optimizations aimed at reducing wirelength

Sure, but they are potentially significant, as VPR currently only emits one constant LUT and then proceeds to route that constant throughout the network. I don't have numbers on me but in the example I was looking it, it consumed at least one routing resource in basically every column of the interconnect network.

[litghost]

For instance, if there is a dedicated tie-off in the RR graph, but no block-internal tie-offs, the external source could be used to route the constant into all the blocks which need it -- meaning the dedicated constant LUT used by (1) would be redundant.

That is what the 7-series arch supports, and yes, the constant LUT would become redundant.