Page 33 of 110
Re: REV 3 - The beginning
Posted: 28 Apr 2021 19:49
by 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 :(
Re: REV 3 - The beginning
Posted: 28 Apr 2021 19:53
by Badwolf
exxos wrote: 28 Apr 2021 19:49
@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
Re: REV 3 - The beginning
Posted: 28 Apr 2021 22:45
by 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
Then I took a couple of zeros off the step...
IMG_6455.JPG
EDIT:
What is odd , is that regardless of what I write (0-255) it always comes back as 238 :shrug:
EDIT2:
Always same ranges fail in blocks..
IMG_6456.JPG
Code: Select all
111011111101111001000000 ok 15720000
111100000000010101010000 F 15730000
1111011111110100100100000 ok 32500000
1111100000001000000110000 F 32510000
1111100001111101010010000 F 32570000
Re: REV 3 - The beginning
Posted: 29 Apr 2021 00:59
by 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 :roll: 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 :roll:
Re: REV 3 - The beginning
Posted: 29 Apr 2021 10:57
by 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;
Re: REV 3 - The beginning
Posted: 29 Apr 2021 10:59
by Badwolf
exxos wrote: 28 Apr 2021 22:45
@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
Re: REV 3 - The beginning
Posted: 29 Apr 2021 11:06
by Badwolf
exxos wrote: 29 Apr 2021 10:57
@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
Re: REV 3 - The beginning
Posted: 29 Apr 2021 11:17
by exxos
Badwolf wrote: 29 Apr 2021 10:59
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..
Re: REV 3 - The beginning
Posted: 29 Apr 2021 11:18
by exxos
Badwolf wrote: 29 Apr 2021 11:06
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...
Re: REV 3 - The beginning
Posted: 29 Apr 2021 11:20
by Badwolf
exxos wrote: 29 Apr 2021 11:17
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