vtr-verilog-to-routing icon indicating copy to clipboard operation
vtr-verilog-to-routing copied to clipboard

Constant and inverter "replication" during packing

Open rs-dhow opened this issue 8 months ago • 2 comments

@KA7E and anyone else working on the packer.

First, I was happy to find: https://docs.verilogtorouting.org/en/latest/tutorials/arch/equivalent_sites/ We will use this feature.

Proposed Behavior

Currently, we don't implement programmable constants or inverters on special inputs (resets and enables). Instead, we make their unused values be all 1 so we can get away with routing only 1 as a constant. (And of course, LUTs don't need this.)

If we have a signal that directly drives e.g. some ENs on FFs, and through an inverter some other ENs on other FFs, we are interested in packing that SINGLE inverter into each block that wants it. This means the number of inverter atoms increases during packing. After the packing is done, if the original inverter is no longer driving anything, it would be dropped from the netlist. It would be best if the inverter comes from a .names in the netlist, not a special .subckt.

We looked into this 18 months ago but didn't figure it out. Maybe we were working on too much at the same time, and we didn't hear about someone else's solution to this. We could also expand some control-signal muxes to accept 1'b0 and 1'b1 and handle constant generators the same way as inverters above.

Current Behavior

Current behavior relies on using an explicit inverter, as well as explicit LUTs generating constants. The real cost is routing their outputs everywhere.

Possible Solution

We are wondering to what degree others have thought about replicating constant generators and inverters as described above. Doing this before the packer (in the netlist) doesn't make sense, since you don't know whether each consumption site is in the same block after packing or not.

Context

Local replication of constant generators and inverters would eliminate at least one dense wire that must route everywhere currently, and more in some cases. This wire doesn't respond well to typical congestion mitigation approaches either since it can be so dense.

Thanks.

rs-dhow avatar Jun 11 '24 23:06 rs-dhow