add flat idx to pb_graph_node , populate in alloc_and_load_pb_graph

KA7E commented 3 weeks ago

Added a flat_site_idx to pb_graph_node struct, along with code to populate it in alloc_and_load_pb_graph.

Description

As alloc_and_load_pb_graph builds the graph from the top down, each parent computes its child's flat index and passes it to them as an argument to alloc_and_load_ph_graph.
The child's flat site is computed by the parent as: (parent's flat site)*(total children of this type) + child's sibling index.

Related Issue

Motivation and Context

This is used to help the legalizer place a molecule on a user specified site. It is better to store this value in the node than to recompute it over and over.

How Has This Been Tested?

Compared this value to locally computed value in the legalizer, which is then printed to a flat placement file and compared via a script. I tested on both StratixIV and ISPD Ultrascale architectures. In all cases, computed sites and sites stored in the pb_graph_node match.

Types of changes

[ ] Bug fix (change which fixes an issue)
[ ] New feature (change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] All new and existing tests passed

KA7E commented 3 weeks ago

@vaughnbetz could you please review? Subsequent legalizer PRs depend on this.

KA7E commented 2 weeks ago

QoR check running neuron:

Master VPR: BB estimate of min-dist (placement) wire length: 609607 Placement estimated critical path delay (least slack): 7.36338 ns Total wirelength: 778820, average net length: 15.3064 Final critical path delay (least slack): 7.63097 ns The entire flow of VPR took 603.12 seconds (max_rss 2827.0 MiB)

Master VPR with legalizer-related modifications (this PR and others): BB estimate of min-dist (placement) wire length: 609607 Placement estimated critical path delay (least slack): 7.36338 ns Total wirelength: 778820, average net length: 15.3064 Final critical path delay (least slack): 7.63097 ns
The entire flow of VPR took 547.78 seconds (max_rss 2825.2 MiB)

vaughnbetz commented 2 weeks ago

Thanks, that looks good. It's odd cpu time sped up by about 10%; probably a load issue I guess.

KA7E commented 2 weeks ago

The modified version was compiling while the baseline was running, but nothing else was happening while the modified version was running. I thought I had enough resources that this wouldn't matter, but maybe it impacted the runtime.

vaughnbetz commented 2 weeks ago

CPUs throttle pretty aggressively now; if it's a laptop cpu it probably changes the voltage and clock frequency if more than one core is running.

On Wed, Jun 12, 2024 at 10:55 AM KA7E @.***> wrote:

The modified version was compiling while the baseline was running, but nothing else was happening while the modified version was running. I thought I had enough resources that this wouldn't matter, but maybe it impacted the runtime.

— Reply to this email directly, view it on GitHub https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/2590#issuecomment-2163252082, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNDPJ72FAPUMM2QBESDERDZHBOMJAVCNFSM6AAAAABI3WPLZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGI2TEMBYGI . You are receiving this because you modified the open/close state.Message ID: <verilog-to-routing/vtr-verilog-to-routing/pull/2590/c2163252082@ github.com>

KA7E commented 2 weeks ago

It is not a laptop, it's a repurposed gaming server (that I like to use so I can control what else is running). If runtime is a concern I'm happy to re-run each all alone.

vaughnbetz commented 2 weeks ago

I think it's OK ... the odds were low of a slowdown and this pushes them lower still.

verilog-to-routing / vtr-verilog-to-routing