exxos's DFB1 trials

[dml]

However if I then remove the division on the FPU clock ( /2 ) then it seems to fail on some tests..

The tests which fail here are using some of the most complex FPU operations - more microcode, lots more gates, more power used. Dunno if that is significant but its two of the most cycle-expensive op groups there.

[Badwolf]

The tests which fail here are using some of the most complex FPU operations - more microcode, lots more gates, more power used. Dunno if that is significant but its two of the most cycle-expensive op groups there.

That's good to understand, thanks, Doug.

Bodging some extra capacitance on the four (two each side) VCC pins that don't have a directly attached cap should be easy enough. Might do that on my board and see if it affects my FPU's top speed.

BW

[exxos]

That's what I tend to see when it's overclocked. BUT the same chip will work at that speed in another board (or another machine).

Reckon it must be signal integrity. Probably control line as normal data exchanges work. But odd it changes so dramatically board to board.

Problem is if something is borderline, any sort of tolerances anywhere can screw the things up.. Mean changing the PLD could make it work, but does not necessarily mean the PLD is faulty. Its all the type of crap I am always up against with these machines :(

The tests which fail here are using some of the most complex FPU operations - more microcode, lots more gates, more power used. Dunno if that is significant but its two of the most cycle-expensive op groups there.

Good to know thanks. I think the power was a little noisy around the area but I was not using a ideal ground at the time anyway.

I have just put the FPU back in the Falcon MB. it passed all tests fine. So I am inclined to think that the FPU itself can operate at 16MHz fine. however when it is in the DFB1 Running at 16MHz it fails on those few tests.

@Badwolf I assume you're using a GND plane across the board ?

[exxos]

This test

Code: Select all

assign FPUCLK = CLKOSC; //CLKOSC_2

With OPTION2 jumpered.

Assuming CPU & FPU both running at 16MHz. It fails (again) like in this image viewtopic.php?p=93491#p93491

Removing option 2 - it just comes up garbage like in the first test them bombs. Granted this is ( I assume) 50MHz. But it does the same with 25MHz anyway.

But as the FPU run 16MHz fine in the falcon, I am currently shelving the idea that the FPU is in the problem at this point (but is not totally ruled out yet).

Moving onto the power rail (top left vcc pin) tested below.

IMG_0203.JPG

In fact all the top row VCC pins have similar on them. The bottom row of VCC pins still little noisy but nowhere near as bad.

[exxos]

I have slapped a couple of 10uF caps on the bottom... Notice the timebase is still the same...

IMG_0204.JPG

[Badwolf]

I have just put the FPU back in the Falcon MB. it passed all tests fine. So I am inclined to think that the FPU itself can operate at 16MHz fine. however when it is in the DFB1 Running at 16MHz it fails on those few tests.

@Badwolf I assume you're using a GND plane across the board ?

Yep, four layer with dedicated ground and power (abeit with a 5V side and a 3V3 side -- the FPU's as far from the 3V3 side as is possible, mind).

The only significant difference at 16MHz between onboard and external is the bus width. Perhaps that's not only more power hungry, but also finds itself on a daughterboard with a longer power routeing.


BW

[exxos]

Bringing out the big guns now :lol:

IMG_0205.JPG

IMG_0206.JPG

While the ripple is slowly improving it is not seemingly having any effect on anything :( Possibly the probe is picking up noise with it being physically close to the power supply but it is difficult to tell.

It is possible because the traces are relatively "long" on the decoupling caps that could be aggravating the problem.


This is the VCC pin near the top left of the FPU.

IMG_0207.JPG

Possibly it is dipping because that side is closer to the CPU.. I will slap a big cap on the back of that also just to rule it out...

[exxos]

Yep, four layer with dedicated ground and power (abeit with a 5V side and a 3V3 side -- the FPU's as far from the 3V3 side as is possible, mind).

The only significant difference at 16MHz between onboard and external is the bus width. Perhaps that's not only more power hungry, but also finds itself on a daughterboard with a longer power routeing.

Not sure I can see any significant bulk capacitance on the power input to the board ?

[Badwolf]

This test

Code: Select all

assign FPUCLK = CLKOSC; //CLKOSC_2

With OPTION2 jumpered.

Assuming CPU & FPU both running at 16MHz. It fails (again) like in this image viewtopic.php?p=93491#p93491

CLKOSC is what it says -- the osc frequency. Probably 50MHz!

You'd want FPUCLK = CPUCLK; if you're trying to lockstep them.

BUT that's actually quite good that you're seeing *some* results! So it probably is a 40MHz FPU. Don't suppose you've a 40MHz oscillator in your parts bin?

But as the FPU run 16MHz fine in the falcon, I am currently shelving the idea that the FPU is in the problem at this point (but is not totally ruled out yet).

I agree -- FPU works fine in my board, took it out and put it in this board and nada.

Moving onto the power rail (top left vcc pin) tested below.
In fact all the top row VCC pins have similar on them. The bottom row of VCC pins still little noisy but nowhere near as bad.

Mmm.

BW

[Badwolf]

Yep, four layer with dedicated ground and power (abeit with a 5V side and a 3V3 side -- the FPU's as far from the 3V3 side as is possible, mind).

The only significant difference at 16MHz between onboard and external is the bus width. Perhaps that's not only more power hungry, but also finds itself on a daughterboard with a longer power routeing.

Not sure I can see any significant bulk capacitance on the power input to the board ?

No, there are not electrolytics at all. Could be a sensible upgrade.

BTW, pins 52,53 and 16,17 are also VCC pins. I'd be tempted to add the extra capactitance across them and ground rather than to the pins that already have decoupling.

Bottom side of the board:-

fpu_top.png

...

fpu_bottom.png

BW