A packaging engineer describes the software they need, and Micius builds it

Teams usually buy the software they design chip packages with, and it rarely fits how they work. In this project, a packaging engineer wrote one paragraph describing the tool they wanted. Micius, Zhiman’s model, turned it into a list of eight capabilities, and built them into a desktop workbench. The engineer then tried it on a sample package.

Take a wire-bonded PBGA (plastic ball grid array) package. The die is bonded to a substrate with gold wires and sealed under a mould cap, and the underside carries an array of solder balls. Every signal runs from a pad on the die, through a bond finger on the substrate, to one particular ball. Get one of those links wrong and a wire ends up in the wrong place.

Teams usually buy the software for this. It is built for general use, so its menus, the way it imports a pin map and the points where it asks for confirmation often don’t match how a team works. Some smaller companies still have steps with no dedicated software at all.

The people who know what the tool should do rarely write software. A packaging engineer knows which components come in, what the pin map looks like and where mistakes creep in, but building a desktop application takes someone who also writes code. In this project, the engineer wrote only the requirements. Micius wrote the software, and the result was tested on a sample package.

The engineer asked for a desktop workbench for designing a wire-bonded PBGA package. It needed to import five kinds of components (substrate, die, wires, mould cap and solder balls) and a pin map as a CSV file, let the engineer edit package dimensions and see the 3-D model update, offer several views, a bill of materials (BOM) and a design-rule check, and export the model and the pin map. One sentence set the point where the engineer decides: when the workbench finds conflicting endpoints between pads, bond fingers and balls, it locates the problem and suggests a fix, then waits for the engineer to confirm before generating the connections and assembling the package.

Micius read the request and produced a list of eight capabilities, from the desktop frame and its menus to one-click assembly, the four views, the BOM and design-rule check, and export. It defined the connection check by signal: each row of the pin map records the net a pad carries, and a conflict means endpoints from different nets landing in the same place. The export includes a check report, so the result stays on record.

It then built the modules one at a time, adding each to the workbench and ticking it off the list. The workbench frame and its menu system are the first item. Connection editing became its own module with five controls: import CSV, assign pins, check conflicts, confirm fixes and export connections. Confirm fixes turns the engineer’s “wait until I confirm” into a control: a suggested fix is applied only once the engineer accepts it.

To test the workbench, the engineer imported a sample component set: a die with 52 pads, 52 gold wires, and 121 solder balls in an 11 × 11 array. The workbench added the parameters to the project and rebuilt the 3-D model.

With no pin map loaded, the connection editor warned that 52 pads had no connection. Once the pin map was in, each row gave a pad, its net, its bond finger and its ball. Net DATA1, for example, runs from die pad D002 to bond finger F002 and on to ball A2, and the connection diagram highlights that path end to end.

The check found all 52 pads assigned and no conflicting endpoints. The workbench generated the connections, synced them to the bond wires in the 3-D model, and exported the pin map and a check report. With no conflicts, the fix-suggestion step never came into play. Engineers can also skip the suggestions and assign a pad to a bond finger and ball by hand.

A note under the connection editor sets the scope. This is a logical pre-check: every pad is covered and no endpoints from different nets conflict. The paths on screen are a connection diagram, not physical substrate routing, and nothing has been signed off for manufacturing. Whether the wires can be bonded and the substrate routed is decided later in physical design, by an engineer.

Zhiman’s EngiWorld research measures how well models operate engineering software. This project asks the reverse: whether a model that knows package design can write the tool an engineer describes. If it can, some software a company would otherwise buy, or has never had, could be filled in this way, which might also shorten purchasing and lower its cost.

The run record covers the request, the capability list, the component import and the connection check. The views, BOM and design-rule check are on the capability list, but the record doesn’t include their results on the sample package. The workbench is still some way from production software: a company would need to connect it to its own component libraries and data formats, add tests, and have engineers accept it item by item.