exxos's DFB1 trials

[exxos]

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?

I'll send you the code you can take a look at it all. Having problems uploading the file, keep getting HTTP errors, so need to go fix that now :roll:

[Badwolf]

OK, I've had a look and if you've got both the FPU and CPU on the DSACK[x] lines to the CPLD then it does indeed look like you're double-driving it. That'll be putting a lot of strain on the FPU as it tries to sink all the CPLD's current and on the CPLD as it tries to overpower the FPU! Yikes!

The obvious thing to do would be to not drive DSACK[x] when the fpu line is active, but since you queue the fpu line on the DSACK[x] lines, that'd be a circular dependency.

You could try this:-

Code: Select all

wire [1:0] DSACK_IN = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & FPU_DSACK_INT & { FLASH_DTACK, 1'b1 } ); // change your FPU delay logic to use this wire
assign DSACK =  ( DSACK_IN == 2'b11 ) ? 2'bzz : DSACK_IN;

That should, AFAICT, drive DSACK[x] as open drain. Only driving when one or both of the lines are active.

It might fix a couple of problems.

BW

[exxos]

@Badwolf

I commented out this as well though..

Code: Select all

wire [1:0] FPU_DSACK_INT = fpu | FPUDSACK;

Your adding it back in, .. there isn't a FPUDSACK anymore...

So maybe your code should be using fpu not FPU_DSACK_INT ?

[Badwolf]

@Badwolf

I commented out this as well though..

Code: Select all

wire [1:0] FPU_DSACK_INT = fpu | FPUDSACK;

Your adding it back in, .. there isn't a FPUDSACK anymore...

So maybe your code should be using fpu not FPU_DSACK_INT ?

Ah, sorry. No you're right that shouldn't be in there:-

Code: Select all

wire [1:0] DSACK_IN = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & { FLASH_DTACK, 1'b1 } ); // change your FPU delay logic to use this wire
assign DSACK =  ( DSACK_IN == 2'b11 ) ? 2'bzz : DSACK_IN;

The key thing is going high-z when it can so that the FPU can assert its own DSACK properly.

BW

[exxos]

Code: Select all

wire [1:0] DSACK_IN = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & { FLASH_DTACK, 1'b1 } ); // change your FPU delay logic to use this wire
assign DSACK =  ( DSACK_IN == 2'b11 ) ? 2'bzz : DSACK_IN;

Added that in bought in order to use DSACK_IN I had to move the fpu code about a bit as it wouldn't compile as DSACK_IN is at the bottom of the code and FPU stuff at the top..

So now I have.

Code: Select all

wire [1:0] DSACK_IN = ( RAM_DTACK & ROM_DTACK & DSP_DTACK & { FLASH_DTACK, 1'b1 } ); // change your FPU delay logic to use this wire
assign DSACK =  ( DSACK_IN == 2'b11 ) ? 2'bzz : DSACK_IN;

wire [5:0] DT_DELAY; //exxos bodge -  DONT LET FPU_CS GO LOW UNTIL DSACK HAS BEEN LOW FOR A WHILE
FDCP ff_dtdly0( .D(DSACK_IN), .C( ~CPUCLK ), .CLR(1'b0), .PRE( AS ), .Q(DT_DELAY[0]) );  
wire fpu = DT_DELAY[0] | fpux; 

fpux is at the top of the code somewhere.

Code: Select all

wire fpux = {FC,A[19:16]} != 7'b1110010; // co-processor decode

Unfortunately I just get a row of bombs when trying to test the FPU now :(

But shouldn't the DSACK_IN has the fpu in there somewhere to high-z them on fpu access ? Or does that just go high-z on everything other than what is listed ?

EDIT:

I put back fpu instead of DSACK_IN, and it still works. I guess if it prevents any DSACK shorts then thats a good update. It would seem it can't be relating to DSACK then , otherwise I assume having DSACK_IN in the delay for FPU_CS would have worked otherwise :roll:

So need a new theory now then I guess :shrug:

Maybe something on the bus isn't quite stable yet like the address bus or something :shrug:

[Badwolf]

But shouldn't the DSACK_IN has the fpu in there somewhere to high-z them on fpu access ? Or does that just go high-z on everything other than what is listed ?

The high-Z is handled in the assign DSACK line. It's saying whenever both DSACK_IN lines are high, don't drive the pins. No FPU dependency in there.

I'd start off by removing all your FPU hacks and seeing if it runs like that. If not, then start to re-introduce hold-offs.

If fpux has a dependcy on DTACK_IN, then I wouldnt' want DTACK_IN to have a (circular) dependency on fpux.

BW

[exxos]

@Badwolf ah no it was supposed to be ~DSACK_IN (inverted) for my code.

So now the FPU is working again...

[Badwolf]

Good news, then!

By the way, there's quite a lot of superflous chaff in that firmware. I'll have a go at hacking it down to the minimum necessary when I get a chance. I suspect it's been compiled out but it won't hurt to spruce it up.

There's a time-delay in there that I've since figured out why it's needed so I can hopefully alter that and free up a bit of CPLD-space too.

BW

[exxos]

By the way, there's quite a lot of superflous chaff in that firmware. I'll have a go at hacking it down to the minimum necessary when I get a chance. I suspect it's been compiled out but it won't hurt to spruce it up.

I need to get rid of all my crap first :lol:

Still having problems at 50MHz. Might slap another 1K on the DSACK pins for the hell of it.

[Badwolf]

Still having problems at 50MHz. Might slap another 1K on the DSACK pins for the hell of it.

I'd play with the inline termination resistor on the CPU clock line. 100R, perhaps?

BW