exxos's DFB1 trials

[exxos]

@Badwolf DSACK1 Has a lot of activity so difficult to know what cycles they belong to.

DSACK0 pulses twice slow, but this match is what is in the input of the PLD. So can likely say thats OK.

I need to find another scope probe with a tip which isn't snapped off :lol: :roll:

[exxos]

@Badwolf

DSACK0 input and output of PLD.

IMG_0196.JPG

DSACK1 input and output of PLD.

IMG_0197.JPG

IMG_0198.JPG

So looks fine to me.


Bizarrely the number seems to be relatively consistent to this all the time now. Sometimes it changes to a different number and stops there for a bit now :shrug:

IMG_0195.JPG

[Badwolf]

@Badwolf DSACK1 Has a lot of activity so difficult to know what cycles they belong to.

Yeah, you’d have to trigger on the FPU side. Dsack1 on the cpu side gets all the motherboard traffic.

BW

[Badwolf]

@Badwolf

DSACK0 input and output of PLD.


IMG_0196.JPG


DSACK1 input and output of PLD.


IMG_0197.JPG
IMG_0198.JPG


So looks fine to me.

Ah, well. There goes another theory. Thanks for indulging me. :)

You can see the difference between the 25MHz operation of the FPU and the 16MHz operation of the motherboard quite clearly there too. That’s reassuring.


BW

[exxos]

Ah, well. There goes another theory. Thanks for indulging me. :)

:lol: keep pressing and guessing :lol:

Going back to what I mentioned earlier about more noise on some databus pins. Those are the lower ones bits. I see you got 10k on them. As we out of options I could try lower values, maybe even add some 33pf caps on them to rule out noise. Though I can't see what else it can really be at this point.

[Badwolf]

Ah, well. There goes another theory. Thanks for indulging me. :)

Going back to what I mentioned earlier about more noise on some databus pins. Those are the lower ones bits. I see you got 10k on them. As we out of options I could try lower values, maybe even add some 33pf caps on them to rule out noise. Though I can't see what else it can really be at this point.

Yeah, nor why it would only happen on this board, nor why it would only affect the FPU.


There isn’t much else to try, though:

0C5DE38A-9D75-41EB-8CD0-40FB0D9B8536.jpeg

A0 and SIZE have been checked as high, IIRC.

I’m pretty sure we’ve both buzzed out A1-4.

Only really leaves the decode logic. Perhaps we should build a firmware with that AS dependency we were talking about?

BW

EDIT: long shot, but I don’t remember that I buzzed out RW.

EDIT2: Attached firmware that gates the FPU decode with AS.

[exxos]

@Badwolf I checked every pin last night :)

Falcon had to move to my "workbench" due to the USB cable isn't long enough to reach the floor :lol: No change with the firmware, but no surprise.

Maybe for the hell of it, run the FPU at 8MHz ? Slow the CPU to the same speed also during FPU access ?

IMG_0199.JPG

[exxos]

@Badwolf Just looking at the 68882 datasheet and states there is 80ns from DS to data actually valid. Also DSACK to data valid is 50ns. It quotes max times.. but I don't take those as gospel anyway.

1.PNG

2.PNG

EDIT:

I tried

Code: Select all

FDCP ff_fpu1( .D( FPUDSACK ), .C( XCPUCLK ), .CLR(1'b0), .PRE( 1'b0 ), .Q(FPUDSACK_2) );
wire [1:0] FPU_DSACK_INT = fpu | FPUDSACK_2 | FPUDSACK;

But seems to have made it worse :lol: It crashes on the first test now without displaying any numbers at all :roll:

[Badwolf]

Falcon had to move to my "workbench" due to the USB cable isn't long enough to reach the floor :lol: No change with the firmware, but no surprise.

Yeah.

Maybe for the hell of it, run the FPU at 8MHz ? Slow the CPU to the same speed also during FPU access ?

If you jumper OPTION2, you'll stay in 16MHz mode* -- the FPU will then run at 8MHz.

If you want to keep CPU and FPU in lockstep, I could generate another firmware tonight, ditching the half clock speed (FPUCLK = CPUCLK) or you could remove the FPU clock inline termination resistor R18 and bridge its western pad to the adjacent CPU clock inline termination resistor R19.

EDIT: I just spotted you'd built your own firmware, so changing the FPUCLK directly might be easiest.

Obviously that is unlikely to go well at 50MHz.

BW



* Technically motherboard speed, this could be set to 8MHz with the normal tools but the FPU would then end up at 4MHz.

[Badwolf]

@Badwolf Just looking at the 68882 datasheet and states there is 80ns from DS to data actually valid. Also DSACK to data valid is 50ns. It quotes max times.. but I don't take those as gospel anyway.

Given it's designed to share a common DS and DSACK[x] line with the CPU I can't see that it could be a problem, unless the clock differential is too much.

After all the FPU is intended to be run faster than the CPU. Here we're doing the reverse. I found (empirically) about half clock the most I could get away with -- going below CPUCLK/2 was unreliable. We would probably be taking out a variable by locking the two clocks, but it wouldn't explain why *this circuit board* is so senstitive.

BW