exxos's DFB1 trials

[exxos]

I'm just casting around trying to work out why one board behaves *so much* differently to another from the same batch.

If it simply failed altogether (which is what I thought it was doing), I could kind of accept it -- perhaps a random low-z pathway between a couple of traces or something, but the fact you were able to get it going again at all...

...its' very odd.

It's those magic bodge wires :lol:

[Badwolf]

Its those magic bodge wires :lol:

The bloody FPU didn't work before I tried to reflow everything and end up with those bodge wires!!

BW

[exxos]

The bloody FPU didn't work before I tried to reflow everything and end up with those bodge wires!!

:lol:

One more thought popped in my head which don't think mentioned ... Was when I was testing DSACK into the PLD, one of those lines causes it to crash on the first fpu test rather than garbage then crash. I don't know why that would be..

IIRC I increased the pull ups on them. Tried delays in the firmware , nothing made any difference. So something there is amiss which doesn't make sense.

Maybe the PLD doesn't like the 5v inputs for some reason on DSACK. Or its to noisey or something. I need to look into that more yet as well.

[Badwolf]

One more thought popped in my head which don't think mentioned ... Was when I was testing DSACK into the PLD, one of those lines causes it to crash on the first fpu test rather than garbage then crash.

OK, that's a material difference!

What do you mean by one of those lines caused it to crash, exactly? Just probing it?

BW

[exxos]

OK, that's a material difference!

What do you mean by one of those lines caused it to crash, exactly? Just probing it?

Yep. Doesn't make sense does it :lol:

I have some ideas to try out when I get back later tonight. I'm leaning towards running DSACK via the PLD doesn't work for some reason... No reason why it wouldn't work.. But something isn't right. My only guess is maybe there is some ringing and causing a glitch on them, maybe the long route from the FPU to the PLD is to blame. Only a wild guess but that's all we got to go on currently.

EDIT
Look at DSACKx
viewtopic.php?p=93441#p93441

EDIT2
viewtopic.php?p=93461#p93461
Even though the output of the PLD looks fine, the scope probe is enough to make it not work more. So the assumption that "its fine" can't be made. Also one screenshot doesn't represent "its fine" on all other transitions.

You would think you could sample lot of it on a LA to find the io error. But even the loading on the LA could be enough to taint results. Also the logic levels on the LA are not going to the the same as the PLD which can taint results. Then its impossible to really diagnose such problems. Even a different batch of PLD can cause different results.

So while this may not be THE fault. I think it does need fixing anyway.

[Badwolf]

OK, that's a material difference!

What do you mean by one of those lines caused it to crash, exactly? Just probing it?

Yep. Doesn't make sense does it :lol:

Very interesting. Did you probe on the socket?

The two pin header holes NNE of the CPLD marked 'for expansion use' are the FPU DSACK[x] lines exposed. Can you replicate the crashing on probing behaviour if probing at these points? Just to rule out bad contact on the FPU induced by probing the socket.

Ta.

BW

[exxos]

@Badwolf those exposed vias was where I had the probes. Was convenient to shove the probes into :D

I don't remember which one was sensitive though. But even the probe on x10 caused issues.

Likely I need to retest, then maybe see if I can add (roll the dice) on 100R series resistor on both lines.

[Badwolf]

@Badwolf those exposed vias was where I had the probes. Was convenient to shove the probes into :D

I don't remember which one was sensitive though. But even the probe on x10 caused issues.

Likely I need to retest, then maybe see if I can add (roll the dice) on 100R series resistor on both lines.

OK, that's good -- if it's a failure that was caused by probing a good solid base, far away from the FPU then that removes a lot of possible alternative causes.

Which reduces it to, AFAICT:-

1) Bad PLD pin junction -- possible, hand soldered after all. Could be worth reflowing that edge.
2) Bad PLD pin -- also possible, has happened before. We have spare pins we can test that with if 1) doesnt' work.
3) Unacceptable delay caused by routeing the signal via the CPLD. Harder to investigate as would need new firmware that supports driving CPU DSACK lines tristate.

But there is an obvious path to progress along now.

BW.

[exxos]

1) Bad PLD pin junction -- possible, hand soldered after all. Could be worth reflowing that edge.

I did beep them out and look under a magnifier and didn't see anything suspect.. But us both having similar issues...on the same pin.. on 2 different boards..

2) Bad PLD pin -- also possible, has happened before. We have spare pins we can test that with if 1) doesnt' work.

Again on 2 boards... There could be some odd internal routing oddness internally.. but I lean towards not. We likely have 10ns delay there.

3) Unacceptable delay caused by routeing the signal via the CPLD. Harder to investigate as would need new firmware that supports driving CPU DSACK lines tristate.

The delays were "almost" seen here.. viewtopic.php?p=93461#p93461 Granted 50ns/div but Likely around 10ns.

Even so.. I assume the CPU would just sit there all day waiting for DTACK to arrive anyway. So I lean towards its not a delay issue.

The low oscillations even though are not looking like they get anywhere near a logic high, doesn't mean the same elsewhere.. Maybe they do trigger a double pule on DSACK.. But also assume the CPU wouldn't care. But its still a point of failure which shouldn't be there.

But there is an obvious path to progress along now.

It *might* be an indication that slowing the CPU down helps. IE its a pause which lets the oscillations on DSACK die down before it continues the cycle termination.

Problem with that notion is that slowing down DSACK in the PLD with clocked delays doesn't help. But possible that logic function could be glitching as well. But generally running bad signals though a FF should help anyway. But can't assume that in every case.

[Badwolf]

I did beep them out and look under a magnifier and didn't see anything suspect.. But us both having similar issues...on the same pin.. on 2 different boards..

It's not two different boards.

My board works with the FPU at stock settings, yours didn't.

Whilst we're trying to look for any systematic issue with the FPU implementation, please don't lose track of the fact it's only your board that refuses to accept an FPU at stock settings.

Frank's board didn't like his 40MHz FPU which might imply there's an upper bound on the speed we can get out of the FPU in this configuration but my board did run happily with a 40MHz FPU until I blew it up plugging it in incorrectly.

Yours is the only board failing in this way.

BW

PS: this is why I can't actually do much in the way of testing here -- all I can try to do is maximise FPU speed, but I have no way of knowing what my FPU is capable of in a different system.