DFB1 FPU experiment thread

[foft]

I finally got round to trying some initial checks.

So far I've just done this, on two boards:
i) 0.1uF on the bottom of the FPU (as per previous BW post)
ii) Removed R18. Connected X2 to pin 23 of the expansion connector (CPU clock).
iii) Verified that I'm using release 1.0 of the CPLD firmware.
iv) Tried swapping FPUs from 4 tested by exxos
v) Removed the internal FPU from the board, on the off-chance that interferes somehow (unlikely, would be no CS I guess!)
vi) Resoldered all the CPLD pins again, using a little more solder and a lot of tacky flux!

One of the boards (that one that passed ONCE) seems to fail on the 3rd instruction. The other board fails always on the 1st instruction.

Not FPU related: Also soldered on the two 29F800 chips and those are working well.

FPU_EXPERIMENT_CPUCLK_WIRE_TOP.JPG

FPU_EXPERIMENT_CPUCLK_WIRE_BOTTOM.JPG

[foft]

Next I'm going to try two things BW tried before:
i) Using the internal FPU instead with https://github.com/dh219/DFB/blob/v1.0/ ... _hack.jpeg
ii) Capture FPU CS, FPU CLK, CPU CLK and DSACK on the logic analyzer.

I see on the schematic and PCB J8 that you break out unused CPLD pins P50,P61,P106 and P110. I'm going to wire that header up so I can capture a few other choice things by recompiling the firmware.

[Badwolf]

You're putting extra load on XCPUCLK -- I had meant driving the main oscillator with that pin rather than the FPU, but never mind. You are also driving it through the inline termination resistor there. Quite a few variables to look at.

To simplify things even further I might consider the following:-

* Use OPTION2 to force the CPU clock to 16MHz. jumper the CPU's clock input pin and the FPU's clock input pin directly together.

You're then running both in lockstep and considerably below their ratings. Absolute base conditions to start from.

Not FPU related: Also soldered on the two 29F800 chips and those are working well.

That's good news at least! :)

BW

[Badwolf]

Next I'm going to try two things BW tried before:
i) Using the internal FPU instead with https://github.com/dh219/DFB/blob/v1.0/ ... _hack.jpeg

Let me know how that goes -- it worked a treat for me, but I tried to get greedy with a 32 bit 40MHz CPU. ;)

It ought to be a tri-state driver really. If you going to program up those J8 pins, perhaps configure one as an open drain DS signal for this purpose?

Something like:

Code: Select all

assign P106 = DS ? 1'bz : 1'b0;

And, obviously, don't leave the external FPU in place at the same time!

BW

[foft]

The FPU hack isn't working for me, perhaps I made a mistake.

I connected nDS on the 030 here, then to a 20ohm resistor then to pin 3 of U62. Sysinfo shows no FPU and fputest bombs straight away. I removed the FPU on the DFB1.

FPU_EXPERIMENT_nDS.JPG

[foft]

To simplify things even further I might consider the following:-
* Use OPTION2 to force the CPU clock to 16MHz. jumper the CPU's clock input pin and the FPU's clock input pin directly together.
You're then running both in lockstep and considerably below their ratings. Absolute base conditions to start from.

This one works :D

Now to get the CPU to also run faster than 16MHz at the same time.

Edit:

You're putting extra load on XCPUCLK -- I had meant driving the main oscillator with that pin rather than the FPU, but never mind. You are also driving it through the inline termination resistor there. Quite a few variables to look at.

BTW I also tried removing R1 from the loop of the direct from pin 23 case - no change in that case.

[foft]

I just wired up to the logic analyzer:
FPU clock
FPU cs
FPU dsack0
FPU dsack1
CPU dsack0

The first thing I noticed is that I'd make a mistake in locking them both to 16MHz with option2. The CPU was 16MHz but I'd connected the FPU back to 25MHz by mistake!

The second thing is that I see both 16-bit and 32-bit accesses.

The third thing is 6ns latency from fpudsack0 drop-> dsack0 dropped and 8ns latency from fpudsack0 raise -> dsack0 raise.

These captures are with 16MHz CPU and 25MHz FPU (the case that works). I probably should have grabbed AS or DS and CPU dsack1 too in hindsight!

option2_25MHz_fpu.png

dsack_latency.png

[foft]

At 50MHz CPU, 25MHz FPU I see it seems to retry 4 times (it fails on the first test).

50MHzCPU_25MHzFPU_4_tries.png

Each try looks like this...

first_attempt.png

[foft]

One more to contrast with the same first in the working case (16MHz CPU, 25MHz FPU):

first_attempt_working_16MHz_25MHz.png

[foft]

Adding on cpu dsack1 and cpu as/ds. So more of the cycle timing can be seen.

Here is the 16MHz cpu, 25MHz fpu case (working):

with_strobes_16_25.png

Here is the 50MHz cpu, 25MHz fpu case (not working):

with_strobes_50_25.png