Byte enable information

[Jpnock]

Reposted from David Thomas in the Teams Question chat

If you only wanted byte 2 to be written, then yes the byteenable would be 0b0100.

However, in the example the write is of 2 bytes starting at address 2, so both byte3 and byte2 need to be written, so the bytenable is 0b1100.

Let's assume we have a 4-byte aligned base address b, then we can work our way through the possibilities for byte-enables when writing:

0b0001 : Write 1 byte to address b

0b0010 : Write 1 byte to address b+1

0b0100 : Write 1 byte to address b+2

0b1000 : Write 1 byte to address b+3

0b0011 : Write 2 bytes (half-word) to address b

0b1100 : Write 2 bytes (half-word) to address b+2

0b1111 : Write 4 bytes (full word) to address b

The same applies for reading, as technically you should use byte-enables during reads as well. These cover the cases for LW, LH, LHU, LB, LBU and equivalent stores, but there are some extra cases for LWL and LWR - though I would avoid those instructions till you've got the basic instructions like LW+SW working and tested.

[Jpnock]

From p.g. 15 https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/mnl_avalon_spec.pdf

Agents that simply return readdata with no side effects are free to ignore byteenables during reads.

Therefore agents can effectively ignore byteenable during a read, so we need to do this bit mask ourselves on the CPU side.

[Jpnock]

This has been implemented and tested, with the exception of read byte enables which are tracked in a different issue (#41)