exxos's DFB1 trials

[Badwolf]

No stock in Mouser for the PLD and they like £50 a pop at that

I strongly suspect that was NOT a £50 CPLD.

Mostly because there have been hardly any in stock.

Oh well, let’s see if we can get board 5 working and give that one time to sit in the corner and think about what it’s done.

BW

[exxos]

Oh well, let’s see if we can get board 5 working and give that one time to sit in the corner and think about what it’s done.

Are we giving up with my board then ?

[Badwolf]

Oh well, let’s see if we can get board 5 working and give that one time to sit in the corner and think about what it’s done.

Are we giving up with my board then ?

It's been through the mangle, that one. It's got bodge wires and a borkey FPU interface. It's been through the post three times.

I think it might be time to consign that one to the back burner. Perhaps one day you'll fancy reflowing the CPLD or throwing a ton more of time at it, but I get the impression it's 'good money after bad' time with that one.

BW

[foft]

Reading the manual for the 68020 it specifies the circuit for FPU nCS in Figure 9-3. @Badwolf, why don't you use that exact logic in the CPLD? Perhaps worth a try? It has 3 terms using AS, CLK and CLKD, I only see AS in the github.

Edit: Also why mask dsack by fpucs? Aren't all DSACKs meant to be on a single bus, so any device can pull it low (active) - and the fpu will already only pull it low when selected. Might be better directly rather than via the CPLD, adding latency.

[exxos]

Reading the manual for the 68020 it specifies the circuit for FPU nCS in Figure 9-3. @Badwolf, why don't you use that exact logic in the CPLD? Perhaps worth a try? It has 3 terms using AS, CLK and CLKD, I only see AS in the github.

Can you post a link to that file as I am struggling to find a reference to the FPU in the 020 datasheet.

Edit: Also why mask dsack by fpucs? Aren't all DSACKs meant to be on a single bus, so any device can pull it low (active) - and the fpu will already only pull it low when selected. Might be better directly rather than via the CPLD, adding latency.

I think he is planning on removing the PLD out of the loop. It is likely there because the CPU can run a lot faster than the FPU. If the FPU keeps DSACK low for a "long time" the CPU could double read it. Though I haven't looked into the datasheet timings specifically. But it is likely there just as a matter of safety.

[foft]

https://www.nxp.com/docs/en/data-sheet/MC68020UM.pdf
p255-260ish

I guess the CPU doesn't start the next cycle while DSACK is held low by the FPU, though I'd have the check the timing details.

[exxos]

I guess the CPU doesn't start the next cycle while DSACK is held low by the FPU, though I'd have the check the timing details.

Not sure on the 030. Never needed to look really. Though DSACK is normally released after it sees /AS go high. So depending on if its pure logic, could be upto 50ns. Or even slower if its based on the CLK input.

[foft]

I guess the CPU doesn't start the next cycle while DSACK is held low by the FPU, though I'd have the check the timing details.

Not sure on the 030. Never needed to look really. Though DSACK is normally released after it sees /AS go high. So depending on if its pure logic, could be upto 50ns. Or even slower if its based on the CLK input.

I checked the 68020 manual and ...

i) nDSACKx negated is defined relative to nAS/nDS negated (num 28 in AC electrical characteristics table in 10-8). The table only defines up to 33MHz (in my boot at least!) At 50MHz. It looks to be about 1.25 cycles, which at 50MHz would be 25ns. i.e. the limit is that within 25ns of nAS/nDS negated nDSACKx must be negated.
ii) The CPU only waits on for nDSACKx assertion.


edit: 68030 manual update!
https://www.nxp.com/docs/en/reference-m ... 8030UM.pdf
https://www.nxp.com/docs/en/data-sheet/MC68030EC.pdf <- electrical characteristics with timing limits
28 is split into 2 sections: synchronous hold and asynchronous hold. It specifies at 50MHz 15ns (async), so pretty tight...

[Badwolf]

Reading the manual for the 68020 it specifies the circuit for FPU nCS in Figure 9-3. @Badwolf, why don't you use that exact logic in the CPLD? Perhaps worth a try? It has 3 terms using AS, CLK and CLKD, I only see AS in the github.

Is that the GAL example equation for 33MHz operation?

If so, yes, I've tried that, but it seemed redundant since it was for clocked GALs. I didn't get any benefit from it. Instead I based mine of Stephen's TF534 logic since that runs in a CPLD at 50MHz.

Bear in mind I only experienced one board that had absolute FPU failure and I (erroneously) put that down to bad socket. I've had no need (and no way to test) different FPUCS logic. Ultimately Exxos adding VCC capacitance got that board to work, BTW.

Edit: Also why mask dsack by fpucs? Aren't all DSACKs meant to be on a single bus, so any device can pull it low (active) - and the fpu will already only pull it low when selected. Might be better directly rather than via the CPLD, adding latency.

I've tried both (see previous picture with DSACK bodge wires and tristate DSACK[x] driver from the CPLC), but since I planned to run the FPU more slowly than the CPU I figured this would be a prudent modification to the logic to stop the FPU stomping on any following non-FPU cycle.

Like I say, only one of my builds has had an FPU problem and I found no solution in logic.

BW

[foft]

Is that the GAL example equation for 33MHz operation?

Yes that is the one I meant, I thought the CLK referenced was the CPU clock with sequential logic in the GAL. I didn't realize it was because its a clocked GAL.

I've tried both (see previous picture with DSACK bodge wires and tristate DSACK[x] driver from the CPLC), but since I planned to run the FPU more slowly than the CPU I figured this would be a prudent modification to the logic to stop the FPU stomping on any following non-FPU cycle.

So with the DSACK bodge wires did it make any difference to how fast you could run the FPU?