Blog
Physical width changed the question
A committed-oracle comparison exposed a nominal-width error: TNF16 labelled as 16 bits occupies 19 physical bits, so the table now matches containers before comparing lattices.
- THE LABELNOMINAL WIDTH: 16 BITS
- THE WIDTHPHYSICAL CONTAINER: 19 BITS
- THE COMPARISONMATCH CONTAINERS BEFORE COMPARING LATTICES.
[measured — committed oracle, not board hardware] W991 reran the competitor table from the repository’s committed oracles. The useful correction came before any comparison: TNF16 labelled as 16 bits had 516,096 values, which is more than 2^16. Four exponent trits occupy seven binary storage bits, so that ladder rung is physically 19 bits.
The table now asks the physical question
The repair keys the comparison by physical width and refuses a width that no rung occupies. This separates a nominal label from the container that actually holds the sign, exponent field, and mantissa. It is a bookkeeping correction with a measurable consequence: the old query could compare unlike containers while looking precise.
| physical width | TNF rung | TNF values | posit es=1 values | TNF step at 1.0 | posit step at 1.0 |
|---|---|---|---|---|---|
| 6 bits | TNF4 (2 trits, 1 mantissa bit) | 56 | 62 | 25% | 12.5% |
| 10 bits | TNF8 (3 trits, 4 mantissa bits) | 960 | 1022 | 3.125% | 0.781% |
| 19 bits | TNF16 (4 trits, 11 mantissa bits) | 516,096 | 524,286 | 0.024% | 0.002% |
At every matched width in this ladder, TNF has fewer reachable values and a coarser local step at 1.0 than posit with es=1. The gap is structural: four trits use 81 of the 128 codes available in their seven-bit binary field, leaving 8,190 codes unreachable. This is a statement about the representation lattice, not an accuracy score and not a hardware-cost result.
The comparison is not the conclusion
A table can be internally exact and still answer the wrong width question.
The corrected table does not establish that one format is preferable for a workload. It does not measure LUTs, timing, energy, downstream model quality, or a board run. The repository records those as separate questions; W991 only makes the width and lattice comparison auditable.
What the patch leaves open
- Whether the physical-width comparison changes a workload-level choice is not measured.
- The table does not provide a cost model; area, timing, and energy remain separate measurements.
- The displayed local step describes the neighbourhood of 1.0 and is not a summary of every extreme of a tapered format.
- The TNF ladder and the posit oracle are compared at matched container widths; no claim about takum accuracy is made here.
The practical lesson is small and reusable: before comparing numeric formats, derive the stored width from the encoding and make the tool reject impossible widths. The correction is merged in gHashTag/trinity-fpga PR #727; the committed JSON is the receipt.
What this does not settle
- Whether matching physical width changes a workload-level choice is not measured. W991 compares the representation lattice only.
- No LUT, timing, energy, or board measurement follows from this table. Those are separate artifacts and remain open.
- The local step at 1.0 does not summarize the extreme behaviour of a tapered format, so it must not be read as a whole-range accuracy claim.
- The comparison is with posit for the committed lattice table; no accuracy comparison with takum is made here, and no claim about a preferred format is supported.
Receipts
Work with me
Want this kind of check on your own design?
I audit RTL and build independent, bit-exact models, then take the result through synthesis and, when useful, onto an Artix-7 board. The first conformance module is free.