avalon mm byte enable

[Altera_Forum]

In the project we are currently working on, we want to read and write pixels to external DDR SDRAM. 

 We need to be able to use byte-mask / byte-enable bits to not overwrite some previously written good pixels, for writes that are not aligned.  Now, I just recently learned that the Altera mm-interface does not support arbitrary byte enable masks, it only supports:  (from www.altera.com/literature/manual/mnl_avalon_spec.pdf page 15)  The following values are legal for a 32-bit slave: 1111 writes full 32 bits 0011 writes lower 2 bytes 1100 writes upper 2 bytes 0001 writes byte 0 only 0010 writes byte 1 only 0100 writes byte 2 only 1000 writes byte 3 only  The point I am getting at is this:  I have 8, 16, and 24 bit pixel data I would like to write to an arbitrary byte-address. In order to do this with Avalon right now, I must read a complete aligned data word, modify only the data I am interested in, then write the full word back to main memory.  If my mm data width is 32 bit and I want to write only the top two bytes, I can't use the byte mask 1100, according to the above.  Is there any trick to handling this, without having to read the full data word, modify the desired bytes, then write the full thing back?  Can the mm-master data port that is controlling the mm-slave port on the DDR controller be made smaller DDR controller's native width, and thus cause all addresses to be aligned? In other words, if I want to write 8 bit words, can I address the memory in this fashion, and bypass the need for write enables all together?  What is the reason for not supporting arbitrary byte-enable patterns, when they are inherently supported by external SDRAM?

[Altera_Forum]

So here are my thoughts: 

1 - I never noticed this before, I wonder if it's a recent addition to the documentation. 2 -   --- Quote Start ---  I can't use the byte mask 1100, according to the above.  --- Quote End ---   Yes you can. According to the table, the only combinations you couldn't use would be: 0111 1011 1101 1110 0101 0110 1001 1010 3 - Have you tried it? Honestly I think I'd just try it anyway and see what happens. It may just work. It seems like if you always present a word address, the byte enables would be taken as they are given. I'd be surprised if there is actually some logic in the interconnect fabric that manipulates them. Try it. 4 - It does seem a little odd to me that you would be writing random bytes within a word. Especially pixel data. Are you sure you can't just buffer up multiple pixels and perform a single write. I guess I just don't know enough about what your trying to do to understand the usefulness.  Jake

[Altera_Forum]

Jake, 

you are correct, I meant to say 1110, not 1100.  I suspect you are correct in guessing that there is no added logic that manipulates the byte-enables, and they just get passed directly to the device/component as is.  I have not yet experimented with this to determine whether or not this is the case.  Has anyone written a component that talks to SDRAM that can use arbitrary byte masks? What about other mm components?  Why would Altera put in this restriction?

[Altera_Forum]

The restriction has to do with masters and slaves of different widths. If you have problems implementing the logic to break down the byte enables into supported combinations let me know and I can email you what I'm using.

[Altera_Forum]

--- Quote Start ---  So here are my thoughts: 1 - I never noticed this before, I wonder if it's a recent addition to the documentation. 2 -  Yes you can. According to the table, the only combinations you couldn't use would be: 0111 1011 1101 1110 0101 0110 1001 1010 3 - Have you tried it? Honestly I think I'd just try it anyway and see what happens. It may just work. It seems like if you always present a word address, the byte enables would be taken as they are given. I'd be surprised if there is actually some logic in the interconnect fabric that manipulates them. Try it. 4 - It does seem a little odd to me that you would be writing random bytes within a word. Especially pixel data. Are you sure you can't just buffer up multiple pixels and perform a single write. I guess I just don't know enough about what your trying to do to understand the usefulness.   Jake  --- Quote End ---     Hello, I have created a Qsys system that consists of a JTAG to Avalon Master Bridge (Master) and an Avalon Memory Mapped Slave. Here the master is 32 bits and the Slave is 16 bits. Am I supposed to use byteenable here as the width of data is not same for master and slave? The byteenable is a input signal within the qsys system. How can I set the byteenable to be "0011"? And do I set it on the master side or slave side? I will appreciate if you can help me with byteenables. Thanks.

[Altera_Forum]

You set the byte enables on the master side, I haven't used that bridge before but it should be possible to do 8, 16, and 32 bit (aligned) accesses. You don't have to use 8 or 16 bit accesses for the narrow slave, if you perform a 32-bit access the interconnect will chop that up into two sequential 16-bit accesses for you. If you created the component with the slave port and have not included byte enables I highly recommend doing so, I have seen lots of people shoot themselves in the foot by not including byte enables on their IP.

[Altera_Forum]

--- Quote Start ---  You set the byte enables on the master side, I haven't used that bridge before but it should be possible to do 8, 16, and 32 bit (aligned) accesses. You don't have to use 8 or 16 bit accesses for the narrow slave, if you perform a 32-bit access the interconnect will chop that up into two sequential 16-bit accesses for you. If you created the component with the slave port and have not included byte enables I highly recommend doing so, I have seen lots of people shoot themselves in the foot by not including byte enables on their IP.  --- Quote End ---     I added a byteenable (2 bits) on the slave side. Does this mean the only valid master addresses are: 0x00 0x04 0x08 0x0C ... and son on. ( I can no longer use address 0x02, 0x06, 0x0A..)? Also I have no clue as to how set the byteenable on master side as 0011..if you have any idea, please help me out. Thanks.

[Altera_Forum]

Yes that is the case. So if you wanted to perform a 16 bit access to addresses 2-3 of your slave port the master would present an address of 0 with byte enables 1100. By the time the access hits the slave port it'll be presented as a 16-bit bit word offset of 1 and both byte enables will be high. Also this assumes the master presents byte address and the slave accepts word addresses. Qsys now lets you specify word/byte accessor for both masters and slaves, I typically stick to SOPCB style addressing (masters=byte, slave=word) so that my stuff will work in both tools. 

 At the end of the day if you have a master and slave that follows the Avalon specification you don't really need to care what the interconnect does. That's the whole point of having the spec.  In your .tcl code if you tell it to perform a 16-bit access at say address 2 then the master will figure out what to present to the fabric for you (address = 0, byte enable = 1100). You just need to make sure that the address you perform reads and writes to are aligned to the width of the access you are performing.

[Altera_Forum]

Thank you so much. I have another question. I am passing the address out from the slave (conduit) and a signaltap file monitors all the values. Internally the address is getting messed up.  

For the master_read_16 commands-- Master address = 0x00 ……………………………. Slave address = 0x00 Master address = 0x04 ……………………………. Slave address = 0x02 Master address = 0x08 ……………………………. Slave address = 0x04 Master address = 0x0C ……………………………. Slave address = 0x06   For the master_write_16 commands-- Master address = 0x00 ……………………………. Slave address = 0x02 Master address = 0x04 ……………………………. Slave address = 0x04 Master address = 0x08 ……………………………. Slave address = 0x06 Master address = 0x0C ……………………………. Slave address = 0x08 I get it that the address provided by the master it is shifted right by one bit when it arrives at the slave. This is indeed happening when I perform master_read_16. But when for master_write_16 this is not true. Why is the internal address mapping different for reads and writes? Also Byteeable is always 00 while write operation. Is that right?

[Altera_Forum]

In your system console code are you reading from 0, 4, 8, etc...? (that's what it looks like to me). If that's the case then everything looks fine to me. If you want to access each 16-bit word you should be coding your .tcl file to read from 0, 2, 4, 6, 8, etc.... Again don't worry about the master itself, it'll do the right thing by presenting the following sequence: 

  Address Byteenables 0 0011 0 1100 4 0011 4 1100 8 0011 8 1100 etc...

[Altera_Forum]

yes, this is happening when I perform reads. But while write operation byteenable is always 00. Also it seems like if I only create a 2 bit byteenable for the slave and do not set master byteenable to 0011 ( I do not know how to set it), this is exactly same as having no byteenable in the slave. Probably that make it native addressing and not dynamic.

[Altera_Forum]

On reads the master most likely asserts all the byte enables and filters out the extra data that returns. So if you read from 0 followed by 2 I would expect two 16-bit reads for each access by the master. So for the read at address 0 I would expect word 0 and 1 to be read from the slave and the master will ignore the upper 16-bits that returns. Likewise for the read at address 2 I would expect word 0 and 1 to be accessed again only the lower 16-bits will be thrown out. I hope that made sense, this is usually easier to show using pictures.....

[Altera_Forum]

hi, i have the same problem of the first user: 

write RGB pixel data (24 bit) in memory. my custom master data width is 128 bit like the memory controller.  can i write for example 3 pixel (so not a power of two) using the byteenable?  how can i do that?

[Altera_Forum]

That is not supported but if you aligned your pixels to 4 byte boundaries it will probably work. That said I would just waste some memory and just store your pixels as 32 bit data. Then your master can access multiple pixels without having to worry about unsupportted byte enables. If you look at the video NEEK designs you'll see this achieved with the streaming ARGB to RGB (or whatever it is called)

[Altera_Forum]

Thank you, this is the solution I've already found. Now in have a frame reader and it wrote a writer component too with same data format. I looked at your sgdma too ..impressive work!