exxos's DFB1 trials

[exxos]

@Badwolf I think you got stuck at 25mhz ? I'll test another FPU and make sure it fails exactly the same and send it to you. Then if it still doesn't work then your board will likely has related problems .

[Badwolf]

@Badwolf I think you got stuck at 25mhz ? I'll test another FPU and make sure it fails exactly the same and send it to you. Then if it still doesn't work then your board will likely has related problems .

My current chip won't go past 30. My previous chip was happy at 40, but I blew it up. Those were both in this board and both with a CPU at 50MHz. 'Stock' is running the FPU at 25MHz and CPU at 50.

That's completely different to your symptoms of not being able to run 'Stock' at all.

I took the FPU that works 'stock' out of my board, put it into yours and yours would not run at 'stock'.

So there is a particular problem with that board. It's why I sent to you with an 'FPU not working' sticker on it. That's not a general problem.

Now, it could be there's a spectrum and that board is at one end and this board is somewhere in the middle and perhaps there's a board that will run my CPU at 40MHz. It's this that I'm hoping we can either establish or rule out, but we really aren't seeing the same symptoms.

I can probe FPUDSACK0 amd FPUDSACK1 without causing crashes and I can run without OPTION2 jumpered.

I'm happy to try a different FPU, but I'm really not sure I follow what this would be trying to test as, AIUI, your board still can't run without OPTION2 set. Is that correct?

I've not been able to replicate your failure mode on my board, I'm afraid.

BW

[exxos]

I'm happy to try a different FPU, but I'm really not sure I follow what this would be trying to test as, AIUI, your board still can't run without OPTION2 set. Is that correct?

No.. It will run fine at 40mhz if I remove AS from the clock switching function.

[Badwolf]

I'm happy to try a different FPU, but I'm really not sure I follow what this would be trying to test as, AIUI, your board still can't run without OPTION2 set. Is that correct?

No.. It will run fine at 40mhz if I remove AS from the clock switching function.

Oh shit -- I'd forgotten that. That's really odd.

Thinking about what that should mean: AS is only really there to qualify rom_access, ttram_access and fpu so I suppose it ought not really matter as they could only really erroneously trigger when AS were already high -- so that's a good optimisation, I think. It does look redundant. Perhaps I should invert that logic and explicitly detect motherboard access instead, for simplicity.

Which implies that we've probably freed up a block of CPLD space giving you a better fit.

Which implies timing, doesn't it?

So, have you made any other changes to the firmware? Does it work work as 'stock' but just with that one change to line 148?

https://github.com/dh219/DFB/blob/main/ ... 1r5.v#L148

Code: Select all

wire lowspeed = DISABLE_FAST & resetblock & ( ~ttram_access | ~rom_access | ~fpu ) & clockholdoff ; // low active (rom access here too)

... this, I presume?

Anyway, that's really very interesting and I can certainly see if doing the same here improves the clock speed I can get with my FPU, but it just serves to emphasise we're seeing different behavour. I suppose it could be that some timing constraint is being cut a bit fine and my board is 'just over' working threshold and yours is 'just under' it.

BW

[exxos]

wire lowspeed = DISABLE_FAST & resetblock & ( ~ttram_access | ~rom_access | ~fpu ) & clockholdoff ; // low active (rom access here too)
[/code]

... this, I presume?

The first test was with just ~ttram_access. That was the only change. Other than currently my FPU is hardwired to the 40mhz osc.. So you would need to change that line of code to run the FPU at CLKOSC.

I didn't keep any of the firmewares I did. They were all just throwaway tests, so didn't bother. but think those were the only 2 changes I did in the end. I did fallback to your code pretty much every time anyway.

I guess simple for you to try to see if you can hit higher FPU speeds. Though if these problems are only on my board and not in general, there probably isn't much point me spending time on it. I wouldn't use the FPU for anything anyway.

[Badwolf]

wire lowspeed = DISABLE_FAST & resetblock & ( ~ttram_access | ~rom_access | ~fpu ) & clockholdoff ; // low active (rom access here too)
[/code]
... this, I presume?

The first test was with just ~ttram_access. That was the only change. Other than currently my FPU is hardwired to the 40mhz osc.. So you would need to change that line of code to run the FPU at CLKOSC.

Ahh. So this?

Code: Select all

wire lowspeed = DISABLE_FAST & resetblock & ( ~ttram_access ) & clockholdoff ;

That would lead to accleration ONLY during TT_RAM access so slowing for FPU, Flash etc. Flash doesn't make any difference as it's not installed on your board.

AH WAIT. I missed a vital part there. Without AS in there qualify those other terms, your CPU is running slowing *between* every bus cycle too.

So basically you've got a fancy version of OPTION2 there. Slow all the time *apart from* TT-RAM access.

So actually we're still no better off. :(

I guess simple for you to try to see if you can hit higher FPU speeds. Though if these problems are only on my board and not in general, there probably isn't much point me spending time on it. I wouldn't use the FPU for anything anyway.

Yes, would be simple enough, although mine seems to crap out at 30MHz with OPTION2 set or not, so I doubt this would help as it's not what I initially thought it was.

I'm sorry if I didn't make it clear, although I have tried to. This board in particular had problems with the FPU.

The story goes: I had five boards:

1. I gave one away.
2. I built one for Frank (on camera) which worked when I had it here, but got damaged in shipping. Robert (@12-MHz) fixed it up. He did run into problems with FPU speeds there, which is perhaps why I caused confusion earlier on by mentioning others having problems (but not the same problem).
3. I built this one and the FPU didn't work. I ended up damaging the CPU socket trying to reflow it so rejected it and...
4. ...built a fourth. That worked well and is the board I use now.
5. I've lost track of the fifth board -- I can't remember if I gave it away before I realised I had a rejected build, broke it or have simply lost it.

Anyway, the fifth was meant to be for you, but since I don't have a fith, I went back and salvaged board two for you. The FPU was still not working even after I fixed up the CPU socket with the bodges.

I tried to explain the FPU never worked for me *on that board* when I sent it and if you could get it to, it'd be really useful to know how, because *perhaps* it'd be information useful to improve top FPU speed on the other builds. I thought we'd cracked that nut with the capacitors, but it doesn't look like it.

So that's where we are now. Unfortunately it looks like your board only really works with the CPU running in slow-mo.

BUT if you've got a FPU_DSACK line sensitivity, it could still be fixable -- that's potentially the cause of that board's problems.

BW

[exxos]

So basically you've got a fancy version of OPTION2 there. Slow all the time *apart from* TT-RAM access.

So actually we're still no better off. :(

The CPU would run at 16MHz and setup the FPU at 16MHz, but the FPU itself is still running its internal calculations at 40MHz. The CPU is just slower setting up the FPU and obtaining the result. On that basis, running the CPU at full speed shouldn't make any difference. But it does.

[Badwolf]

So actually we're still no better off. :(

The CPU would run at 16MHz and setup the FPU at 16MHz, but the FPU itself is still running its internal calculations at 40MHz. The CPU is just slower setting up the FPU and obtaining the result. On that basis, running the CPU at full speed shouldn't make any difference. But it does.

Yes, this is the same as fixing the FPU speed and holding OPTION2. The key thing has seemed to be the CPU speed in all this.

But if you've got a flakey FPU_DSACK[x] line, that's a (potentially) easy fix.

If reflowing doesn't work, then we can route to one of the spare pins (jumper from the expansion pins to the spare pin breakout headers ENE of the CPLD & change the UCF file to look for the FPU_DSACK[x] pins at a different location).

BW

[Badwolf]

EXPERIMENTAL FIRMWARE! @exxos

This takes the DSACK[x] lines high-Z when the FPU is decoded.

Idea is to connect FPUDSACK to CPUDSACK lines directly and take the CPLD out of the equation.

My system boots up with this, but doesn't pick up the FPU (this is expected).

I'm off to get the soldering iron out. :)

BW

[exxos]

EXPERIMENTAL FIRMWARE! @exxos

Seems worse :(

Did you change your git files over the past couple of days, some of the code looks different now...and OPTION2 no longer works :roll: