Chipfoot BGA Footprints

Use it in VS Code

This extension registers the Chipfoot BGA Footprints MCP server with VS Code. Open Copilot Chat in Agent mode and the server's tools appear in the tools list; MCP: List Servers shows its status and log.

The first start creates a private Python environment (Python 3.10 or newer must be installed; set chipfoot.pythonPath if it is not on PATH) and installs the dependencies. Chipfoot BGA Footprints: Rebuild Python environment starts over.

Environment variables for the server go in the chipfoot.env setting.

A footprint for almost any BGA chip, every Nvidia GPU included, from one of these sources:

Each run writes .csv (ball, x, y, net), .kicad_mod, .json (summary) and _fitcheck.svg (1:1 ball side drawing for a paper test).

Universal method: scan the chip

Lay the chip balls down on a flatbed scanner, close the lid and scan at 1200 dpi or more. Grey or colour, no ruler needed. Then call footprint_from_image with image, dpi, out and optionally expect (ball count from the package name, e.g. 3328 for FCBGA3328).

The image pipeline has no package-specific constants:

1. Pitch: autocorrelation of the image.
2. Lines removed: package edge, frame and rulers (long straight lines) are taken out.
3. Balls: a template learned from the image itself (median patch), then normalised cross-correlation and sub-pixel peaks. This works for bright balls, dark pads and stencil rings alike.
4. Deskew: neighbour directions with the 90 degree symmetry folded out.
5. Physical rule: no two balls closer than 0.75 pitch.
6. Row and column lines: neighbour chains, merged across gaps. Each ball takes the mean of its lines. This is how zones with different pitch, diagonal seams and paired rows come out on their own.
7. Gaps filled only with evidence: a detection must sit at a free line crossing or bridge. Real depopulated holes stay empty.
8. Output: scale, mirror to the top view, names.

Validation

test_chipfoot.py: truth = the AD102 FCBGA3328 footprint.

test_families.py: package families found on Nvidia boards, 1200 dpi scans, dpi only.

• Synthetic scans only. All scans are rendered from known footprints. A scan of a real chip has not been run yet; that needs the chip. The MCP tools have been run end to end through an MCP client (footprint_from_image on the AD102 scan: 3328 balls, 100 % against a hand-made footprint).
• Phone photo: finds every ball, but the scale from the package edge is about 0.2 % off. Use it to identify the pattern, not to order a board.
• Stencil: the differences all lie under the watermark letters. There the manual footprint is also only an inference.

Fixes found by these tests:

• Pitch now comes from the spectrum's fundamental. Autocorrelation picked harmonics.
• Staggered rows use the longer axis period.
• Deskew picks 4-fold or 6-fold symmetry. Hex grids cancel the 4-fold average.
• The template is learned only from isotropic peaks, so package edges cannot become the template.
• Only strong detections build the lattice; weak ones are evidence for filling.
• The package edge is thresholded between the border and the centre, not by Otsu.

Real Nvidia ball patterns (test_real.py)

The test images are reball stencil artwork sold for real GPUs (gpufix.de, in ref/real). Truth comes from a second, independent method: the ring pixels inside the stencil frame are counted as connected components, with no template, lattice or filling.

• Balls on uncounted rings are real balls. Rings that touch the frame, a printed helper line or the watermark merge with it and cannot be counted as components. chipfoot still finds these balls: on TU106, 86 lie on the two helper lines and 37 touch the right frame.
• AD102 agrees with the manual footprint at 99.55 % (all differences are under the watermark).

Blackwell (RTX 50, current generation). The images are seller listings (AliExpress). The truth is the package ball count the listing gives (BGAxxxx) plus, where the balls are separate disks, an independent disk count.

• GB207 (RTX 5050) is not covered. No stencil or image is offered for it yet.
• Photos of the plate need care. The GB202 photo of the steel plate (photo=True) gives 4775 of 5830; glare wipes out part of the field.
• Too-small photos are refused. The 600 px gpufix.de photos are rejected ("resolution too low").
• The skew fix stays small. It turns by at most 22.5 degrees (square grids) or 15 degrees (staggered). A Blackwell core rotated 45 degrees, or a staggered field with vertical rows, keeps the package axes.

New and unknown chips (test_fuzz.py)

chipfoot has no package catalogue: every chip is just a point in the space of ball patterns, and a newly released chip is a point it has not seen before. test_fuzz.py draws random packages over the whole range Nvidia uses and recovers each from a 1200 dpi scan (2400 dpi below 0.5 mm pitch), dpi only.

The random packages vary:

• Pitch: 0.4 to 1.27 mm, square or rectangular.
• Field: up to 95 mm (datacenter class), up to 20,000 balls.
• Layout: edge zones with their own pitch, a moat and diagonal seams (AD102 style); a depopulated centre; random holes; staggered rows.
• Appearance: bright solder balls or dark pads.
• Scan defects: up to 3 degrees tilt, blur and noise.

A case passes only if every ball is found, there is nothing extra, the mean error is under 0.01 mm and the maximum error is under 0.05 mm.

Fixes found by the fuzz runs:

• Pitch: candidates come from 2D spectrum peaks, including hex and diagonal plane spacings, each checked by the blob area it explains. This is rotation invariant.
• Tolerances: chain, merge, snap and bridge tolerances come from the measured position noise (5 sigma) instead of fixed fractions of the pitch. Seams between zones therefore stay apart on scans, while the noisy stencil still merges.
• Line pieces: pieces that overlap along a line are different lines.
• Lone balls: a lone ball inside the field is kept where it was measured.
• Speed: sub-pixel upsampling follows the ball size; a 95 mm package takes 17 s.

Limits

• photo=True is experimental: it searches only where the image repeats in two directions. It is not used by default because it can cut off real balls on clean artwork.

• Resolution: at least 6 px per ball pitch, 8 or more recommended. Below that the tool refuses the image.

• Ball names are row and column indices of the found lines, not the vendor's names. Use footprint_from_boardview for real pin names and nets.

• Boardviews: only OpenBoardView ASCII .brd and CSV. Encrypted formats (.fz, .tvw, many .bvr) must be exported first.

• Phone photos: need the whole package edge visible on a contrasting background.

• Balls under labels or dirt are only filled when some detection supports them.