DFB1X FPU Error

[whomper]

Hi,

Just installed the DFB1X 50MHz and am consistently getting a fbcc:drand error as seen in the attached image. I've run the FPU test multiple times and am always this single error.

Any hints?

IMG_9856.jpeg (96.42 KiB) Viewed 2083 times

[exxos]

That's really odd. All the FPUs are tested twice and for some hours. I would suggest carefully reseating the FPU.. But be warned that the sockets are fragile and can can break if your not careful. Also check the voltage on the DFB1X power pins next to the "DFB1X" text. Failing that you may have to return the FPU to me to retest it.

[whomper]

The first 1-2 tests when the Falcon is cold passes, but then every following test fails in the same step. I've inserted the previous FPU I had but that generated many more failures, so not a good option.

Inserting the FPU back, I get the same error in the same place.

Voltages are 5.049v and 3.29v measured on the DFB1X board.

What is the real world impact of this single error?

[exxos]

What is the real world impact of this single error?

I'm not sure it's really possible to answer that question.. It really depends on what programs are used, if they even use the FPU or not, or if they do, if they use that function and what for.. There is no way for anyone to really know. As most programs don't use the FPU anyway, the impact regardless is probably small.

[dml]

What is the real world impact of this single error?

Difficult to say - especially for this particular test.

Its purpose (fbcc) is to test the FPU's condition codes / conditional branching - so the result of a calculation can be used to decide what to do next. This is kinda important as a feature - although not all code doing FP math needs to make decisions... so YMMV.

However ... I also found this particular test would fault at 50MHz on some FPUs but not because of the condition codes it was intended to test - it was faulting because of something happening towards the end of the test loop when the last condition skipped a block of code.

I couldn't figure out if it was a fault from overclocking, or a bug in the mask revision. The fault I found was a register-writing race near the end of the test.

That means two instructions are trying to write/memory-load to the same FPU register at slightly different times, but the results are completing at about the same time and there is only one winner. This shouldn't be possible on 68k chips but this is a weird special case on an FPU which probably didn't do this in real programs - or could perhaps be a documented bug in that mask revision for the 882.

If this is the case, it's possible the 'race' will show at 50MHz but not at 40MHz because the completion time for the two competing instructions is affected by other things - like RAM access times. That would mean the chip is 'working' at 50MHz but the mask bug is just showing up in that config, in that code.


....or it could be 100% down to overclocking the thing and causing a bug in register waitstate handling on the chip.

You decide


This explanation ONLY applies to the fbcc test and it's a special case. If any of the other tests start failing - it's an overclocking fault.

The ones which tend to start failing first at 50MHz are these. Some others can fail but typically these are more 'sensitive' to OC-induced chaos.

- fbcc
- ftrigh
- fxtoy
- fsincos

You can get the latest testers from my site at the link below.

[edit]

Sorry, forgot I don't have a default sig on this forum. Link below.

http://www.leonik.net/dml/sec_atari.py

[whomper]

Thanks @dml for the detailed explanation. I also wasn't aware that I've been playing Doom for the past few weeks from your version

If I understand correctly, some FPU exhibit this due to internal race condition with competing requests due to higher bus speed. As this is the single and only fault (confirmed by the two 2 test apps on your site), it might be just that.

BTW, the links for NEMBench and DSPBench are broken.

[dml]

Thanks @dml for the detailed explanation. I also wasn't aware that I've been playing Doom for the past few weeks from your version

There's an update for that coming soon too!

If I understand correctly, some FPU exhibit this due to internal race condition with competing requests due to higher bus speed. As this is the single and only fault (confirmed by the two 2 test apps on your site), it might be just that.

Yes that's my reading of it, more or less.

I'm not 100% sure yet that it isn't an OC fault - It doesn't seem to occur on all FPUs tested - but if its the only test failing and its consistent and you're not seeing other problems, chances are it's just the same race condition I saw when I looked into it myself.

BTW, the links for NEMBench and DSPBench are broken.

Oops - thanks for letting me know. I'll get it fixed this week when I update things again.

[exxos]

I just kind of assumed that more transistors and logic would be used on those tests and overclocking would strain things more so than other tests.

But I still don't understand how he can end up with a bad FPU anyway because they are on for literally hours and I even heat them up. Both CPU and FPU are then again tested in the full DFB1X for a second time. If they fail within a couple of seconds of being heated up then they are binned into the 40mhz pile for retesting again at the lower speed. They are even tested in the adapter which isn't exactly giving them a good ground either. So they actually have an easier life in the final DFB1X.

So either he has been incredibly unlucky with that FPU, or the voltage is a factor, or something else going on. There is only so much testing which can realistically be done and I don't believe there is anything else I can test. I bet a lot of sellers don't even test them at all and just drop ship them as is.

A new FPU has been sent out anyway today. That one was on all day. If it still doesn't work then it's likely his power supply, maybe just borderline too low voltage for it to be stable. I generally test with 5.15v on the DFB1x. But I cannot say if voltage is a factor on the FPU or not, I know it is on the CPU.

[kohli79]

BTW, the links for NEMBench and DSPBench are broken.

Have you checked it yet? Unfortunately, the links still don't work.
I have NEMBench V2.1 and DSPBench V1.0
What's changed in the new versions? Code optimizations?
Thanks.

Regards, Uwe

[dml]

Have you checked it yet? Unfortunately, the links still don't work.

Yeah maybe I should fix that today and post an update.

I have NEMBench V2.1 and DSPBench V1.0
What's changed in the new versions? Code optimizations?

The changes to the tools are not new I just didn't distribute them very well at the time - I linked the existing last versions. Or attempted to :p

i don't remember offhand what was changed but will have a look. NEMBench probably has some extra tests for F030/TT...

(I expect to be updating them again soon, now that i have more machines to try)