exxos's DFB1 trials

[Badwolf]

The current test is still with OPTION2 linked. Basically there does not seem to be any difference in driving the FPU directly from the master oscillator. 40MHz works as before, 50MHz fails on those for all five tests as it did previously.

If I remove the jumper link, (50mhz or 40mhz) .. just back to the usual garbage and crashes in the FPU test.

So, is this the current state of play:-

40MHz driving the FPU, CPU locked into 16MHz mode: success?
Any other 40MHz configuration: fail?

BW

[exxos]

So, is this the current state of play:-

40MHz driving the FPU, CPU locked into 16MHz mode: success?
Any other 40MHz configuration: fail?

Yes.

Though removing FPU From the speed up equation, would presumably run the CPU at 16MHz the same as what OPTION2 would be doing ? But that does not work :shrug:

[exxos]

Another observation - when running FPUTEST from TTRAM, it crashes on the first test straight away without any numbers.. May be a clue :shrug:

[Badwolf]

So, is this the current state of play:-
40MHz driving the FPU, CPU locked into 16MHz mode: success?
Any other 40MHz configuration: fail?

Yes.
Though removing FPU From the speed up equation, would presumably run the CPU at 16MHz the same as what OPTION2 would be doing ? But that does not work :shrug:

It would have to transition down into slow mode, which takes time.

Hence our experiment with delaying FPUCS.

Annoyingly I can't replicate this behaviour.

Another observation - when running FPUTEST from TTRAM, it crashes on the first test straight away without any numbers.. May be a clue :shrug:

Even with OPTION2?

I think we're going to have a build up a truth table with what configuration (firmware, hardware and jumper settings) is doing what, as I'm struggling to see a pattern ATM.

BW

[exxos]

Lost the plot now, IBS belly ache really bad out of the blue for no reason :( So no more tests tonight.

My last test was removing AS & FPU from the speed up line. Then it passes all the tests fine. So maybe another clue ?

Might be worth syncing the clock switching to only happen on the system clock high or something. Maybe even clock down to 8mhz. I know I've been through all this oddness before . I think the clock can glitch because AS can switch state while the clock switching is in progress. You would have to try and check to see what happens. It was something odd like when you switch clocks one way, you get like a "glitch" at 25mhz.. A 25mhz clock.. But OTOH , in tests years ago, it glitches by halfing the clock, so you end up with like a 100mhz clock.

Also my very first clock tests from decades ago also had these faults...

fault.png

[Badwolf]

My last test was removing AS & FPU from the speed up line. Then it passes all the tests fine. So maybe another clue ?

Would have to have a proper think on what that does. First instinct is it shouldn't work at all then unless OPTION2 were still jumpered.

Might be worth syncing the clock switching to only happen on the system clock high or something. Maybe even clock down to 8mhz.

This is basically what it does. On swich down, the clock is held high until the slower clock transitions low. That can mean one half cycle at down to 8MHz (4MHz if the mobo is running 8MHz mode).

Also my very first clock tests from decades ago also had these faults...

Glitching would crash the during heavy STRAM acces -- ie. most of the time. You have to go out of your way to run things in TT-RAM and avoid switching. The FPU didn't get switched, so no glitching there and the CPU in the stock firmare doesn't switch down on FPU access, so why would there be glitching there?

I don't think it's glitching.

BW

[exxos]

I did wonder that altram uses sterm, ROM I assume uses DTACK from the falcons own logic. Maybe some odd fault with dtack from the FPU gong via the PLD. But can't really think of any reason it would matter. I did try various hold offs. Like AS and DSACK had to be high as well, but made no odds.

Could it be some odd cache issue somehow ? Really running out of ideas.

Its like the CPU never sees DSACK, but they are both switching as tested previously. I can't imagine the PLD would cause significant delays..

I might trying FPU access from STOS to see if it gives any clues. It can handle bus errors in the editor.

[Badwolf]

I did wonder that altram uses sterm, ROM I assume uses DTACK from the falcons own logic. Maybe some odd fault with dtack from the FPU gong via the PLD. But can't really think of any reason it would matter. I did try various hold offs. Like AS and DSACK had to be high as well, but made no odds.

The only place I diverge from the datsheet app notes is on the CPLD-gated DSACK[x] lines. A final option is that we jumper the FPU_DSACK[x] and CPU DSACK[x] lines and work out some code to tristate DSACK[x] on the CPLD. Which would be the officially correct way of doing things.

I did it this way because I thought it was less likely to cause conflicts, but perhaps it's an issue in itself.

Could it be some odd cache issue somehow ? Really running out of ideas.

The FPU speaking to its co-processor is one of the more simple things on the system. Nothing else gets involved at all beyond the circuitry that generates the chip select so it can't be cache or OS or anything else. It works one way on one circuit board and other way on another. It's utterly bizarre.

Quick Q: of the four original caps on the back of your FPU socket, can you see (from size probably) which one is the 10uF versus the three 100n ones? I wonder if I've just got the layout different between the two boards.

BW

[exxos]

Quick Q: of the four original caps on the back of your FPU socket, can you see (from size probably) which one is the 10uF versus the three 100n ones? I wonder if I've just got the layout different between the two boards.

Can't check until I get back home. But I slapped loads more caps on so don't think it really matters.

I did slap a 1uf on top of the socket as well. It reduced the noise a bit more. But nothing significant. Still puzzled by the noise on some vcc pins. I mean its half a volt overall.

I wonder if the 5v was upped by a bench PSU to 5.5v if it would be more stable. May be those sockets are no good for high speed stuff. Or maybe the booster needs its own regulators powered from the 12v rail..

Lots of things to ponder about..

[Badwolf]

Quick Q: of the four original caps on the back of your FPU socket, can you see (from size probably) which one is the 10uF versus the three 100n ones? I wonder if I've just got the layout different between the two boards.

Lots of things to ponder about..

I'm just casting around trying to work out why one board behaves *so much* differently to another from the same batch.

If it simply failed altogether (which is what I thought it was doing), I could kind of accept it -- perhaps a random low-z pathway between a couple of traces or something, but the fact you were able to get it going again at all...

...it's very odd.