DFB1 FPU experiment thread

[foft]

Not sure I can see what is wrong. Perhaps I should de-assert nCS when nAS is de-asserted. Also perhaps I could register nCS in case there are some glitches that I can't see on the logic analyzer.

Will try them next time I get some time on this...

[exxos]

Looks like there's a double pulse on DSACK on the not working one ?

[Badwolf]

Hmm. I'd have to digest these a bit, but I did make a mod to board 4 to remove the CPLD from the DTACK equation.

If you're worried about bouncing (although I think the inputs are Schmitt triggered) or the latency, then you could try this.

The DTACK[x] lines need to be tristated instead of driven when FPUCS is active, then the FPU_DSACK[x] component of the assignment needs to be removed and then the DTACK[x] lines joined physically.

I should say it made no odds to the speeds we could run at, but it might be worth a go.

BW

IMG_6011.jpeg

[Badwolf]

The second thing is that I see both 16-bit and 32-bit accesses.

This is one thing that surprised me, but is quite normal. Some operations assert one, both or other DSACKs in 32 bit mode.

The third thing is 6ns latency from fpudsack0 drop-> dsack0 dropped and 8ns latency from fpudsack0 raise -> dsack0 raise.

This seems reasonable and I don't think ought to be a problem unless we're seeing cycles crashing into each other.

These captures are with 16MHz CPU and 25MHz FPU (the case that works). I probably should have grabbed AS or DS and CPU dsack1 too in hindsight!

So this is with the faster FPU and slower CPU.

For the 50MHz tests, can you confirm the CPU clock is slowing during FPU accesses? Latest firmware should do that, I believe.

It can also be trivially changed to not do that by fiddling with the lowspeed wire, IIRC.

Also I'd be interested how it behaves if the input to the clock switching module were changed to CLKOSC_2 instead of CLKOSC, so they're both at 25MHz.

BW

[foft]

I was just looking at the v1.0 tagged verilog at the low speed logic you mention.

Code: Select all

// we don't allow switching from slow back to fast for two clock cycles after XDTACK -- this gives full ST ram access speed for negligible TTRAM overhaed
wire [1:0] xdtack_delay;
FDCP ff_xdtack1( .D( XDTACK ), .C( ~XCPUCLK), .CLR( 1'b0 ), .PRE( 1'b0 ), .Q(xdtack_delay[0]) );
FDCP ff_xdtack2( .D( xdtack_delay[0] ), .C( ~XCPUCLK  ), .CLR( 1'b0 ), .PRE( 1'b0 ), .Q(xdtack_delay[1]) );
wire clockholdoff = &xdtack_delay[1:0];
wire lowspeed = DISABLE_FAST & resetblock & ( AS | ~ttram_access | ~rom_access | ~fpu ) & clockholdoff ; // low active (rom access here too)

+ for reference, the fpu parts:

Code: Select all

wire fpu = {FC,A[19:16]} != 7'b1110010; // co-processor decode
wire [1:0] FPU_DSACK_INT = fpu | FPUDSACK;
assign FPUCS = fpu;
assign DSACK = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & FPU_DSACK_INT & { FLASH_DTACK, 1'b1 } );

I'm curious, why do you reduce the clock rather than have the automatic wait states? Is this a performance optimisation, or it increased stability in some cases?

I'm out today, but I agree trying to not fiddle the clock on the fpu access seems worth a try.

[foft]

I see what you mean, in main on github you have the lowspeed slowing the clock for the fpu access and the register for a whole bunch of settings.

I made a more minimal change based on it to try this:

Code: Select all

diff --git a/DFB1/ise/dfb1r5.v b/DFB1/ise/dfb1r5.v
index 343b23a..4412dab 100644
--- a/DFB1/ise/dfb1r5.v
+++ b/DFB1/ise/dfb1r5.v
@@ -145,7 +145,7 @@ FDCP ff_xdtack1( .D( XDTACK ), .C( ~XCPUCLK), .CLR( 1'b0 ), .PRE( 1'b0 ), .Q(xdt
 FDCP ff_xdtack2( .D( xdtack_delay[0] ), .C( ~XCPUCLK  ), .CLR( 1'b0 ), .PRE( 1'b0 ), .Q(xdtack_delay[1]) );
 wire clockholdoff = &xdtack_delay[1:0];
 //wire lowspeed = DISABLE_FAST & resetblock & fpu & ( AS | ~ttram_access | ~rom_access ) & clockholdoff ; // low active (rom access here too)
-wire lowspeed = DISABLE_FAST & resetblock & ( AS | ~ttram_access | ~rom_access | ~fpu ) & clockholdoff ; // low active (rom access here too)
+wire lowspeed = DISABLE_FAST & fpu & resetblock & ( AS | ~ttram_access | ~rom_access ) & clockholdoff ; // low active (rom access here too)

Now I do see the clock slowing down for the fpu access, however the fpu access fails.

This is interesting to me since this is basically the same as the working case in that the cpu is running at 16MHz and the fpu at 25MHz during an FPU access.

[Badwolf]

The idea of slowing the clock was merely to get things into a 'known good' configuration (where FPU clock is faster than CPU clock) and hopefully ameliorate concerns over chip select, or DSACK delays. By the CPU working more slowly than the FPU a delayed or prolonged DSACK would hardly be an issue.

I've never seen any difference in the effect on FPUs with it either way, so left it in as a belt and braces.

Yes, the 'cutting edge' dev has started adding writable registers. It should be possible to configure, amongst other things, FPUCLK on the fly (16, OSC/2, OSC).

I'd advise using the verilog from the 1.0 release for testing as why stack unknowns on unknowns?

BW

[foft]

Thanks.

Since it works in 'constant' low speed but not 'accessing fpu' low speed I tried to extend the period for the slow fpu access, to see if that helped. It didn't, but I'm not sure I did the logic right, so should revisit.

Then I killed a 68030 - in system flashing, which I'd done a lot without issue but this time it didn't like it:( I've just ordered a couple more (to replace that + spare) + a 40MHz and 48MHz crystal to see if it works with the 68030 slightly slower.

I tried running the CPU at CLKOSC_2 and the fpu then works. So 25MHz CPU + 25MHz FPU is ok.

Also 25MHz CPU and 50MHz FPU is passing (sometimes trig fails).

50MHz CPU and 50MHz FPU fails though (on first few fpu instructions).

33MHz CPU and 33MHz FPU fails partway through(with 66MHz xtal/2 in cpld - fails on fbcc/*rand)

16MHz (i.e. option 2) CPU and 33MHz FPU passes

16MHz (i.e. option 2) CPU and 50MHz FPU passes (sometimes trig fails).

25MHz CPU and 16MHz FPU (via cpld) passes

50MHz CPU and 16MHz FPU (via cpld) fails (on first few fpu instructions)

I was hoping to divide the clock by 1.5 using https://www.mikrocontroller.net/attachm ... l33_30.pdf. While it works the duty cycle is nothing like 50%. So to try other frequencies before getting the xtals will need to wire up a clock generator.

[foft]

Wired up my DE1 to generate a range of clocks with its pll.

Since 25/25 was stable, now progressively increasing the clocks in sync to see where I get to:
34.7MHz: pass
(Note: already slightly odd since 33MHz from the 66MHz xtal /2 in cpld failed...)
40.5MHz: pass
42.8MHz: pass
45MHz: fail - cpu bombed on desktop once, drand fails on fpu test
47.4MHz: cpu fail (unable to click on desktop!)
50MHz: cpu fail (unable to click on desktop!)

Now the same, with the fpu locked to 16MHz (XCPUCLK):
34.7MHz: pass
37.3MHz: fpu fail (fadd/fsub)
40.5MHz: fpu fail (first instruction)
42.8MHz: fpu fail (first instruction)
45MHz: cpu fail (unable to click on desktop!)
47.4MHz: ... not tested
50MHz: does not boot

The same, with the fpu locked to 25MHz (xtal/2 in cpld):
34.7MHz: pass
37.3MHz: fpu fail (fadd/fsub)
40.5MHz: fpu fail (first instruction)
42.8MHz: fpu fail (first instruction
45MHz: fpu fail (third instruction)
47.4MHz: cpu fail (unable to click)

Note all these tests were run with:
wire lowspeed = DISABLE_FAST & resetblock & ( AS | ~ttram_access | ~rom_access | ~fpu ) & clockholdoff ; // low active (rom access here too)

So... seems that 42.8MHz is my winner for cpu+fpu, or 50MHz (xtal) for cpu alone! I'm wondering about 50MHz to the CPU direct from the xtal.

Final test:
50MHz xtal->cpld->cpu, 42MHz from de1->cpld->fpu : cpu crashes.
-> This one is slightly interesting in that the cpld handling the clocks for the fpu (even without access) stops the cpu working. I'm wondering about adding extra capacitance on the cpld.

[Badwolf]

Then I killed a 68030 - in system flashing, which I'd done a lot without issue but this time it didn't like it:(

Ugh! I've flashed in system must be hundreds if not thousands of times over the course of the board's development and never seen this. Bad luck. :-(

So... seems that 42.8MHz is my winner for cpu+fpu, or 50MHz (xtal) for cpu alone! I'm wondering about 50MHz to the CPU direct from the xtal.

Just to be clear, all those results were with the FPU and CPU clock decoupled, but sometimes at the same freq?

Do you see any improvement in max stable speed if they're sharing the same physical wire?

Final test:
50MHz xtal->cpld->cpu, 42MHz from de1->cpld->fpu : cpu crashes.
-> This one is slightly interesting in that the cpld handling the clocks for the fpu (even without access) stops the cpu working. I'm wondering about adding extra capacitance on the cpld.

One thing Exxos and I saw when experimenting with different oscillators and combinations was that because we're mixing 5V and 3V3 parts, often going 5-3->5 the frequency may be spot on but the duty cycle might be a bit squiff. Tweaking the 'TUNE' inline termination resistors would be my first approach rather than capacitance.

Exxos, for example, found that a couple of pF on the output of one of his oscillators helped it work, but then killed other oscillator output stone dead. I increased the master osc TUNE resistor from 33R to 100R and they all worked to one extent or another. Try upping that?

BW