REV 3 - REV 5 - The beginning (ST536)

[exxos]

Looks like my new board will not get here until the 23rd

Slightly annoying as those boards are already technically obsolete in terms of mods But its not "deal breakers" either. I got some small clock mod boards made which can be retro fitted if needs be. Cost a fortune and they are tiny

I did some experiments where I just added some 33R in series with some signals and it caused the SDRAM to break just by doing that. Even just 22R as I fitted on the STE536 almost did nothing signal quality wise. But I believe the tiny delay it adds is enough to break SDRAM timing again. Hence the new mods boards and tests. My scope isn't really good enough for capturing such tiny differences.. Plus with a bit of jitter as well makes it very difficult

I also believe this is why fast slew doesn't work because it changes the timings on some signals by about 2ns. Noise gets worse of course, but I don't believe that is the primary issue.

Ironically the STE536 doesn't seem to suffer the same.. But that could be a fluke as some SDRAM trances are longer due to limit space on the PCB. Likely that tiny delay extra is just enough to make it work. I'm talking of in the order of like 0.1ns ! That's all it takes. Also similar with the 33R, timing is almost nothing, but enough to break it.

What still doesn't currently make sense is why a different STram board kills the SDRAM. There isn't any real link between the two other than power. But even so it's a 5V vs 3.3V rail.. But GND bounce is probably the cause. I'm not going to get sidetracked onto all that.. If after the current mods are done both ST run boards then work then I will just call it job done. But it's possible they all could just be a red herrings because make or break can depend on how hot/cold the PLD is. It really does not take much..

So theoretically when my buffer boards come and hooked into the circuit, that should give about a 2ns timing skew, which should be enough to deal with any "tolerances" with everything else.

[exxos]

New boards come

Rather than build up another board, I hacked jobbed the current one because I know the behaviour already of that board..

Basically with no modification TOS TTram check fails intermittently. I verified this before I started modelling and it still failed in the same way..

Then things escalated a little bit...

IMG_4250.JPG (358.04 KiB) Viewed 187 times

Currently

IMG_4251.JPG (220.14 KiB) Viewed 187 times

I need to try some other stuff out but hopefully this is the winning stretch now....

[exxos]

Well this is crazy...

Look at the fall between both the signals..

IMG_4254.JPG (297 KiB) Viewed 177 times

IMG_4255.JPG (283.46 KiB) Viewed 177 times

Ironically the worse skew is with a shorter wire.

IMG_4256.JPG (365.03 KiB) Viewed 177 times

I realised I still had the buffer connected in that test

Retesting :

IMG_4257.JPG (301.97 KiB) Viewed 177 times

IMG_4258.JPG (285.12 KiB) Viewed 177 times

So maybe 10cm gives about 1ns delay over the shorter wire. Thats enough to make or break the thing

This rather puzzling because with fast slew, I get more delay now.. i would have expected less skew because of faster PLD logic.. thats what I think I saw originally...

EDIT:

ah no.. BLUE is FASTER with fast slew, making the timing skew "larger".. Man, this is complicated !

[exxos]

Been doing a lot of testing and ultimately it needs a buffer in the clock for slow slew. But fast slew, as it makes RAS/CAS faster, that buffer now creates a problem and has to be removed to "close the gap" from the clock edge.

TTram speed ends up at 887%. But locked up during GB6 tests Problem is as well, I haven't moved to the later revision boards which should be more stable, BUT, moving to a totally different board changes tolerances of everything which could upset my current tests anyway...

In summary for everyone who is not keeping up.. The timing problem is fixed with slow slew... but TTram takes a few % speed hit with all the fixes currently. I am only trying to get fast-slew working to gain extra TTram speed. Probably chasing a unicorn, but that is generally the case....

[exxos]

I flashed the latest STE536 firmware into the ST536 and TTram has failed again

I'm going to put some series resistance on some signals again because that is what I did on the STE version. I think ringing could be part of the problem I have been fighting for a long time..

[exxos]

Only fast-slew now works on the ST536

There must be some ringing on another signal somewhere..

IMG_4312.JPG (387.36 KiB) Viewed 105 times

IMG_4313.JPG (403.28 KiB) Viewed 105 times

[exxos]

I suspect what might be happening is that there is simply more noise on the SDRAM bus on the ST536 than the STE536 as I optimised the routing on the STE536..

This is the same signal highlighted...

STE536.PNG (154.53 KiB) Viewed 100 times

ST536.PNG (184.81 KiB) Viewed 100 times

The ST536 has more of a "T" shaped track, whereas on the STE536 is more "direct" right to left.


So believe it or not these are the exact same signal...

IMG_4315.JPG (267.14 KiB) Viewed 100 times

IMG_4316.JPG (257.63 KiB) Viewed 100 times

The difference is the bad one during a TTram test. The other is not accessing TTram much at all.

You could then ordinarily assume (like I did) it smells like a decoupling issue.. But I use multiple values on the ST536 rebuild. Dual regulators. Improved the power planes and doubled up where I could.. and still its worse than the STE536.

So it looks like current boards will have to use the Fast-slew firmware (not uploaded yet) . Ultimately, I need to squash down the ST536 traces as much as possible and maybe even add some series resistance to "Take the edge off" a bit more. I think all the high frequency switching, even with improved decoupling, its still tipping the whole thing over the edge.

In other slightly related news, I discovered a new crash screen today

IMG_4317.JPG (215.57 KiB) Viewed 100 times

[exxos]

I noticed a couple of other things as well...

This is RW ... Notice the rise..

IMG_4345.JPG (285.88 KiB) Viewed 43 times

But then notice this one...

IMG_4346.JPG (290.2 KiB) Viewed 43 times

That seems to happen during floppy drive access or somewhere around there.. Possible blitter as well but not looked into it more.. Those scopes are even with 1K extra on RW!

Those cycles happened during ST bus access, so the slow RW rise time is "normal" , my concern is that this could potentially clash with the RW on the CPU since RW and RW30 are hardwired on the 536 by default. I think that is part of the issue I have been fighting for a while now.

I have done some tweaks to the clock switching code as well to make sure it doesn't glitch on a slow cycle as much. Gives a bit more time for the ST chips to "do their stuff" before the CPU cranks up the speed.

I also see less of these now but still weird..

Where yellow speed switch register and blue is the CPU clock..

IMG_4349.JPG (346.94 KiB) Viewed 43 times

A small pulse high on the speed register and it is basically causes the 50mhz clock to glitch. I am not sure the exact trigger.. Possibly related to address decoding glitches when the CPU has completed its cycle..

Anyway, I don't allow slow mode any more unless the register is high for two consecutive cycles..

So now it ends up like this...

IMG_4350.JPG (353.76 KiB) Viewed 43 times

I've not seen any side-effects so far.. It is just the CPU spending more time in 50mhz , (it does not yield any speed benefit) .

I have been doing tests by heating up the PLD. Generally it survives 10+ seconds heating. Then when something is "borderline" , it generally crashes within about five seconds.

It is a bit tricky doing this because generally it will survive 25 seconds of heating.. I will do a code change. Then it will only survive like 12 seconds.. But I think that is a red herring because the PLD is still "warm" from the previous heating.. So I am ignoring the 25 seconds timing and just going for above 10 seconds is "good".

I've also added in some hold off logic during fast cycles. Aside from the problems with RW, I think the problem is after a STram access. those 373 / 244 buffers take some time to release the bus. While the 536 has databus isolation, I think it can take more time for the bus to fully release and all control signals (like RW) for about 20ns or thereabouts. So now I make sure I don't start fast cycles until after a 20ns delay to prevent bus turnaround conflicts. Of course the data isolation buffers probably take like 10+ns to tristate anyway.

Annoyingly the benchmark scores have dropped a little bit again. So I need to look into that next..

[ijor]

This is RW ... Notice the rise..
That seems to happen during floppy drive access or somewhere around there.. Possible blitter as well but not looked into it more.. Those scopes are even with 1K extra on RW!

Those cycles happened during ST bus access, so the slow RW rise time is "normal" , my concern is that this could potentially clash with the RW on the CPU since RW and RW30 are hardwired on the 536 by default.

While this would be a problem? As you are saying, the slow rise edge is perfectly normal when GLUE tristates the bus after completing a DMA transaction. Shouldn't cause any conflict, even with a weaker pull-up. The CPU will actively drive the signal when starting a new bus cycle. During the slow rise time the bus is idle.

Aside from the problems with RW, I think the problem is after a STram access. those 373 / 244 buffers take some time to release the bus. While the 536 has databus isolation, I think it can take more time for the bus to fully release and all control signals (like RW) for about 20ns or thereabouts.

The LS373 might take ~20ns to completely release the bus. But this delay is from RDAT trailing edge, not from the end of the bus cycle. MMU deasserts RDAT after S7. By next S0 the bus should be tristated. The CPU would not start driving the bus, at least after another full cycle.

[exxos]

I think I figured something else out as well..

Slow slew causes TTram to malfunction totally. However if I delay TTram access by a CLK100, it works fine, even when heating the PLD.

Fast slew works without the delay. However it seems more heat sensitive when heating the PLD, but not by much.

Long story short, I think it still needs the delay on the SDRAM start. Fast slew "just" gets away with it, but I had a buffer on the CPU clock before, I bypassed it and now fast slew no longer works. Is very temperature dependent as well. So theoretically it would need probably a 4ns delay on CPU clock.

However, I really wonder if it's a side effect of RW again. If the ST side RW is driven low, and the CPU enters high-speed mode and is trying to do a write, it would clash on the first cycle. Adding a delay would skip that as well..

I did remove the wrong shadow logic is that likely adds a little bit of delay, but nothing changed. So I don't get the impression it's a addressed eco-problem like I was previously assuming.. It's something else.. Proving its RW is tricky though without some serious hacks