Page 25 of 60
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 17:05
by arkadiusz.makarenko
terriblefire wrote: 12 Oct 2020 15:53
arkadiusz.makarenko wrote: 12 Oct 2020 15:39
Does it mean that we can place data on the bus, but control signals need to be controlled over CPLD?
So what need to happen on cpld and side to check this?
Can you push/send what you currently have for the CPLD / arm code somewhere i can look.
It is not much as I didn't really saved any failed attempts
Interrupt routine in in main.c (HAL_GPIO_EXTI_Callback)
I changed crystal to 25Mhz and set up clocks for max 216Mhz ( i can revert it back to 8Mhz if you would like to run it on your board)
https://github.com/arkadiuszmakarenko/RiserTest
saying that I did manage to do what I wanted test here from cpld. (read data from bus and save it in register, and then send it back).
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 18:24
by terriblefire
Ewwo.. using ISE I see.. its pretty awful. Why take a huge step back to use that old crap? ;)
Ok i thought you were modifying my original code. It had latches specifically to let you ack from the ARM which then disasserted DSACK0 when AS went high.
EDIT: You also have to assert PUNT when you decode an address. Or the system will ack for you.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 18:40
by terriblefire
Code: Select all
wire dsack_int = 'SOME SIGNAL FROM THE ARM TO ACK'
wire punt_int = 'decode logic '
always @(negedge CLKCPU_A or posedge AS20) begin
if (AS20 == 1'b1) begin
dsack_int <= 1'b1;
dsack_int_d <= 1'b1;
end else begin
dsack_int <= punt_int;
dsack_int_d <= dsack_int;
end
end
assign D[31:24] = dsack_int ? {8{1'bz}} : data_out;
assign DSACK = punt_int ? 2'bzz : {1'b1, dsack_int_d};
I did notice why you had write issues...
Code: Select all
wire punt_int = ~RW | ~PUNT_IN | AS20 | chipset_decode | ((A[11:0] != JOY0DAT_H) & (A[11:0] != JOY0DAT_L) & (A[11:0] != CIA_PRA));
only decoded reads not writes.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 19:52
by arkadiusz.makarenko
terriblefire wrote: 12 Oct 2020 18:24
Ewwo.. using ISE I see.. its pretty awful. Why take a huge step back to use that old crap? ;)
Ok i thought you were modifying my original code. It had latches specifically to let you ack from the ARM which then disasserted DSACK0 when AS went high.
EDIT: You also have to assert PUNT when you decode an address. Or the system will ack for you.
I am working on it just now. But It looks like it is different to one which you sent me last time, as I remember using INTSIG to ack that data is on the bus, and I can't find reference in this version?
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 19:56
by terriblefire
arkadiusz.makarenko wrote: 12 Oct 2020 19:52
terriblefire wrote: 12 Oct 2020 18:24
Ewwo.. using ISE I see.. its pretty awful. Why take a huge step back to use that old crap? ;)
Ok i thought you were modifying my original code. It had latches specifically to let you ack from the ARM which then disasserted DSACK0 when AS went high.
EDIT: You also have to assert PUNT when you decode an address. Or the system will ack for you.
I am working on it just now. But It looks like it is different to one which you sent me last time, as I remember using INTSIG to ack that data is on the bus, and I can't find reference in this version?
I think its on a PC that is currently no longer here. But it does roughly what i said above.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 21:26
by arkadiusz.makarenko
With your code, I can see that DSACK and PUNT is asserted correctly, but still when ARM is touching databus cpu crashes.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 21:37
by terriblefire
arkadiusz.makarenko wrote: 12 Oct 2020 21:26
With your code, I can see that DSACK and PUNT is asserted correctly, but still when ARM is touching databus cpu crashes.
you should be able to write to the ARM without an issue. maybe make the led go on and off with bit 8 of the data or something.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 21:53
by arkadiusz.makarenko
terriblefire wrote: 12 Oct 2020 21:37
arkadiusz.makarenko wrote: 12 Oct 2020 21:26
With your code, I can see that DSACK and PUNT is asserted correctly, but still when ARM is touching databus cpu crashes.
you should be able to write to the ARM without an issue. maybe make the led go on and off with bit 8 of the data or something.
Maybe you are right, lets start from reading from the bus. Lets see if I can do it easily.
Writing to a bus is much more difficult. I have started reading Section 5 68020 reference manual... nice read :D
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 21:57
by terriblefire
arkadiusz.makarenko wrote: 12 Oct 2020 21:53
terriblefire wrote: 12 Oct 2020 21:37
you should be able to write to the ARM without an issue. maybe make the led go on and off with bit 8 of the data or something.
Maybe you are right, lets start from reading from the bus. Lets see if I can do it easily.
Writing to a bus is much more difficult. I have started reading Section 5 68020 reference manual... nice read :D
The issue when you put data from the ARM to the 020 is that you must disassert it before the cpu tries to read the next instruction.
You almost want arm assembly here to .
1. assert ack to CPLD.
2. tristate ARM data bus
3. disassert ack.
do in that order as fast as possible.
Re: TF CD32 Riser Revision 2 Design Complete
Posted: 12 Oct 2020 23:13
by arkadiusz.makarenko
That is what I did try, already.
I need to measure exti latency....
I even can't read meaningful data from the bus. :(
Time for a break and regroup I think. :D ... it was worth a try. (Need to get a little bit better with verilog)