In xilinx/arch.cc, Arch::place() sets cfg.alpha, cfg.beta and cfg.criticalityExponent by hand right after constructing PlacerHeapCfg:
PlacerHeapCfg cfg(getCtx());
cfg.criticalityExponent = 7;
...
cfg.alpha = 0.08;
cfg.beta = 0.4;
The constructor has already read those same three values out of ctx->settings (common/placer_heap.cc, around line 1980):
alpha = ctx->setting<float>("placerHeap/alpha", 0.1);
beta = ctx->setting<float>("placerHeap/beta", 0.9);
criticalityExponent = ctx->setting<int>("placerHeap/criticalityExponent", 2);So anything that sets placerHeap/alpha, placerHeap/beta or placerHeap/criticalityExponent has no effect on this arch. The values are read, then overwritten a few lines later.
The NEXTPNR_PLACER_BETA / NEXTPNR_PLACER_ALPHA env vars further down do work, because they are applied after the hardcoded assignments. But they are undocumented and arch-specific, and they don't help anyone setting the values through the settings dict.
Checked against 918060f.
Suggested fix
Only apply the arch defaults when the setting wasn't supplied:
if (!ctx->settings.count(ctx->id("placerHeap/alpha")))
cfg.alpha = 0.08;
if (!ctx->settings.count(ctx->id("placerHeap/beta")))
cfg.beta = 0.4;and the same for criticalityExponent.
Why it matters
beta is the cut-spreader's density target, and it makes a real difference to routability on congested designs. Lowering it spreads cells further and leaves more free bels and routing tracks per region. Tuning it through settings looks like it works and quietly does nothing, so experiments come back with plausible results that all used the same value.
In
xilinx/arch.cc,Arch::place()setscfg.alpha,cfg.betaandcfg.criticalityExponentby hand right after constructingPlacerHeapCfg:The constructor has already read those same three values out of
ctx->settings(common/placer_heap.cc, around line 1980):So anything that sets
placerHeap/alpha,placerHeap/betaorplacerHeap/criticalityExponenthas no effect on this arch. The values are read, then overwritten a few lines later.The
NEXTPNR_PLACER_BETA/NEXTPNR_PLACER_ALPHAenv vars further down do work, because they are applied after the hardcoded assignments. But they are undocumented and arch-specific, and they don't help anyone setting the values through the settings dict.Checked against 918060f.
Suggested fix
Only apply the arch defaults when the setting wasn't supplied:
and the same for
criticalityExponent.Why it matters
betais the cut-spreader's density target, and it makes a real difference to routability on congested designs. Lowering it spreads cells further and leaves more free bels and routing tracks per region. Tuning it through settings looks like it works and quietly does nothing, so experiments come back with plausible results that all used the same value.