I was having intermittent CPU issues. These manifested as intermittent results uploading S-Records. Sometimes I'd even make an identical build which would work one time but not the next. Something was marginal in the design.

I hooked up a logic analyzer and added test points to the I/O connector to monitor some of the internal control lines of the CPU.

    IO_PIN(48) <= w_cpuClock;
    IO_PIN(47) <= n_WR;
    IO_PIN(46) <= w_nLDS;
    IO_PIN(45) <= w_nUDS;
    IO_PIN(44) <= n_externalRam1CS;
    IO_PIN(43) <= w_wait_cnt(3);
    IO_PIN(42) <= w_n_RomCS;
    IO_PIN(41) <= w_n_RamCS;
    IO_PIN(40) <= w_busstate(0);
    IO_PIN(39) <= w_busstate(1);
    IO_PIN(38) <= cpuAddress(15);
    IO_PIN(37) <= '0' when ((cpuAddress(23 downto 3) =  x"00000"&'0'))    else        -- X000000-X000007 (VECTORS)
                        '1';

The 68K CPU has two bus state lines which indicate the operation being performed. They are documented as follows:

busstate : out std_logic_vector(1 downto 0);
-- 00 -> fetch code 
-- 10 -> read data 
-- 11 -> write data 
-- 01 -> no memaccess

Disabling accesses for the situation where the busstate = 01 cleaned up the issues I was having. Also, making peripheral accesses only active when busstate(1) = 1 protects the port a bit. RAM and ROM can have either code or data so they need to access for the situation where busstate{1) = 1 or busstate(0) = 0.

 Here's the timing of the CPU coming out of reset:

This fixed the CPU so that it runs reliably at 25 MHz including downloading S-Records and running code. It broke the External SRAM but that's OK since I wanted to work on the controller anyway. 

The VHDL code is up on the GitHub.