Generally, for worst case timing that is true. But how many engineers will have dumped the W65C816 for quoting this extremely unrealistic timing, is anyone's guess.
From memory, address lines were valid something like 5 to 10 ns after phi1. It figures, of course, that the address is simply clocked into a register connected to the relevant pins, so it's not a surprising number either. When I saw the timing in the datasheet, I immediately distrusted it. WDC does not make very good documentation anyway. Quite messy, buggy and inconsistent ...

I think the discrepancy stems from confusion between the conceptual (where phase 1 is an address and control line setup period, and phase 2 is the transfer, i.e. where address and control lines, in principle, only need to be valid when phase 2 starts) and the implementation.

I have a new processor design that removes the memory pipeline delay (that was required for using bram normally) from my original design. Unfortunately I have not been able to test it with normal sram. How I tested it was by clocking the bram on the negative edge of the clock to simulate normal sram single cycle access. I do not know how fast it will be able to run with sram but I was running it at 48MHz for my testing. The average cycle count for all instructions are half of what the original processors were.

If anyone tries to use it and finds any problems please let me know.

edit:
Well, I found 3 bugs and some extra code already, here are my suggested changes to fix the bugs...

This fixes indirect accesses to internal memory for memory to register operations.
replace
S_WR_MEM_OP,S_WR_MEM_OP: cpu_aw = tmp_a;
with
S_RD_MEM_OP,S_WR_MEM_OP: cpu_aw = tmp_a;


These fix not changing these flags when executing indirect addressing mode store operations.
replace
else next_N = alu_op_inc_neg;

with
else if(inc) next_N = alu_op_inc_neg;
else next_N = negative; //ix/iy writes


replace
else next_Z = alu_op_255;

with
else if(inc) next_Z = alu_op_255;
else next_Z = zero; //ix/iy writes


alu_op and tmp_a does not need to be initialized everywhere they are.
I imagine the compiler is taking care of most of these automatically. If you really want these changes I will upload another zip file. I renamed some variables for better clarity and grouped the code better so a diff with what I have already provide will be pretty big.

For those stumbling across this old thread :

My proof of concept (a full implementation, really) can be read about here : http://forum.6502.org/viewtopic.php?t=6284