exxos's DFB1 trials

[exxos]

That's interesting, it could mean that the FPU itself is stomping on its own accesses? That said you've changed the whole DSACK[x] logic, as I understand it, so I may be way off-base.

On my boards DSACK[x] was fully derived and there was a dedicated FPU_DSACK input to the CPLD. If you've now gone for an open-collector shared DSACK[x] bus between the CPU and FPU, I don't know what's reliable to sample any more.

If you remember I had odd things happen with the scope on one of those DSACK pins from the FPU when it was going via the PLD. I think it would start working on X10. I do remember documenting those something incredibly sensitive about one of those signals. Which was why I wanted to decouple it from going via the PLD for starters.

Looking at the FPU datasheet it seems that DSACKx both go high basically within a few ns of AS going high.

FPU_CS itself seems to go low even before /AS does on the datasheet :shrug:

68882.PNG

I don't see how CS goes low before AS.. that does not make any sense. In your code you did not have AS in there, I added yesterday but it did not make any difference IIRC.

I'm really starting to wonder about CS now. Is a datasheet wrong somehow ? because at the moment CS will be delayed (I assume) by a longer amount than waiting for AS to go low.

Or could just be some DSACK conflict from the previous bus cycle. But as you say XDACK should work also, but it doesn't.

Currently I just assume that delaying CS shifts DSACK timing by like 10ns and it causes it to work. I guess its possible DSACK internally in the FPU isn't timed correctly and its pushing DSACK low before the data is actually valid.

[Badwolf]

Looking at the FPU datasheet it seems that DSACKx both go high basically within a few ns of AS going high.

But if they're not actively driven high, the speed they rise will be determined by the pull-ups. As I'm not quite sure exactly the configuration of the DSACK[x] lines on the board and the CPLD at the moment, I'm not sure what exactly you're sampling in the verilog.

FPU_CS itself seems to go low even before /AS does on the datasheet :shrug:

I don't see how CS goes low before AS.. that does not make any sense. In your code you did not have AS in there, I added yesterday but it did not make any difference IIRC.

Yes, that's correct and how I had it set up initially.

remember the FPU is configured as a co-processor, not a memory-mapped peripheral. It doesn't rely on address decoding to drive chip select, so AS is technically not relevant. We've experimented adding it before, but it's not had any effect, AFAICT and is technically incorrect to do so.

Or could just be some DSACK conflict from the previous bus cycle. But as you say XDACK should work also, but it doesn't.

DSACK[x] is, in my firmware, driven by either (indirectly) XDTACK, the flash ROM or the FPU. If you're not using the flash ROM, you've taken the FPU out of the CPLD and XDTACK doesn't work, then I can only assume you're switching the DSACK lines to high-z and have them configured as input/output so you're seeing the DSACK[x] from the FPU.

If not, it doesn't make much sense to me either. This is the bit I meant about not being sure of the exact configuration.

Currently I just assume that delaying CS shifts DSACK timing by like 10ns and it causes it to work. I guess its possible DSACK internally in the FPU isn't timed correctly and its pushing DSACK low before the data is actually valid.

That would be a serious issue that decades of co-processor use would have found(*). I think we can rule it out.

BW



(*) Although I don't believe technically data has to be valid on DSACK[x] assertion, merely on the next falling edge after it. Cf. Atari ST memory timings and my lack of hair after working on PiStorm.

[exxos]

But if they're not actively driven high, the speed they rise will be determined by the pull-ups.

Yes that is what I was thinking that it can take a incredible long amount of time for that to happen. Those 2k2 pullups are still there. Cannot realistically go much lower than that anyway.

As I'm not quite sure exactly the configuration of the DSACK[x] lines on the board and the CPLD at the moment, I'm not sure what exactly you're sampling in the verilog.

It be the DSACK lines from the CPU (which are connected directly to the FPU now).

DSACK[x] is, in my firmware, driven by either (indirectly) XDTACK, the flash ROM or the FPU. If you're not using the flash ROM, you've taken the FPU out of the CPLD and XDTACK doesn't work, then I can only assume you're switching the DSACK lines to high-z and have them configured as input/output so you're seeing the DSACK[x] from the FPU.

You just have this

Code: Select all

assign XDTACK = DISABLE ? 1'bz : ( FLASH_DTACK ? 1'bz : 1'b0 ); // inactive when accelerator enabled, becomes a bus slave when disabled

I assume it is a output to XDTACK (to the MB) ? I further assume that if I sample XDTACK, it is coming directly from the motherboard ?

All I did was

Code: Select all

wire [5:0] DT_DELAY; 
FDCP ff_dtdly0( .D(~DSACK[0] | ~DSACK[1]), .C( ~CPUCLK ), .CLR(1'b0), .PRE( AS ), .Q(DT_DELAY[0]) );      
wire fpu = DT_DELAY[0] | {FC,A[19:16]} != 7'b1110010; // co-processor decode

Without that patch it will pretty much crashed on the first FPU test. With it, it passes them all every time at 40MHz.

It also works if you just simply run fpu via the FF chain. Just for a delay of ~25ns.

I'm not sure why DSACK would work unless it is not sampling at all and it is just the internal logic delays of the PLD causing a couple of ns delay which then works anyway. Probably that sensitive because again going back to my X10 probe on the DSACK lines helped a great deal.

Maybe just a simple fixed delay would be better. Though I think we tried this on the original board and it had no effect, but this board is wired slightly different than the previous ones. So maybe now things have changed enough for it to work this time..

In any case, the bottom line is still going to be why does FPU_CS need a slight delay on it.

[Badwolf]

You're showing me two different things there XDTACK (which is always high Z unless the board is disabled) is my code, I know how that works. If the board is active, that's a 1:1 representation of what the motherboard is driving.

But what has been reconfigured for DSACK[x]? Are they now an INOUT (rather than just an OUTPUT as on my design)?

Then at what time do they go high-z?

What is happening in that flipflop depends on all that.

BW

[exxos]

But what has been reconfigured for DSACK[x]? Are they now an INOUT (rather than just an OUTPUT as on my design)?

It's not just output on your design. This code was in your original code and I haven't changed it!

Code: Select all

	inout [1:0] 	DSACK,

I have done very little code change wise and the bulk of the changes were only moving 3 PLD pins about. I removed the FPU DSACK from going via the PLD to the CPU.. That is pretty much all the code changes I did.

[Badwolf]

But what has been reconfigured for DSACK[x]? Are they now an INOUT (rather than just an OUTPUT as on my design)?

It's not just output on your design. This code was in your original code and I haven't changed it!

Code: Select all

	inout [1:0] 	DSACK,

I have done very little code change wise and the bulk of the changes were only moving 3 PLD pins about. I removed the FPU DSACK from going via the PLD to the CPU.. That is pretty much all the code changes I did.

Ah, sorry I misremembered. They're always driven on my design, so I thought they were pure OUT.

OK, so when do they go high-z? What's your assign DSACK line look like?

BW

[exxos]

OK, so when do they go high-z? What's your assign DSACK line look like?

I only do this.

Code: Select all

wire [5:0] DT_DELAY; 
FDCP ff_dtdly0( .D(~DSACK[0] | ~DSACK[1]), .C( ~CPUCLK ), .CLR(1'b0), .PRE( AS ), .Q(DT_DELAY[0]) );      
wire fpu = DT_DELAY[0] | {FC,A[19:16]} != 7'b1110010; // co-processor decode

But I have changed it to

Code: Select all

wire fpux = {FC,A[19:16]} != 7'b1110010; // co-processor decode 
wire [5:0] DT_DELAY; 
FDCP ff_dtdly0( .D(fpux), .C( ~CPUCLK ), .CLR(1'b0), .PRE( AS ), .Q(DT_DELAY[0]) ); 
wire fpu = DT_DELAY[0] | fpux; 

Both work.

All other code is as per your original code (aside from I disabled flash in the code to get me running).

[Badwolf]

OK, so when do they go high-z? What's your assign DSACK line look like?

All other code is as per your original code (aside from I disabled flash in the code to get me running).

Your DSACK line must have changed, though as mine is always driven:-

Code: Select all

assign DSACK = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & FPU_DSACK_INT & { FLASH_DTACK, 1'b1 } );

BW

[exxos]

Your DSACK line must have changed, though as mine is always driven:-

Code: Select all

assign DSACK = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & FPU_DSACK_INT & { FLASH_DTACK, 1'b1 } );

Ah yep I removed the FPU_DSACK_INT from that as there was nothing to drive it anymore.

[Badwolf]

Your DSACK line must have changed, though as mine is always driven:-

Code: Select all

assign DSACK = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & FPU_DSACK_INT & { FLASH_DTACK, 1'b1 } );

Ah yep I removed the FPU_DSACK_INT from that as there was nothing to drive it anymore.

I'm not sure that's right.

You'll be double-driving the DSACK[x] lines if that's all that's changed. There's no high-z option in there that I can see so the FPU would be trying to drive DSACK[x] low and this term would be trying to drive them high. There must be a high-z in there somewhere?

BW