Simultaneous address update and read for external SRAM

[atoone]

I'm interfacing an external SRAM to a Lattice part, and coming up against a timing issue that makes the design unstable. Frustratingly, the simple cases work fine, with problems emerging as the overall design gets larger.

Essentially, I'm doing a continuous lookup, where the results of the previous read are used to set the address of the next read. Something a bit like this (other cases and additional computation removed).

always @(posedge CLOCK) begin
    case( state )
       PHASE_ONE: begin
            ram_address <= location;                   // First phase - lookup stable address
            some_value <= ram_data[15:8];          // Get result of previous PHASE_TWO <- This is unstable
            location++;
            state <= PHASE_TWO;
          end
       PHASE_TWO: begin
            ram_address <= { 7'b0, ram_data[7:0] };  // Second phase - lookup based on previous value
            other_value <= ram_data[15:8];               // Also use previous value for a calculation <- This is stable
            state <= PHASE_ONE;
          end
    ...
end  

Output enable, chip select and so on are all held continuously active (low).

This works just fine... some of the time (and of course, always in simulation). Then small changes elsewhere in the project knock everything out of whack. The overall clock rate is well within the limits of the SRAM.

My assumption (hard to verify) is that setting the ram_address with it's own data is the root of the problem, since the other_value read in phase_two appears stable, and both phases do the same simultaneous set address and read data functions. When the project is reduced to bare bones, this all works, but it becomes unstable as other functionality is added.

Any suggestions for checking/debugging/diagnosing the issue? I really want to avoid breaking this out into multiple steps as it dramatically reduces the available bandwidth..

The ram interface is declared as a module that takes the ram_address and control signals and mediates the bidirectional bus to the physical device (somewhat simplified):

    input   [ADDRESS_WIDTH-1:0] address;  // Address in
    output  [DATA_WIDTH-1:0]    data_read; // Data from SRAM
    input    [DATA_WIDTH-1:0]   write_data;  // Data to SRAM
    
    input   write_en;
    ...
    output  [ADDRESS_WIDTH-1:0] sram_addr;   // External SRAM interface
    inout   [DATA_WIDTH-1:0] sram_data;
 
    ...
    
    assign data_read = sram_data;

    assign sram_data = write_en ? write_data : 16'bz;

    assign sram_addr = address;

In general, how are people getting help for larger projects, when it moves beyond the 'casual hacking' phase? Since this runs on custom hardware, it's not really something that can be usefully explored by other developers on a whim, so it might be helpful to find advisors who can perhaps handle a slightly more formal arrangement..

[atoone]

Further investigation has isolated the problem to this line:

ram_address <= { 7'b0, ram_data[7:0] };

I can store the value to another register and simultaneously update the ram_address on the same clock, but setting the ram_address from the incoming data becomes unstable once the rest of the design is more complex.