exxos's DFB1 trials

[Badwolf]

Right, so the oscilloscope and I spent a great deal of time together on Friday night and Saturday morning. I got absolutely nowhere with this!

What I did was pushed my FPU right up until it failed with an Exxos RCO. It can pretty much do 30MHz bang on, but 30.2 it fails in the trig tests.

Then I made sure I had caps across all pins. 1uF ones too, rather than 100nF. Didn't seem to make any difference to anything on this board, but then this board was working beforehand.

Then started scoping. There were the normal high speed transients of up to 1V p2p here and there but nothing that seemed to co-incide with failures.

All VCC pins had a 100Hz mains hum, but I can't see that as being a huge issue.

AS and DS lines appeared clean, without any obvious ringing or bouncing. DSACK[x] looked to be handled via the CPLD correctly.

About all I can really think of doing now is putting vast swathes of electrolytic ballast on the board's main VCC input although I did briefly consider was that perhaps the 3V3 clock wasn't up to driving an FPU? Works OK with the CPU, but..? Well, it's one more thing I could test, I suppose.

Equally it is perfectly possible my chip does only work at 30MHz. I'm suspicous of just concluding that these days since I saw the marked difference between my board and Exxos' at 25.

I've branched off into a slightly different area now -- I'm going to default FPU to 16MHz and have the speed configurable in software to 16, OSC/2 or OSC. Obviously there's also the hardware option built into the board if someone wants to measure their FPU's maximum speed and fit an oscillator to exactly that.

Genuinely I might drop the FPU from rev 6 and go back to offering that flylead solution to those who want an FPU. The difference between a 16MHz 16 bit FPU and a 40MHz 32 bit FPU for the vast majority of users is undetectable anyway.

BW

[dml]

About all I can really think of doing now is putting vast swathes of electrolytic ballast on the board's main VCC input although I did briefly consider was that perhaps the 3V3 clock wasn't up to driving an FPU? Works OK with the CPU, but..? Well, it's one more thing I could test, I suppose.

If it is specified for 5v inputs you might well see odd/different behaviour with overlocking at 3.3v. At least, not to be compared apples-apples with overclocking on the mainboard which I assume is supplying a 5v clock. Maybe comparing the drop at the clock input pin for FPU in both locations would reveal something?

[edit]

One thing that could differ is the active clock pulse width interpreted by the chip, if the pulse is not neatly square at the top. more chance of switching logic near the top of the on-cycle so more likely to misinterpret a non-perfect signal.

[exxos]

Right, so the oscilloscope and I spent a great deal of time together on Friday night and Saturday morning. I got absolutely nowhere with this!

Welcome to my world :lol:

Then I made sure I had caps across all pins. 1uF ones too, rather than 100nF. Didn't seem to make any difference to anything on this board, but then this board was working beforehand.

As noted earlier, I think the capacitance is being squatted by the lead inductance of the tracks from the pin to the capacitor. It has little effect on the noise on the rail with overall amplitude. We should not theoretically be possible increasing the capacitance.

About all I can really think of doing now is putting vast swathes of electrolytic ballast on the board's main VCC input although I did briefly consider was that perhaps the 3V3 clock wasn't up to driving an FPU? Works OK with the CPU, but..? Well, it's one more thing I could test, I suppose.

I already tried bulk capacitance on the board..

Is possible 3.3V might not be up to the job.. Putting a schmitt buffer on it should rule all that out.

Equally it is perfectly possible my chip does only work at 30MHz. I'm suspicious of just concluding that these days since I saw the marked difference between my board and Exxos' at 25.

The only thing we could do is if you send me the FPU to try here to see if it behaves the same as the one I am using.

I've branched off into a slightly different area now -- I'm going to default FPU to 16MHz and have the speed configurable in software to 16, OSC/2 or OSC. Obviously there's also the hardware option built into the board if someone wants to measure their FPU's maximum speed and fit an oscillator to exactly that.

Genuinely I might drop the FPU from rev 6 and go back to offering that flylead solution to those who want an FPU. The difference between a 16MHz 16 bit FPU and a 40MHz 32 bit FPU for the vast majority of users is undetectable anyway.

I would hold off before starting doing any hardware revisions for the moment. I still have some things I want to try out.. But I'm a bit pushed for time this week as not going to be home for the next two days for starters :(

[Badwolf]

One thing that could differ is the active clock pulse width interpreted by the chip, if the pulse is not neatly square at the top. more chance of switching logic near the top of the on-cycle so more likely to misinterpret a non-perfect signal.

Hmm. Good point.

Equally it is perfectly possible my chip does only work at 30MHz. I'm suspicious of just concluding that these days since I saw the marked difference between my board and Exxos' at 25.

The only thing we could do is if you send me the FPU to try here to see if it behaves the same as the one I am using.

My chip didn't work AT ALL in your board before you started tinkering. I suppose if I sent you this one and it now started working it would at least prove one of your mods had done the trick.

...then which one was it? :)

Genuinely I might drop the FPU from rev 6 and go back to offering that flylead solution to those who want an FPU. The difference between a 16MHz 16 bit FPU and a 40MHz 32 bit FPU for the vast majority of users is undetectable anyway.

I would hold off before starting doing any hardware revisions for the moment. I still have some things I want to try out.. But I'm a bit pushed for time this week as not going to be home for the next two days for starters :(

Yeah, I don't plan to unless we decide we've found a killer bug. Might do another firmware spin, with these sof-registers, though.

BW

[exxos]

@Badwolf

I've been messing around for almost an hour with this bit of code which I was sure I had it working a couple days ago.

I was just trying to run DSACK from the FPU to the CPU via a clocked delay.. But no matter what I try the Falcon does not even tried to boot up afterwards :roll:

Code: Select all

wire DT2;
FDCP ff_666( .D( FPU_DSACK_INT | fpu), .C( CLKOSC ), .CLR(1'b0), .PRE( 1'b0 ), .Q(DT2) );
assign DSACK = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & DT2 & { FLASH_DTACK, 1'b1 } );

[Badwolf]

@Badwolf

I've been messing around for almost an hour with this bit of code which I was sure I had it working a couple days ago.

I was just trying to run DSACK from the FPU to the CPU via a clocked delay.. But no matter what I try the Falcon does not even tried to boot up afterwards :roll:

Code: Select all

wire DT2;
FDCP ff_666( .D( FPU_DSACK_INT | fpu), .C( CLKOSC ), .CLR(1'b0), .PRE( 1'b0 ), .Q(DT2) );
assign DSACK = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & DT2 & { FLASH_DTACK, 1'b1 } );

All those terms, bar FLASH_DTACK are vector types ( [1:0] ) so you need a...

Code: Select all

wire [1:0] DT2;

...and two flip-flops.

(just checked back to your old code and that oughtn't have worked either)

BW

[exxos]

@Badwolf Can with bodge wires the master OSC to the FPU clock somehow ? as mentioned above, I just want to rule out that it is not a actual clock driving problem next...

EDIT:

Nevermind worked it out :lol:

[exxos]

@Badwolf Sorry if this is sounding like the obvious/dumb here... But you do isolate FPU address from the motherboard somehow ? Just wondering otherwise the Falcon logic could be triggering FPU stuff if the motherboard sees the same address as well ?

[Badwolf]

@Badwolf Can with bodge wires the master OSC to the FPU clock somehow ? as mentioned above, I just want to rule out that it is not a actual clock driving problem next...

EDIT:

Nevermind worked it out :lol:

There's a dedicated oscillator spot for FPU, if you want to give that a go. You need to remove R18, though.

@Badwolf Sorry if this is sounding like the obvious here... But you do isolate FPU address from the motherboard somehow ? Just wondering otherwise the Falcon logic could be triggering FPU stuff if the motherboard sees the same address as well ?

The reason that fly wire is needed if you want to use the onboard FPU is that the FPU datastrobe isn't generated from the external bus, so the two can't fight if that's what you mean?

BW

[exxos]

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.