REV 3 - REV 5 - The beginning (ST536)

[exxos]

I've been thinking it might just be monumentally easier just to run the CPU at 50MHz all the time. I was going to do that originally but changed my mind.

A quick hack up (no TTram sorted yet) gave these results.

IMG_4415.JPG (261.24 KiB) Viewed 686 times

IMG_4416.JPG (303.46 KiB) Viewed 686 times

[ijor]

I think I finally found the root cause. All the hacks I've done don't seem to matter anymore. ...
I've had to order a rather expensive scope as I believe my old one has been lying to me the whole time..

Very interesting, and intriguing. Don't keep us in the dark. What was the root cause and which kind of scope you are getting?

[exxos]

which kind of scope you are getting?

I'm getting a DHO924S. I need 4 channels and it's 250mhz. I think my 100mhz scope is missing some runt pulses.

[exxos]

TTram back working ..

But the odd side-effect is that the scores, in particular STram has dropped to 98%

IMG_4419.JPG (350.68 KiB) Viewed 645 times

Just a comparison this is what it was before with clock switching..

IMG_4313.JPG (403.29 KiB) Viewed 645 times

So slightly puzzled where the delay is coming from..

[Badwolf]

I've been thinking it might just be monumentally easier just to run the CPU at 50MHz all the time.

Even easier to have the memory run at 50MHz! (DFB1 )

BW

[exxos]

Even easier to have the memory run at 50MHz! (DFB1 )

Yeah I been thinking that as well. But the SDRAM isn't actually a problem at all.

[exxos]

Been trying to claw back the lost speed but I don't think it is possible.. The problem is there has to be synchronisation logic to the ST bus which causes overhead where running the CPU at stock 8mhz doesn't have..

So this was basically the end result...

IMG_4420.JPG (376.32 KiB) Viewed 606 times

At some point TTram appeared to run faster.. Is not down to any timing difference.. Only thing I could assume is that "bus turnaround time" is faster which is tainting the results, or BURST is running more efficiently.. Probably more of the test is running faster rather than the actual ram itself or something like that. Either way, cannot be bothered to investigate it.

IMG_4422.JPG (292.04 KiB) Viewed 606 times

I did run frontbench and it basically is "missing" about 400 frames.. So ST RAM being slower as they can rather a big hit

Some going to abandon running the CPU a constant 50 MHz, It just overcomplicates everything and ultimately ends up running slower anyway.

Still waiting for my new scope to come

[stephen_usher]

Would running the CPU at a constant multiple of the system clock, say 48MHz, allow the ST-RAM memory interface to run more quickly as the CPU and main system will always be in the same phase?

[exxos]

Would running the CPU at a constant multiple of the system clock, say 48MHz, allow the ST-RAM memory interface to run more quickly as the CPU and main system will always be in the same phase?

In theory yes..

Similar thing with my STE booster in fact.. 32MHz works well because it is in total sync with the motherboard.. I think I had to clock it something like 40MHz to compare to the 32mhz synced clock because of "overhead". The side-effect is TTram run will probably run a bit slower.

But one of the main problems is the very slow rise time on the ST clock... it would need a multiplying PLL to upscale the clock. But I think the ST clock bad rise and fall times are contributing to "clock skew" . Even with a buffer there would still be jitter.. which is in part where half of the problems are coming from I think...

Don't want to say too much about my current analysis because I'll probably have to write about 20 pages on it all.. I need my new scope to come so I can make better measurements first.. The conundrum is the 8 MHz system clock cannot be used as a reliable clock reference... Which poses a bit of a problem doesn't it.....

[stephen_usher]

Can the accelerator be used to generate the ST clock in some way, disabling the on-board clock generation?

I can't remember where the ST clock is generated... Is it the Glue?