This bug only happens when writing with burstcount > 1, i.e. when issuing writes of more than 2 bytes. Basically, the controller ignores the byteenable input on all but the first clock cycle. This bug was observed in the ILA while investigating issue #2.
To reproduce
Start a write with burstcount = 2 and write the following:
cycle: data = X"BBAA" with byteenable = "11"
cycle: data = X"DDCC" with byteenable = "01"
Expected behavior
The memory is updated with the three bytes X"AA", X"BB", and X"CC".
Observed behavior
Four bytes are written to memory, i.e. the fourth byte X"DD" gets written as well, thus corrupting one byte of memory.
MJoergen
commented
1 year ago
Short description
This bug only happens when writing with burstcount > 1, i.e. when issuing writes of more than 2 bytes. Basically, the controller ignores the byteenable input on all but the first clock cycle. This bug was observed in the ILA while investigating issue #2.
To reproduce
Start a write with burstcount = 2 and write the following:
Expected behavior
The memory is updated with the three bytes X"AA", X"BB", and X"CC".
Observed behavior
Four bytes are written to memory, i.e. the fourth byte X"DD" gets written as well, thus corrupting one byte of memory.