lutpack: warn when the installed LUT library is narrower than the network - #557
Open
marcelwa wants to merge 1 commit into
Open
lutpack: warn when the installed LUT library is narrower than the network#557marcelwa wants to merge 1 commit into
marcelwa wants to merge 1 commit into
Conversation
…work `Lpk_Resynthesize` takes the LUT width from `Abc_FrameReadLibLut()` when a library is installed, and falls back to the network's max fanin count only when none is. `If_Init()` installs a 4-input library at start-up and never removes it, so the fallback is unreachable in practice and plain `lutpack` packs a 6-LUT netlist for 4 inputs, which barely moves it. On EPFL mem_ctrl mapped with `if -K 6`, `lutpack` alone goes 12104 -> 12069 nodes; after `read_lut` of a 6-input library it goes 12104 -> 11494. Print a warning when the library width is below the network's max fanin count, so the mismatch is at least visible.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
lutpack's own usage text says it "determines LUT size as the max fanin count of a node", butLpk_Resynthesizeonly does that in theelsebranch, when no LUT library is installed, andIf_Init()installs a 4-input library at start-up and nothing removes it — so in a normal session the fallback is unreachable and plainlutpackalways packs for 4 inputs, which on a 6-LUT netlist is close to a no-op. On EPFLmem_ctrlmapped withstrash; if -K 6,lutpackalone goes 12104 -> 12069 nodes, while the same command afterread_lutof a 6-input library goes 12104 -> 11494; across 31 benchmarks the stock default changed the LUT count on 2 of 31 fresh mappings, against 15 of 31 and geomean -2.39% (Wilcoxon p = 6.2e-4) when the width is set to 6, and it regressed neither LUT count nor levels anywhere. So the question is whether the 4-input default is intended — plausibly it is, as a legacy of the 4-LUT era, in which case the usage text is what is out of date. This patch is the smallest thing we could think of that makes the mismatch visible: one warning when the installed library is narrower than the network's max fanin count, no change to any result. The alternative we considered and did not propose is defaulting the width to the network's max fanin count, which is what the usage text already promises but would change everybody's numbers; if you would rather have that, or a line in the help text instead, we are happy to redo it. This is orthogonal to #542 — that one is aboutlutpackproducing a non-equivalent netlist, and this change only prints.