Open kmurray opened 7 years ago
As an update VPR no longer treats vcc
and gnd
nets specially, but simply detects them as constant nets.
However the long-term solution of describing tie-able pins in the architecture and making use of them remains open.
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:
I believe support for both is required. Thoughts?
I can envision 3 potential ways to handle constant nets:
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.)
There are dedicated constant generators embedded in the routing network.
It would make sense to model these as SOURCE
s 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:
SOURCE
s are actually constant generators, and what value they generate.SOURCE
(s) when routing a constant net.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.
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.
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.
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
tieable
):