REV 3 - REV 5 - The beginning (ST536)

[exxos]

@Badwolf I will try again when I'm at home, but AFAIK it just hits a point then starts failing.. But if I loop the working address range on YAARTTT it passes fine.

The dram is driven from the master clock 100mhz, CPU is just a division of it for 50mhz.

I'm starting to think maybe its because the TF536 doesn't have pull ups on it.. But I would think it would have never worked.. I have scoped them out and looked good. But I'm sure it would fail on random addresses not just hit the same one and die..it very odd

[Badwolf]

@Badwolf I will try again when I'm at home, but AFAIK it just hits a point then starts failing.. But if I loop the working address range on YAARTTT it passes fine.

Also interesting to see what the failures are. That first test pass where it writes the absolute address into each longword is the best one. Often you can see logic problems immediately from that.

The dram is driven from the master clock 100mhz, CPU is just a division of it for 50mhz.

Yeah, so what's the offset of the edges? 10ns? 20?

I'm starting to think maybe its because the TF536 doesn't have pull ups on it.. But I would think it would have never worked.. I have scoped them out and looked good. But I'm sure it would fail on random addresses not just hit the same one and die..it very odd

Will original firmware work any more? If so, does that exhibit the same issues?

BW

[exxos]

@Badwolf I have not tried original firmware yet (its not compatible with my board out of the box)

I just got home.. wrote A quick program in STOS to skip over some addresses...


Comes up exactly the same error on the same two addresses..

IMG_6454.JPG (221.62 KiB) Viewed 3652 times

Then I took a couple of zeros off the step...

IMG_6455.JPG (310.81 KiB) Viewed 3652 times

EDIT:

What is odd , is that regardless of what I write (0-255) it always comes back as 238


EDIT2:

Always same ranges fail in blocks..

IMG_6456.JPG (246.16 KiB) Viewed 3639 times

Code: Select all

111011111101111001000000 ok  15720000
111100000000010101010000 F   15730000


1111011111110100100100000 ok 32500000
1111100000001000000110000 F  32510000
1111100001111101010010000 F  32570000

[exxos]

I made a change in the code to not allow ram decoding to happen while DTACK is low. But I seem to be back to the STERM oddness again now in theory , the cpu could read DTACK from the previous bus cycle and terminate the ram cycle, even before the cpu a actually gets STERM.. So a simple code change , and now its behaving like its not terminating the RAM cycle. YAARTTT just hangs if I try to access ram. STOS bizzarly chucks out a illegal instruction.

Even more odd, is that I don't let the CPU see DTACK on ram access later in the code anyway. So adding DTACK to the ram decoding line should not make any odds at all. If DTACK was low all the time the ram would never get decoded.. But that cant happen really anyway..

I'm out of ideas at this point. I'm pretty much at the door of thinking the xlinix compiler is flawed and something isn't running as it should

[exxos]

@Badwolf

I think as we suspected, there is no bus error for out of bounds memory address ranges..

Code: Select all

// bus error needs to be thrown on an FPU accses.
assign BERR = CPCS_INT ? 1'bz : 1'b0;

[Badwolf]

@Badwolf I have not tried original firmware yet (its not compatible with my board out of the box)

I just got home.. wrote A quick program in STOS to skip over some addresses...


Comes up exactly the same error on the same two addresses..

This one is interesting.

You're getting errors at 1F00000 and 2F00000 (translating your decimal to hex).

That seems too repeatable to be a fluke. Incidentally for the second test it would be nice if you could output the failure address in hex as it lets us easily see if the addresses in 1xxxxxx are the same as that in 2xxxxxx.

From this I'd be suspecting something amiss in the firmware that's triggering on xxFxxxxx before the AltRAM flag is set.

Anything that mentions A[23:20] ?

BW

[Badwolf]

@Badwolf

I think as we suspected, there is no bus error for out of bounds memory address ranges..

Code: Select all

// bus error needs to be thrown on an FPU accses.
assign BERR = CPCS_INT ? 1'bz : 1'b0;

OK, that's an easy fix and it'll hopefully reduce the problems to the strange issue at xxFxxxxx.

Code: Select all

wire altrambuserr = AS30 | ( A[26:24] != 3'b101 );
assign BERR = CPCS_INT | altrambuserr ? 1'bz : 1'b0;

Try that. That creates a flag (wire) that's low if AS30 is low and A[26:24] is equal to 101.

That should cover address ranges 0x05000000 to 0x5FFFFFFF.

You might need to check AS30 is the right symbol for your 030's AS line -- I'm extrapolating from the TF330 code.

BW

[exxos]

You're getting errors at 1F00000 and 2F00000 (translating your decimal to hex).

That seems too repeatable to be a fluke. Incidentally for the second test it would be nice if you could output the failure address in hex as it lets us easily see if the addresses in 1xxxxxx are the same as that in 2xxxxxx.

Yes I will get it to output hex next time..

I thought it was a fluke,If I run the program several times it fails in exactly the same figures.

This has spilled over to the EMUTOS list a bit.. but when I view the memory ranges in sysinfo, its totally blank.. It is to be expected as there should be nothing in ram anyway.

I will try running my program just doing reading, to see what the values I get back are..

[exxos]

Try that. That creates a flag (wire) that's low if AS30 is low and A[26:24] is equal to 101.

Great thanks.. will see if EMUTOS behaves with this fix in...

[Badwolf]

This has spilled over to the EMUTOS list a bit.. but when I view the memory ranges in sysinfo, its totally blank.. It is to be expected as there should be nothing in ram anyway.

There's a difference in Sysinfo between blank (00) and error (--) as far as I understand it.

Reading (for example) from 4FFFF00 should see a lovely transition from numbers to dashes as it tips over from the 4x to the 5x range once your bus error logic is in place.

BW