Increase CPU Speed

Looking at the datasheet, the max frequency at 3.3v is about 14MHz.

Our clocks must be synchronous, which limits us to 12.5MHz.

added Feature Hardware labels

assigned to @bslathi19

created branch 38-increase-cpu-speed to address this issue

mentioned in merge request !33 (merged)

The delay value would be #40 for this.

Doing so makes it too fast for the SDRAM though, so you would have to implement wait states, or get faster memory (which we cannot do)

Here is the memory access at 2MHz

And now here it is at 4MHz

See how it skipped the first memory access, and there is some weird stuff going on at the first write access?

So before anything else, why did it just skip that write state?

So in the faster case, we start in the wait state and don't exit it until the positive edge of cpu clock, but then we miss the write signal. Why does it happen in the slow case?

Ah, do notice that in the slow case, the writes all happen at the end of the cycle, whereas in the fast case they are happening at the beginning.

Interesting behavior here where the state is changing at the same cycle as next_state (for the first 2 transitions). This should only be possible on reset going into state 3. Is this a simulation bug, or bad coding?

Seems like the problem is to do with comparing to clk_cpu, as in both cases where next_state and state change at the same time, it is because we are basing next_state on the output of a comparison with clk_cpu

I think I see part of the problem

if (i_cs) begin
    w_addr = {{i_addr[24:2]}, {1'b0}};;  // divide by 2, set last bit to 0
    
    if (i_rwb) begin    //read
        w_read = '1;
        w_last = '1;
        // dm is not needed for reads?
        if (w_rd_ack) next_state = READ_WAIT;
    end else begin      //write
        w_data_i = i_data << (8*i_addr[1:0]);
        //w_data_i = {4{i_data}}; //does anything get through?
        w_dm = ~(4'b1 << i_addr[1:0]);
        if (~i_cpuclk) begin
            w_write = '1;
            w_last = '1;
            next_state = WRITE_WAIT;
        end
    end
end 

You see how we are dependent on i_cs being high, but i_cpuclk being low. These are never supposed to happen together, since when i_cpuclk goes low, that is the end of the write cycle and i_cs will change again. tbh I am not sure why this even worked at the slow speed.

So it seems like memory reads/writes work, but somehow the new state machine breaks the boot process. Why?

Looks like zerobss is failing. Trace the path that it takes to get to the uart print

called from F09D, which is in _clrscr, which we don't ever call? How do we get into that code?

We jump there from F0C5, which is in _irq_int?

aha, its called there because we get a break instruction, which is then calling into offsets for stuff that it probably shouldn't. At 434us there is a BRK.

Looks like a 432 us the stack gets corrupted, and we RTS to 00

Why are we writing to address 0 and 1? It should be address 1fe and 1ff