Badwolf wrote: Thu Nov 12, 2026 5:12 pm
They may be the longest routes, but they also have, like you say, other things on them. Jumping to it being the length seems a stretch at the speed we're talking about.
The length is what sets the load though. Capacitance to the planes and to the neighbouring tracks goes up with every mm of track. On the current board each of the top 8 lines has about 28pF of copper on it, against under 2pF on D0 to D7.
A topological issue generating reflections might be more easily fixed with some termination and a tweak to the STERM timing.
It's both. The firmware decides when the 030 latches, the board decides how long the lines take to settle. STERM is clocked from the CPU clock, so it can only move in whole 20ns steps. Moving it one clock later on a read straight after a write got the bus tests passing, but that is working around the lack of margin, not removing the cause of it.
Adding capacitance should reduce reflections & would likely improve things if it were topological, wouldn't it?
No, it slows the edges, so the line takes longer to settle while the latch point stays where it is. Whatever it does to reflections, the result was zero errors to 99% failing.
So doesn't that sound like something's asserting on the wrong cycle (or half cycle) rather than on a 10cm board you've somehow lost about 4 metres worth of trace delay?
The 4 metres is right if you only count flight time, but that isn't what's going on. The flight time on these lines is well under a ns, I agree with you there. STERM can only move in whole 20ns steps, so moving it a clock was just the smallest change available, it doesn't mean the data was 20ns late. On the simulation there was only about 2ns between the data settling and the 030 latching it, so a few ns is all it takes.
That few ns comes from how long the line takes to settle, not how long the signal takes to travel. The load slows the edge, and the branches ring, which you can see on the scope. The errors also only happen when the read is the opposite of what was just written, so the line has to swing all the way across. All of that gets worse with longer tracks and more load, which is why the longest and most loaded lines are the ones that fail.
I don't doubt your measurements, I just don't think topography or line length pass the smell test.
The board rework isn't there to fix one fault, it's there to give margin back, which is just good design practice. Right now the four bytes of the data bus average about 18mm, 28mm, 47mm and 88mm from the CPU, with the top byte also carrying the heaviest load. After the rework they are about 25mm, 36mm, 35mm and 41mm, so all 32 lines see a similar load and settle at a similar time, instead of one byte running right on the edge. The firmware then has a bus that behaves the same across all the bits, rather than being tuned around the worst 8 lines.
