TF CD32 Riser Revision 2 Design Complete

[arkadiusz.makarenko]

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).

[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.

[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.

[arkadiusz.makarenko]

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?

[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.

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.

[arkadiusz.makarenko]

With your code, I can see that DSACK and PUNT is asserted correctly, but still when ARM is touching databus cpu crashes.

[terriblefire]

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.

[arkadiusz.makarenko]

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

[terriblefire]

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

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.

[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. ... it was worth a try. (Need to get a little bit better with verilog)