ST536 STE EDITION

[exxos]

Out with the old, in with the new...

IMG_2931.JPG

IMG_2932.JPG

IMG_2934.JPG

IMG_2935.JPG

I haven't made any firmware tweaks, it is basically come back to the original ST536 firmware (which likely used Winbond). But theres some RAS/CAS tweaks I need to undo yet.. So it *shouldn't* really work in that state.. but EMUTOS has found 64MB and now YAARTTT is running... Will take out my "fixes" later and try again...

Before, It locked up on pass 2...

:crossed2:

[Badwolf]

Why hasn't someone ported the EMUTOS driver as a standalone PRG for TOS by now ? With it being open source, all issues and improvements by developers could be done a lot easier..It be way better than keep depending on the old ICD tools for a "free" driver..

I very nearly completed a PRG version of the ET IDE driver codebase but I think it fell over on my implementation of (rather lack of understanding of) a diskbuffer and I got distracted.

Thanks for linking Mikro's forum post, @Steve. I hadn't seen that and found it very interesting. I doubt the problem as described is related to TF536, but from what I understood setting the cache fill disable jumper might let one test if it is.

BW

[exxos]

I very nearly completed a PRG version of the ET IDE driver codebase but I think it fell over on my implementation of (rather lack of understanding of) a diskbuffer and I got distracted.

Always too many projects and ideas and not enough time :)

Thanks for linking Mikro's forum post

Not sure if was specifically mentioned but I found a thread on HD driver forum..
https://www.hddriver.net/forum/viewtopi ... 1321#p1321

[exxos]

It is just ticked over to pass 10 :) This is with the inverted SDRAM clock which is what the windbond chip used.. Will try the original TF timings next.

I wonder if the Winbond chip being 200mhz, actually need something close to that frequency to reliably work.. Whereas the alliance chip being a slower part of 166 MHz, may tolerate the down clock more (100MHz) :shrug:
it seems incredibly weird that the winbond chip seems to have a very narrow timing window of like 3ns.

it also begs the question, that if the inverted clock worked better for the winbond, should we continue using that clock, or go back to the tried and tested (original) TF536 timing..

IMG_2936.JPG

Well EMUTOS didn't boot with the original timings...

IMG_2937.JPG

TOS206 booted, but no TTram...

IMG_2938.JPG

So I will have to leave it on test with the inverted clock it seems... its all very discombobulating :crazy:

EDIT:
I look back through my previous conversations relating to the clock inversion, and I mentioned before that even "innocent" changes to the code seemed upset the SDRAM controller..

So now I go back to my previous notion of that it is just literally luck of the draw, of how the compiler fits everything together as to if it works or not :roll:

The alliance chip so far seems to be behaving better than the winbond one.. Even though its still running my "fixed" code. But it looks like that is just going to be the best solution overall currently.

[exxos]

I revisited the 144xl vs 288xl as I couldn't accept they were both identical timing wise. Turns out "compiler gone funny" and I deleted a load of files and now it actually seems to be updating the reports now!!

There are some subtle differences between the two, for example..

144.PNG

288.PNG

These are both the reports if anyone wants to take a closer look...

timing_reports.zip

[ijor]

I wonder if the Winbond chip being 200mhz, actually need something close to that frequency to reliably work.. Whereas the alliance chip being a slower part of 166 MHz, may tolerate the down clock more (100MHz) :shrug:

No. There is "virtually" no minimum frequency. I say "virtually" because if you use extremely low frequencies you might violate some specifications, specially of course, the minimum refresh period. 100 MHz is not considered a low frequency at all, in this context.

... slightly faster.. which should work better.. in theory.. as timings shouldn't need to be as tight

That's not exact. A faster chip will usually require both smaller setup and hold timings. That means, indeed, that the output timing (from the controller to the DRAM) would be less tight. But a faster chip will also typically provide less output hold time. And that means that the input (to the controller) timing could be even tighter! Faster is not always better.

it seems incredibly weird that the winbond chip seems to have a very narrow timing window of like 3ns.
it also begs the question, that if the inverted clock worked better for the winbond, should we continue using that clock, or go back to the tried and tested (original) TF536 timing..

I don't know what was the original T356 timing, but in general it depends on the frequency. For lower frequencies inverting the clock is better, Or at least is simpler. At higher frequencies you might need a more fine adjustment. Ideally you need a PLL to shift the clock to the optimal relation.

But, most important, you need to perform a timing analysis. At lower frequencies you can get along just by inverting the clock. At higher frequencies an inverted clock might produce setup timing violations. Probably (but again, only a timing analysis would tell), 100 MHz is too high for working with an inverted clock.

I look back through my previous conversations relating to the clock inversion, and I mentioned before that even "innocent" changes to the code seemed upset the SDRAM controller..

Yes, that's very possible. Unless you register all the DRAM signals (which is not always possible), your timing depends on the actual compilation result. That's why timing analysis and, if available, timing constraints, is so important.

[exxos]

Unless you register all the DRAM signals (which is not always possible), your timing depends on the actual compilation result.

I'll probably need a larger PLD to register them all which I'm trying to avoid. But as the compiler keeps changing timings every time something changes, it's near impossible to create a SDRAM controller which is "reliable".

I also suspect the 10ns PLD isn't helping and really needs a 5ns part. Preferably with a larger PLD so I can register the outputs..but ill end up messing about again with timings anyway, so not sure theres any point. it seems a lot of work and costs when it's all basically working now. But I think it's more of a fluke at this point it works.

I guess I will just have to do the experiment, 5ns 288, register all high speed signals, and compare to the 144 based code. See if the SDRAM works better or worse.

[ijor]

I guess I will just have to do the experiment, 5ns 288, register all high speed signals, and compare to the 144 based code. See if the SDRAM works better or worse.

Registering the signals will help with a more consistent compilation. But it won't necessarily fix the timing problem. It might even make it worse. It depends on which timing is your problem.

There are four timings involved in a SDRAM interface:

- Output Setup
- Output Hold
- Input Setup
- Input Hold

If you are working on an inverted clock, typically the problem is the input setup because it's the one that has the longest path. Registering the data input might help in this case. OTOH, if you are not working on an inverted clock, the problem might be the hold timing and registering might make things worse. Once again, that's why I'm saying that a comprehensive timing analysis is critical.

Also note that registering the signals change the design overall pipeline. When you register a signal it means that the output will be available one cycle later. It is not something that you can do blindly.

[PhilC]

just checking in now that the Simms and spacer have arrived and are fitted. I've also loaded the main_top.jed onto the chip.

It boots to Emutos but won't boot to ST536 TOS. It does the ST Ram test, goes a bit crazy with dashes on the TT ram test and gets as far as memory test complete and just stays there.

Neither TOS detects the CF card I have in it but I still have the Winbond ram installed and the Emutos version I have is 1.2.1 which is what I already had on the rom chip.

@exxos What would you like me to try next?

edit: BTW, to get the STe to boot I need to press reset once every time I power it up. It doesn't need the reset when running with a 68000

[exxos]

It does the ST Ram test, goes a bit crazy with dashes on the TT ram test and gets as far as memory test complete and just stays there.

Yeah the timing is off on the SDRAM which causes that. Normally I get garbage as the RAM amount.

edit: BTW, to get the STe to boot I need to press reset once every time I power it up. It doesn't need the reset when running with a 68000

Yeah I have to do that, think its because the reset cap needs changing.

@exxos What would you like me to try next?

I think its pretty conclusive now, that its not going to be a simple problem to fix :(

My only option is to move to the larger 288 and 6ns version and start again. But this is the reason I based everything on the TF536, as it was tried and tested. Just I wasn't aware how much of a problem even slight code changes would make. Everytime I compile, timings change, making it near impossible to solve. The 288 would help as it has more space and I can "Fix" some signals to be more constant. But this will likely changing timings to the point the whole SDRAM controller may need a re-write. Not something I can do myself.

I will get a couple boards made with the 288 to try it out, but if that's sulky right from the start, I will unfortunately just have to abandon the ST/STE536 project :(