REV 3 - REV 5 - The beginning (ST536)

[exxos]

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?

MMU.. but the ST doesn't like it when clocks start going out of sync with other stuff.. Its why I tried 50mhz experiment as it doesn't use the clock at all really then. But that's a whole other can of worms..

Currently im creating a "internal" 8mhz clock which has a "poormans" PLL to keep it in some sort of sync with the ST clock.. it works.. but sure ain't pretty..

[stephen_usher]

I guess that "assuming the crystals are accurate" you could start your internal 48MHz clock triggered by the first system clock pulse after reset and then run your own 8MHz clock as a divided version of your internal master clock and let it run free after that.

[exxos]

I guess that "assuming the crystals are accurate" you could start your internal 48MHz clock triggered by the first system clock pulse after reset and then run your own 8MHz clock as a divided version of your internal master clock and let it run free after that.

It would drift out of sync without constant checking on the master 8MHz. Thats part of the problem I have already. Only a bit more complicated as 100mhz doesn't divide well to 8mhz :lol:

Ive had it running YAARTTT overnight in the new test setup and it's passed. Kinda suprised it worked. But then again it worked before and was still unstable. But it was more thermal related causing issues last time..

[stephen_usher]

It would drift out of sync without constant checking on the master 8MHz. Thats part of the problem I have already. Only a bit more complicated as 100mhz doesn't divide well to 8mhz :lol:

Bah! You are just making it more complicated for yourself... stick a 96MHz crystal in there! 4% CPU speed drop is nothing when most of the time you're waiting for the ST to catch up. :-)

Seriously though, having the CPU clock be a multiple of the system clock may make the overall performance a bit better as the two buses will be more in balance and you won't have variable wait states all over the place. It may make the logic a lot easier too.

I wonder if you could resync the clocks at the start of every bus cycle which accesses the ST hardware. In that way the accelerator can run free whilst it's not worried about the ST hardware. Should also help make it more deterministic.

[exxos]

Bah! You are just making it more complicated for yourself... stick a 96MHz crystal in there! 4% CPU speed drop is nothing when most of the time you're waiting for the ST to catch up. :-)

Overclocking is next ;)

Seriously though, having the CPU clock be a multiple of the system clock may make the overall performance a bit better as the two buses will be more in balance and you won't have variable wait states all over the place. It may make the logic a lot easier too.

I wonder if you could resync the clocks at the start of every bus cycle which accesses the ST hardware. In that way the accelerator can run free whilst it's not worried about the ST hardware. Should also help make it more deterministic.

Problem is the same.. 8mhz clock has, for a better term, "random jitter". I'd assume signals are clocked events, so it wouldn't matter what signal is used..

8MHz jitter on the CPU clock doesn't seem to matter in my tests so far.. The ST doesn't seem to care.. But the PLD timing does care based on the ST 8mhz clock.

Basically you can't use the ST clock as a gospel timing reference.. Its to unstable. You can use it as a rough indicator, that's what I'm doing now... It creates jitter but there's not many other options anyway. The TF designs have clock jitter anyway by how it works.. So it's nothing exactly new..

[stephen_usher]

I was thinking more that the PLD holds its own 8MHz clock until it sees a rising or falling (depending upon what you need to trigger on) clock from the ST at the beginning of an ST bus transfer. In this way the two clocks probably wouldn't diverge much anyway. The PLD's primary clock would be the 96MHz one which would be stable and the internal 8MHz clock would be derived from this, just synchronised to within 1/12th of the ST clock.

i.e.
Start ST access:
Stop internal 8MHz clock.
Wait for ST clock to rise/fall.
Start internal 8MHz clock.
Do ST bus transfer
End ST access.

This means that the clocks are only synchronised when they need to be.

P.S. this would have a maximum skew between the ST clock and internal 8MHz clock of 10ns, plus any delays inside the PLD, during the ST bus cycle.

[exxos]

I was thinking more that the PLD holds its own 8MHz clock until it sees a rising or falling (depending upon what you need to trigger on) clock from the ST at the beginning of an ST bus transfer.

It sort of does that currently.. It just synchronises to the falling edge of the ST clock as its the "best" signal to use. The PLD just struggles because I end up with like 8.2mhz, but after its gets chopped about a bit, its not really making much difference anyway.

IMG_4426.JPG

Considering the ST clock is pretty unstable and adding jitter plus the recreated clock also adding jitter.. And trying to synchronise them up together in something half sensible ... I don't think is done too badly overall..

At least this way, the PLD has a clean 8mhz clock to work with and its in sync with the CPU and internal logic as its all generated from the same clock source.

It was running all day and all night...

IMG_4424.JPG

[ijor]

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.

In theory the CPU interface, the 68000 bus protocol, is completely asynchronous. This is by design and if you check Motorola manuals, it explicitly mentions that the CPU can run on a completely independent clock. For this purpose the CPU has all the control signals properly synchronized.

But the chipset is not really designed for this purpose. Signals are not so well synchronized, and e.g., MMU expects the CPU to be more or less synchronized and follow the "standard" timing. E.g., even the latch strobes (UDS & LDS) are used asynchronously, MMU will not wait if the CPU delays too much when driving the bus on a write transaction. It actually can't wait because the bus is shared and interleaved with video access. Or if the CPU is too fast, it might violate setup timing on the chipset.

Even if it works, there is some risk of meta stability because the chipset doesn't have a synchronization chain (as the CPU does have). As I said before, meta stability is a very rare event. But that means it can run ok for a full day, but still fail, say, every other day.

[exxos]

It's pretty odd because if I run the original TF code at 8mhz fixed, STram ends up at 78%. However, if I run my new clock switching code he now ends up at 92%. I cannot get it to go any higher so this could just be down to the 030 itself now.

But there lies the problem, of why all my scores still slower than the original TF code scores. I'm wondering if I am being fooled somewhere along the line and for some reason TTram is more efficient somehow, and its upping the test scores because the tests themselves are running faster rather than their actual STram.

So is not that the STram is 98%, it's actually faster than stock TF 78%, of mine at 92%, and GB6 loops are running more efficient giving the bump to like 116%. I suspect there's some BURST or cache related shenanigans going on.. It's difficult to pin point..

This is my current 8MHz baseline test.

IMG_4433.JPG

This one is with just 50mhz only when AS30 is high (better cache speeds)

IMG_4435.JPG

Actually surprised it got as high as 102% that time :shrug:

Next to get TTram back running...

IMG_4436.JPG

Next I need to mash this code base up for the 50 MHz tests again...

[stephen_usher]

I know from when I was getting ground bounce on my relocator board that missing only one clock cycle now and again will decrease the ST-RAM score by ~2%. It doesn't take much to upset the apple cart.