New silicon, and numbers nobody can yet vouch for

A part with a new dataflow architecture arrives without a mature compiler behind it. Getting a model to produce numbers is the short half of the work. Showing those numbers are the ones the reference would have produced is the long half.

Where the bring-up schedule goes

That half is measured in weeks to months, most of it verification rather than engineering, and it restarts with each model release. Until it finishes, silicon that has already been paid for is not carrying production traffic.

The risk is documented rather than hypothetical. Production tensor compilers miscompile silently, and a differential test suite finds the cases somebody thought to write (Source: PolyJuice, on miscompilation in production tensor compilers, OOPSLA 2024, doi:10.1145/3689757(opens in a new tab)).

A model placed onto a dataflow fabric, compared with its referenceA grid of tiles with a route threaded through it, feeding an output. Above it, a reference implementation feeding its own output. An equals sign between the two outputs, and beside it a sealed certificate.The Part, as ShippedFabric OutputReference ImplementationReference OutputCertificateEvery InputA model runs quickly. Showing the outputs agree is the long half.
A model placed onto the fabric, and the reference implementation beside it. Bring-up has to establish that the two outputs agree, and a certificate establishes it for every input rather than for the inputs somebody ran.

Bring-up

For a part that already exists

The bring-up engagement points the toolchain at the part as shipped. The lowering from model to fabric carries a proof obligation, and the obligation is discharged once rather than retested per release. The engagement is described in full under Model bring-up.

Want the engagement described first? Model bring-up

Bringing up a part that is already racked?

Contact our team