REV 3 - REV 5 - The beginning (ST536)

[exxos]

And this old Microsoft Word video describes this Xlinix hellhole also perfectly !

[ijor]

Found another weird thing.. I got AI to explain, I'm not sure if this is real or its actually a thing ?!

Ridiculous analysis by the AI. Doesn't make any sense to me at all ...

WITHOUT the idle clear:
ARAM and BA hold whatever value was last driven during the previous access column address phase. The starting state before each new access is therefore random and depends on access history. When a new access begins, the number of ARAM/BA bits switching simultaneously varies unpredictably.

WITH the idle clear (to 0 or any other fixed value):
Every access starts from the same known baseline regardless of what the previous access was. The switching pattern from idle state to row address is consistent and bounded for any given address ... The specific idle value does not matter ... What matters is consistency.

Why consistency and predictability would reduce SSN? If all the signals change state, consistently, then you are just consistently provoking the worst case SSN. No, not at all, consistency is not what matters here. Not for signal integrity purposes (might matter for debugging purposes, though). In anycase, clearing the bus at idle would add one additional bus switch. And while the state of these signals might not be relevant at that point, the provoked SSN might affect other signals.

If you want to reduce SSN, then you should, well, simply not change all the signals simultaneously. If you can afford it, you can change, say, half the signals in the previous cycle.

Scope measurements confirmed approximately 1V overshoot on ARAM lines due to transmission line reflections from the ABT16245 bus buffer switching.

What the ABT16245 has to do with these signals??? These signals go directly from the CPLD to the SDRAM. AI seems totally confused.

But if you are detecting serious signal integrity issues it might be worth to improve impedance matching ...

Slow slew rate on ARAM/BA/RAS/CAS/RAMWE was investigated as an alternative fix but made things worse - it reduces setup margin from ~5ns to ~2ns which is insufficient at 100MHz.

In general, slow slew rate might be recommended to improve signal integrity. I think those AI figures are probably exaggerated. Slow slew rate shouldn't add nearly as much delay. But in your case I would avoid it. Probably not a good idea to mess with the timing with all the issues you had finding a stable setup.

[exxos]

Why consistency and predictability would reduce SSN?

I have thought about it some more..
Consistency and predictability is like if you had 50% of signals switching low, then 50% switching high. You know exactly what the timings are, what the noise is, gnd bounce etc.

Now if you have all signals switching low or switching high at the same time you don't get that balance any more, and you just made things a whole lot worse.

Problem is with the current design, most stuff runs on the 100mhz clock, lots switch at the same time. Running some modules out of phase may help in some cases, but timing is just to tight for that.

If you want to reduce SSN, then you should, well, simply not change all the signals simultaneously. If you can afford it, you can change, say, half the signals in the previous cycle.

True, but not simple with such fast tight timings at 100mhz.

The simplest is, with active driven low signals only. Where you could switch all the signals low at the point where nothing much else is switching, so you reduce ground bounce at a very controlled time. Because they are already low, and assuming a pull-up to +v, there is little gnd bounce as the switching to low already happens and pullup resistors are not pushing much current switching high either.

Push-pull output are more complicated because of switching transience high and low. As to if it is better switching high or low, really depends on ground bounce and where it happens. You can of course switch a lot of outputs high or low and improve or make ground bounce worse depending on how you time at all. So that is where predictability comes into play.

What the ABT16245 has to do with these signals??? These signals go directly from the CPLD to the SDRAM. AI seems totally confused.

Not at all. If buffers switch at the same time as SRAM timings, then of course they are related, by the power rails. So its perfectly valid to mention it. Everything is related by the power rails. Just because ABT isn't connected to SDRAM directly doesn't mean it doesn't matter.

I think I posted a while back, I moved timings of the ABT buffer like 100ns later than needed to avoid huge gnd bounce issues. That bounce is predictable and I can avoid it as much as possible as to improve noise.

But if you are detecting serious signal integrity issues it might be worth to improve impedance matching ...

That's why I build the resistor pass-tough board for starters which is probably a few pages back now. The SDRAM will have improved matching on the next respin. These are all issues I am working through currently. Problem is, the more I look into it, the more issues I find, and the more complicated the whole project gets.

Slow slew rate on ARAM/BA/RAS/CAS/RAMWE was investigated as an alternative fix but made things worse - it reduces setup margin from ~5ns to ~2ns which is insufficient at 100MHz.

In general, slow slew rate might be recommended to improve signal integrity. I think those AI figures are probably exaggerated.

They are not. I have measured them. I experimented with all the SDRAM fast slow slew, timings shift more than you think, to the point that timings get borderline for setup and hold timings etc and the thing fails. 2ns difference is huge on 100mhz.

Slow slew rate shouldn't add nearly as much delay. But in your case I would avoid it. Probably not a good idea to mess with the timing with all the issues you had finding a stable setup.

Slow is required on some signals, it improves timing margins and solves a lot of problems. Currently the timings are all spot on now.

In fact the original TF536 all used slow slew and it was a requirement. Some of my boards would work with fast or slow, others only worked with fast. Now I have a better understanding of whats going on, I can make more suitable changes to the PCB layout as well.

[exxos]

I'm too tired to think about this at the moment but the explanation is this...



Why 7→0 and 1→1 can be WORSE than 8→0

At first glance it seems like flipping 8 bits in the same direction (e.g., 0xFF → 0x00) should always be the worst case. But in real hardware, that isn’t necessarily true. Here’s why mixed-direction switching can actually create a more severe disturbance.

1. Opposite-direction switching does NOT cancel out
A 1→0 transition dumps current into GND.
A 0→1 transition pulls current from VCC.

These currents do not share the same return path and do not cancel each other. Instead, they create two separate di/dt spikes on two different rails. This means you get:

• A GND bounce from the 1→0 transitions
• A VCC droop from the 0→1 transitions
• A cross-rail disturbance because both rails move relative to each other

This can be worse than a single large spike on only one rail.

2. The rails are not symmetric
VCC and GND never have identical impedance or decoupling. A small spike on VCC plus a larger spike on GND can interact in nonlinear ways, shifting thresholds and causing more timing jitter than a single clean event.

3. The PDN is nonlinear
Even if the currents were equal, the power distribution network does not behave linearly. Two smaller spikes on different rails can combine into a worse disturbance than one big spike on one rail.

4. Mixed-direction switching creates cross-rail movement
When some bits switch 1→0 and others switch 0→1 at the same instant, the internal reference point of the CPLD/SDRAM (their local VCC–GND difference) can momentarily shrink or expand. This directly affects input thresholds and timing margins.

5. Random start states make this unpredictable
With random previous values, you can get:

• 7 bits switching 1→0
• 1 bit switching 0→1
• Both events aligning with other switching (buffers, SDRAM DQ, internal logic)

This unpredictability is the real danger. Occasionally, the worst possible alignment happens and causes a failure.

Why fixed idle helps
If you always start from a fixed value (e.g., 0x00 or 0xFF), then:

• The switching pattern for each row address is fixed
• The number of same-direction flips is bounded
• The timing of the noise event is predictable
• You can choose the idle polarity that minimizes worst-case di/dt

You’re not reducing the total switching — you’re eliminating the random, pathological cases that only occur when the starting state is unpredictable.

Bottom line
Yes, 7 bits switching one way and 1 bit switching the other can be worse than 8 bits switching the same way, because opposite-direction transitions create two separate di/dt spikes on two different rails, and they interact in nonlinear, unpredictable ways. Parking the bus at a fixed value removes this randomness and bounds the worst-case event.

EDIT:
Ok I get it now. It's not switching low or high all at once being worse, it's switching in both directions at once which basically causes supply rail collapse. This is worse than just gnd or vcc bounce. What AI thought was right, it just didn't explain it very well. The start conditions need to be all 1 or all 0 to avoid the issue which is what I found already.

Same kinda issue with push pull outputs where they actually short the supply rail out. Also reason why gates should never be left floating as they can hang around mid threshold and cause problems.

[exxos]

Been running all night again without issue :D

20260328_092307.jpg

[ijor]

Why consistency and predictability would reduce SSN?

I have thought about it some more..
Consistency and predictability is like if you had 50% of signals switching low, then 50% switching high. You know exactly what the timings are, what the noise is, gnd bounce etc.

That's not what the AI was "talking about". The AI was claiming that what matters is to set the signals to "ANY" fixed value. That as long as you are consistent, you can "clear" the SDRAM address bus with any fixed value. Quoting the AI again:

WITH the idle clear (to 0 or any other fixed value):
Every access starts from the same known baseline regardless of what the previous access was. The switching pattern from idle state to row address is consistent and bounded for any given address ... The specific idle value does not matter ... What matters is consistency.

That's, IMHO, completely nonsense. If you follow AI"s advice and you set all the signals high on idle (again, AI claims any fixed value is ok), and there is an access to address zero, you are provoking, unnecessarily, a full high to low switch. How that could be good?

Now if you have all signals switching low or switching high at the same time you don't get that balance any more, and you just made things a whole lot worse.

That's something completely different. That does might make some sense. But that's not what AI was claiming. This might make some sense because you are trying to avoid the worst SSN case when all signals are switching from high to low. But the gain would be rather small. You still might get all the signals switching concurrently.

Furthermore, if you change the bus on idle (to whatever value), you are generating an extra switch that otherwise should not happen. And again, while the exact state of the SDRAM address bus is ignored at that point, if this indeed provokes a serious ground bounce, that could affect other signals that are always significant, like the SDRAM control signals or even the clock.

If you want to reduce SSN, then you should, well, simply not change all the signals simultaneously. If you can afford it, you can change, say, half the signals in the previous cycle.

True, but not simple with such fast tight timings at 100mhz.

Why not? Why can't you change half the signals on the previous cycle? The clock frequency should not matter for this purpose because you are not changing the same signal on consecutive cycles. You change some signals on one cycle, and the others on the next one. What's the problem?

What the ABT16245 has to do with these signals??? These signals go directly from the CPLD to the SDRAM. AI seems totally confused.

Not at all. If buffers switch at the same time as SRAM timings, then of course they are related, by the power rails. So its perfectly valid to mention it.

Why the data bus buffers would switch at that point when you are starting an SDRAM access??? Why the buffers would be active at all here? Are you allowing Blitter to write to your SDRAM? Because that's the only circumstance that I can think that the buffers would be active concurrently with a SDRAM access.

I think I posted a while back, I moved timings of the ABT buffer like 100ns later than needed to avoid huge gnd bounce issues. That bounce is predictable and I can avoid it as much as possible as to improve noise.

Why you keep the ABT buffers at all? Why not change them for something not so aggressive? You don't need buffers that fast for the computer side. ABT buffers are much worse for this purpose. They can generate much worse SSN noise and ground bounce than the CPLD.

That's why I build the resistor pass-tough board for starters which is probably a few pages back now. The SDRAM will have improved matching on the next respin.

I read you used a pass through board. But not so sure that would be very helpful here. We are talking about potential impedance mismatch on the SDRAM address bus. That would need internal termination between the CPLD and the SDRAM. But this must be done carefully because it will add a small delay.

Series terminator on the buses going to the computer I'm not so sure would be helpful. May be at the data bus if you keep the ABT buffers. But you shouldn't need anything on the CPU address bus. The CPU (or Blitter, the only other device that can drive the main address bus) are relatively slow devices in comparison.

I remember the scopes you posted, including noise on some address bus signals. But I don't think you posted anything that suggested that they were actually provoked by the address bus. It seemed more like that the address bus was the victim of some noise, or crosstalk, or ground bounce, provoked by other signals, not by the address bus signals themselves.

In general, slow slew rate might be recommended to improve signal integrity. I think those AI figures are probably exaggerated.

They are not. I have measured them. I experimented with all the SDRAM fast slow slew, timings shift more than you think, to the point that timings get borderline for setup and hold timings etc and the thing fails. 2ns difference is huge on 100mhz.

I wouldn't expect 2ns difference between fast and slow slew rate. According to Xilinx documentation, slow slew rate would add 1ns delay, or even less, on small capacitive loads (as two CMOS loads that we have here). But anyway, the AI was claiming that the difference would be more like 3ns (5ns vs 2ns setup margin), and that does seem too much.

Yes, one or two ns could be significant at 100 MHz. But nor necessarily for the worse. It could even be better because, while it might reduce setup margin, it would increase hold margin. It all depends on the clock skew.

Slow is required on some signals, it improves timing margins and solves a lot of problems. Currently the timings are all spot on now.
In fact the original TF536 all used slow slew and it was a requirement.

Slow slew rate is not designed to help with timing issues. It might help in some cases. But the purpose of slow rate is to improve signal integrity.

Why 7→0 and 1→1 can be WORSE than 8→0

At first glance it seems like flipping 8 bits in the same direction (e.g., 0xFF → 0x00) should always be the worst case. But in real hardware, that isn’t necessarily true. Here’s why mixed-direction switching can actually create a more severe disturbance.

IMHO, the AI is hallucinating. Or perhaps is just trying to find a remotely conceivable explanation for a wrong premise.

Bottom line
Yes, 7 bits switching one way and 1 bit switching the other can be worse than 8 bits switching the same way, because opposite-direction transitions create two separate di/dt spikes on two different rails, and they interact in nonlinear, unpredictable ways. Parking the bus at a fixed value removes this randomness and bounds the worst-case event.

This contradicts all the literature on the subject of SSN and ground bounce. Switching all the signals in the same direction is worse. Switching all to low is the worst. Even every AI I ask agrees with that.

What AI thought was right, it just didn't explain it very well.

I don't think so. The AI was claiming something completely different before. The AI claimed that any fixed value, including something like $55 (alternate ones and zeros) is ok as long as it is fixed and consistent.

[exxos]

AI has been an invaluable tool for me on this project. It doesn't get everything right and I sometimes have to correct or refine it, but it has helped solve a lot of issues and saved me a huge amount of time. No need to get hung up on the early wording.

[ijor]

AI has been an invaluable tool for me on this project. It doesn't get everything right and I sometimes have to correct or refine it, but it has helped solve a lot of issues and saved me a huge amount of time.

Absolutely. No doubts AI could be helpful. Just don't take everything AI claims as the absolute truth.

Going back to the main issue. I would seriously consider getting rid of those ABT buffers and replace them with not so fast components. That might be one of the most important things that you can do for improving signal integrity.

[exxos]

Been trying to figure out why the board has just randomly failed again :cussing: JLCPCB strikes again !!

After much hair pulling...

Capture.PNG

The highlighted red track from towards the bottom right of the image, from that CPU to the PLD, no continuity ! There is continuity from the 68K header to the PLD though.


There's not even a via other than what the CPU pin is soldered to. I can't see any damage to the track even as its on top copper.

So Yet another bodge wire (YABW) and back booting again !

IMG_4966.JPG

[exxos]

I've been looking into why a cold boot causes the rom shadow to get corrupted but not having much luck so far. :cry:

It seems to survive a warm reset but not a cold reset and TOS is not aware of the memory shadow area even. I write protected the rum shadow after it is copied on power up and even stopped the state machine running during reset thinking maybe it was a rogue command or a refresh bug or something.

Because it paused on warning bad rom in e message, I patched TOS so it would continue but the message just went to another bad rom message and then it locked up. So I would presume that the lower part of the ROM shadow is working because TOS is still running but then something is corrupted higher up so it just completely craps out after that.

So one Monday I will patch, TOS again and put a ROM shadow bypass key combination in there. So it just copies the contents without actually executing the ROM shadow itself. This way I can verify what actually is corrupted and if it is consistent in the shadow over reboots.