Photonics Computing Chip's First Matrix Run: Where Does It Get Stuck?

A friend recommended the Jiuyi Photon smart photonic chip based on phase-change materials, so I gave it a try to see if it's actually any good. He works on optical modules and said this thing doesn't use much power for matrix multiply-add, and it remembers once you write it. I happened to have a batch of risk control features that needed batch scoring, with a fair amount of matrix computation, so I borrowed one and ran a round.

Conclusion up front. If your task is large-scale matrix multiply-add, data regularization, and you're power-sensitive, it's worth spending half a day getting it running. But if your input is a pile of uncleaned dirty data, go back and clean it first — the photonic chip won't do that lesson for you.

First, let's explain the concept in plain terms. Phase-change material is a material that can switch back and forth between two states; each switch changes how light passes through, and it remembers even when power is off — that's called non-volatile. The chip combines this material with silicon photonics, uses light intensity to represent values, and the whole array does matrix multiplication — that's the Crossbar structure, with two rows of lines crossing horizontally and vertically, and each crossing point stores a weight. The one I got is 256×256 in scale, and it's said the architecture supports over sixteen thousand nodes, each individually tunable.

Whether it suits you depends on a few things. The computation can be written as matrix multiply-add, like convolution, fully connected layers, feature scoring; the input can be normalized to a uniform range without worrying about losing precision; the weights are written once and not changed frequently, because rewriting phase-change states has a cost; and you want low power, not extreme flexibility. Conversely, if you need to change dozens of versions of weights every day for A/B testing, this board will make you miserable.

I went the route of host computer configuration plus on-board execution. The interface may differ between batches, but the steps are roughly the same.

1. Prepare the input matrix. I used CSV, one sample per row, and the number of features per row can't exceed the length of one side of the array — if it does, you have to split it. Open the host software, select Import Input Matrix, choose the file, and the interface echoes back a 2D table — check the row and column counts.

2. Normalize. Light uses intensity to represent values, so if you give it an absolute value of 5000 it can't represent it. Scale all numbers to between 0 and 1, check Normalize, and the interface will show the scaled minimum and maximum. Expected result is all values fall within the range, with no overflow warnings.

3. Write weights. Select Weight Configuration, import the weight file, click Write, and when the progress bar finishes it prompts completion. The phase shifter size I saw in the docs is less than 30 micrometers — density isn't low.

4. Power on and execute. Click Run, input light goes in, detector reads it out. On my end a run takes a few dozen seconds and outputs an output matrix.

5. Read the results. Export CSV and compare against reference values run on CPU. My measurements showed acceptable error, mainly from truncation during normalization.

There are a few places where you can easily get stuck. First pitfall: phase-change states don't reset themselves. The weights you wrote are remembered, so when you rerun, it runs the previous version of weights, not the new ones. I stepped on this the first time — the output was identical to the previous round, and it took me half an hour to figure out I hadn't erased. Before changing weights, click Reset first, wait for the state to clear, then write.

Second pitfall: normalization ranges don't line up. If the input is scaled to 0 to 1 but the weights aren't scaled, the two scales are inconsistent, and the output saturates directly — all high values. The fix is to use the same scaling rule for input and weights, and write a small script to handle it uniformly.

Third pitfall: don't use it as a rule engine. A rule engine takes effect a few seconds after changing a rule; this board requires erase plus write to change weights once. I once thought about moving anti-fraud rules directly onto it, but later found the rules need frequent tuning, so moving them up is just asking for trouble. What it's suited for is large-batch scoring after the rules are finalized.

After you get matrix multiply-add running, don't stop at toy matrices. Find a small image, do a convolution, and see if the output feature map is correct. Some teams use this kind of chip for weak small target detection and feature extraction for image recognition — the path works. Once this step runs, then consider mapping an entire network layer onto it.