... actually, as it's the deassertion edge of WE that counts for level-driven inputs, I think the write logic needs to be like this:
- cycle 0: set address, data
- cycle 1: hold address, data, assert WE (stable address is necessary to not overwrite other addresses randomly)
- cycle 2: hold address, data, deassert WE (stable address and data is necessary since this ends the write operation)

my theory is the deassertion of WE in the transition of wr0 to idle.
Right now it's uncontrolled in a sense that the address might change nanoseconds before WE returns to non-asserted. Try to add a wr1 state that only changes the enable lines and leaves address / data untouched.

What I meant is that the old version updates address_input only on start_operation, but the new one updates it continuously.
Thinking about it, I'm not sure if this really is the root cause. The version from your last post would seem the most logical, though (for readability, not functionality).
I'm in a bit of a hurry right now, but I'd check all warnings. Can I explain every one to yourself? Also review the data sheet / timing.
I can only encourage you not to leave any unsolved problems behind. It's annoying and hard work but the potential insights are too valuable
.

Hi,
the schematic is here. Double-check your constraints file: GCLK should be pin L17 (sheet 3):
https://reference.digilentinc.com/_media/reference/programmable-logic/cmod-a7/cmod_a7_sch.pdf
You don't need to write to flash: a bitstream .bit file can be uploaded directly to the FPGA. Much faster

BTW, just mentioning this: Since you have the code already on git, it seems odd to maintain multiple files with numbers.
Alternatives:
create a tag if the file is of general interest (e.g. something other developers would discuss)
reference the commit by the SHA hash if tagging seems like "overkill" e.g. this: https://github.com/salcanmor/SRAM-tester-for-Cmod-A7-35T/commit/de83d33960108ca66b7f2c4f37ccb498b25deafb
For example, it enables a one-click "diff" between versions (which, in this example, would be extremely helpful)
I can only encourage people to spend a day or two with git basics. Version management is as critical as coding, if much smaller in scope for the average user.

Is it possible that your clock is not there (e.g. not connected to the clock pin)?
I would try a combinational assignment, simply route the button to the LED without clock-driven process.
My VHDL spell checker is still asleep maybe someone else will spots something obvious in the code.

yes, this looks like what I'd expect.
Purely regarding style (opinion!), this
if(~start_operation)
state_reg <= idle;
else begin
is redundant since state_reg retains its value until overwritten.
Same with this...
if(rw) begin
address_to_sram_output[18:0]<=address_input[18:0];
...
end else begin
address_to_sram_output[18:0]<=address_input[18:0];
...
which puts the task of removing redundancy on the reader.
Both could be a coding style - spell out everything explicitly - that seems more appropriate for a much larger project where you immediately see the patterns (opinion).
-------------------------------------------------------------------
I'm wondering whether it is actually possible to solve the problem stateless, just using constraints If I specify Vivado a minimum delay for e.g. an enable signal relative to data, it will introduce dummy buffers. Works on a nanosecond time scale, which is exactly what this chip needs.
If anybody knows the answer or has done the exercise, I'm curious.

Hi,
you will have no difficulties to run logic at 100 Mhz = 5 MHz * 20, or 200 MHz with attention to details.
I would simply register the signals at the high clock rate, and put an extra register or two into the path you want to delay.
The on-chip MMCM can generate a 100 MHz clock from 5 MHz.

Hi,
a random thought: I've seen LCD dot matrix panels with current draw from 300 mA down to 50 or so. The blue ones tend to be better.
Maybe upgrading the display is less hassle than providing external power.

Hi,
>> "To allow bitstream creation with unspecified pin locations (not recommended)"
I would not do that when working with hardware. It's useful in situations where you don't care at what pin the signal is connected (e.g. a quick feasibility check).
It is possible that some pins serve a board-specific special purpose e.g. are grounded. It's unlikely this would cause damage, but you may run into problems that require serious detective work to debug.
Most likely it will actually work.
Just guessing: If you need the outputs because interesting signals get optimized away otherwise, the attribute "DONTTOUCH" or "KEEP" should prevent this.

Hi,
unfortunately, it can.
Try to put a 100 ohms resistor in parallel with the CLK input at the accelerometer board end to ground.
CLK is most likely the most sensitive of the signals when reflected edges cause double-triggering.