REV 3 - REV 5 - The beginning (ST536)

[exxos]

New ST536 board built up. This one is right sulky with STE firmware. Hardly gets to the ROM CRC test even.. very wired.

IMG_4014.JPG

EMUTOS got further, mostly threw up exception errors then got to desktop with bits missing..

IMG_4013.JPG

Anyway, did a load of firmware tweaks (no doubt its going to break the STE stuff now, so I may have to do 2 branches afterall, we shall see)


Now it loads and runs fine..

IMG_4015.JPG

The most frustrating thing in all this is that it once again needs a inverted SDRAM clock and I have no idea why :(

The STE536 will work fine with inverted or non-inverted clock.. Basically the same hardware and firmware otherwise...

Well some timings could be slightly different on the STF chipset, why is TTram sulky.. It has data buffers to isolate the ST bus during TTram access.. So its not like the ST536 will even care if the ST bus isn't free yet or something..

I keep going down this inverted clock shenanigans road and I haven't yet been able to figure out what's going on :cry:

[exxos]

YAARTTT gave something interesting...

IMG_4016.JPG

Left 2 numbers always wrong, right side numbers always correct.. hmm....

Question is, is those left bytes on the ST side bus or just the bytes on the CPU :shrug:

Even more strange ,if I disable my ROM copy logic, those 2 left numbers start at 00 and after YAARTTT lists lots of failure, it starts counting, 00,01,02,03 etc....

IMG_4017.JPG

[exxos]

I went back to an old code patch I did a while ago while messing around with this stuff..

IMG_4019.JPG

Basically slow slew would work but fast slew would not. Similar that only inverted SDRAM clock would work on the ST. But it wouldn't care at all on the STE.

My current thought is that the address bus is simply not stable when the CPU is running at 50MHz. I think in particular on the H4 & H5 boards because all the signals are sandwiched between the power planes adding a lot more capacitance than the STE has.

Mean the address bus is supposed to be stable when /AS goes low. But it needs to be checked , maybe you can have a probe @PhilC if your bored at some point ?

It's also possible the propagation delays through the PLD itself are upsetting things. I talk about my ROM address translation logic and I just got a row of bombs on power up.. So that slight speed up has caused it to become even more unstable.

I have the fastest PLD 6ns. But as the fastest clock is 100mhz, I suspect the decoding needs to wait 20ns. is actually delayed in the original TF core anyway by 10ns as its a clocked event. But I am clocking it again.. so 20ns or there abouts.

I was thinking that it would in that case, needful address isolation to deal with the problem properly, but that would be a royal PITA. I would need to figure out what the delays are on the PLD and address bus in relation to /AS etc first..

I ran GB6 expecting there to be a bit of a speed drop in TTram test, but it seems not :o even more weird it actually seems to be running faster now :stars:

IMG_4015.JPG

IMG_4020.JPG

Annoyingly the inverted ram clock is still needed and that mystery still not solved yet :pullhair:

[Badwolf]

Basically slow slew would work but fast slew would not. Similar that only inverted SDRAM clock would work on the ST. But it wouldn't care at all on the STE.

I'd always try to use slow skew if you can to reduce ringing. It may mean you need to invert a clock here or there, but I'd have thought will be more stable longer term.

My current thought is that the address bus is simply not stable when the CPU is running at 50MHz.

Do you think this is an address bus or data bus issue? Reading or writing?

For the latter what you can possibly do is interrupt (CTRL-C) YAARTT when you get errors and then inspect the most recent one in memory. Do you get the expected value, or do you get the recorded wrong one? If you consistently get the wrong one then it's a write problem. If you get the right one or it varies on occasion -> read.

With all this inverting and otherwise of the clock, it could be you're just firing STERM a cycle early.

Interestingly it looks like your high word is always fine (that's the one that's shared with the motherboard). The low byte is always fine. It's the third byte that has the problem and the bottom three bits are pretty much always OK too. Not sure that tells us much unless one of the buffer chips is a bit slow and you're STERMing too soon.

BW

[exxos]

@Badwolf I've tried all sorts of timing tweaks and I cant hit on anything else. Delaying sterm makes no odds. I've tried pos negedge tweaks etc etc.

I did wonder if it was a databus issue but I even used a faster buffer. Tried spending up isolation and slowing it down.. If a 5ns flip makes or breaks it then I should have hit on something else by now.

If I remove my address translation logic things get worse. Less delay on address bus. If I clock it through a block it's totally stable. All that changes is delaying the address bus.

I was trying to run STOS to do read write tests but it wasn't stable enough. I need to scope the address bus in relation to /AS to see if something is amiss.. There might not be.. It might just be PLD delays internally.

I think I know one issue though. The original TF536 used a 10ns, PLD.. according to be he timing report my pin to pin delay if 6ns.. Now I have to invert the clock, 5ns.... A 10ns delay on the clock on 100MHz, basically zero clock skew.

Grok wrote me a delay loop, running the clock through Inverters to give like 2ns delay steps.. Theres a clear pattern of it working and not working depending on delay.. @PhilC is going to run tests to see if he can get the same pattern.

So the original TF536 works as its using a 10ns PLD.. I have to invert the clock with my 6ns PLD..

PLOTTWISTS
The STE doesn't care.. But it doesn't have powerplanes like the H4 does which could be enough to break it.

[exxos]

So its seems the theory was right with clock skew. I have to invert the SDRAM clock , as after PLD delays, it then ends up 99% back in phase.

So I thought I would try and cut out the PLD, and hardwire the 100MHz osc direct to the SDRAM and bypass the PLD totally.

It works but TTram ended up a speed drop from 847% :roll:

IMG_4021.JPG

I removed the address delay fix I did earlier and speeds back up, but its still overall a bit slower than the faster GB6 results a few posts up.

IMG_4022.JPG

The odd thing is that theres is only about 0.5ns skew between the clocks and that small skew somehow ends up working overall faster even with the address delay fix :stars:

[PhilC]

I'd be happier with more reliable ram than balls out speed, so maybe wiring direct is the thing to do.

It's like overclocking, yes a CPU might get to 100mhz but crash once in a while but 80mhz is rock solid. 80 would get my vote every time.

(Of course you should ignore all I say, running my Raven 060 @ 100mhz :lol: )

[exxos]

(Of course you should ignore all I say, running my Raven 060 @ 100mhz :lol: )

Probably why it locked up when I tried to use it :P

I'd be happier with more reliable ram than balls out speed, so maybe wiring direct is the thing to do.

Yeah stable is my aim. But it just runs slower for no reason. I just put the PLD drive back. "number 14" jed gives a 1ns delay.. So thats probably the best one in theory.. but this is depending on internal propagation delays.. which could vary from PLD to PLD anyway. So I need a better method for the delay.

[exxos]

Left it on overnight...

20251113_104844.jpg

[exxos]

Been doing tweaks all day and I think I have settled on the firmware I am happy with.. I dread to think of it still works with the STE at this point.. Or anyone else's computer :lol:

Is very difficult to add chained delays into the PLD because no matter what I try the compiler seems to always optimise it away :roll: but I was not really happy with that solution because tolerances and thermal drift etc across multiple gates can add up.. And I was pretty much hitting a problem at 0.5ns margins !

Its currently running TTram test and GB6 everal full loops gave the "maximum speed" results which is good.

Probably won't have time to do any more testing until Monday now...