TEF128 routes fine; what failed was my own -nodsp constraint

[gHashTag]

I reported TEF128 as not converging in routing and put that in the limitations as a property of the rung.

It is not. With the device's own DSP48 blocks enabled:

	LUTs	DSP48	Fmax
TEF64, fabric only	7,479	0	48.20 MHz
TEF128, DSP enabled	4,869	56	103.39 MHz

Comfortably — and at more than twice TEF64's fabric-only frequency.

What actually failed

TEF128 under my own -nodsp, which I impose everywhere so the figures describe fabric alone and are not confounded by how many hard multipliers a part happens to carry.

That is the right policy for comparing formats. Reporting its consequence as a property of the format was not.

The limitation now carries both numbers and says they answer different questions: fabric-only for comparison between formats, DSP-enabled for what the rung actually costs on this device. Six of nine rungs measured rather than five.

The pattern

This is the fifth claim of my own that a measurement has falsified in this campaign, and all five have the same shape:

I reported the consequence of a choice I had made as though it were a property of the thing I was measuring.

• the rungs "don't fit their widths" — I had measured a binary-fabric packing cost
• "one trit per tripling is a new class" — it is takum's, off by an additive 1
• "the gap is empty because the intermediate is too expensive" — it costs 18% more than posit's, which ships
• "TEF64 will cost 4,762 LUTs" — a power law fitted to narrow rungs, extrapolated
• "TEF128 does not route" — under a constraint I set

🤖 Generated with Claude Code