exxos wrote: 27 Mar 2026 19:20
ijor wrote: 27 Mar 2026 17:58
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.