Single address Avalon MM slave

[Altera_Forum]

<Accidentally posted this on the Nios General forum. My fault.> 

 Quite often I create a peripheral that just uses a single word of data. The Avalon spec. states that the width of the address bus must be 1-64. Thus, I must necessarily waste a word location for every instance of this peripheral I use. It prevents memcpy() type of operations on a group of such peripherals unless I do specific decoding on address = "0" (to avoid double hits). Is there a way to avoid this ?  Thanks,  J.

[Altera_Forum]

What has the width of the address bus got to do with this? 

 If you are accessing avalon slaves from a Nios cpu then you really want to make your slaves have a 32bit data interface - even if you ignore all the high bits and return zeros on reads. If you have an 8bit slave then a 'bus width adapter' is inserted that converts the 32bit transfer into four 8bit ones with the byte enables set appropriately (ie 3 of the write requests won't have the byte enable asserted). Reads by the Nios always assert all 4 byte enables.

[Altera_Forum]

If I only have one single 32-bit register to write, I still must use address: STD_LOGIC_VECTOR(0 DOWNTO 0), which actually spans 2 32-bit words. Ideally, I would write: 

 ... IF avs_write = '1' THEN -- Address not used. Only writable register.  reg <= avs_data(2 DOWNTO 0); -- Only three bits are needed  go <= '1'; -- Write with side-effects! END IF; ...  but now the condition must be:  IF avs_write = '1' AND avs_address = "0" THEN...  to avoid false triggering of signal 'go', apart from the fact that my memcpy() to an area of, say, 32 peripherals takes twice as long as needed.

[Altera_Forum]

Is your problem that it won't allow you to have one slave at address xxx0 and another at xxx4 ? 

FWIW memcpy() isn't defined (or required) to use 32bit accesses, nor to copy the data is any particular order. So you are better coding any transfer loop directly in C. Given the Nios instruction set having different 'strides' for the source and destination will have to effect on the code size.  Your slave must also look at the byte enable for the low 8 bits, you shouldn't assume it is set.  I'd also consider using a single Avalon slave and muxing your 32 devices below it. It might save logic (since the optimiser might effect that anyway).

[Altera_Forum]

--- Quote Start ---  Is your problem that it won't allow you to have one slave at address xxx0 and another at xxx4 ?  --- Quote End ---    Indeed.    --- Quote Start ---  FWIW memcpy() isn't defined (or required) to use 32bit accesses, nor to copy the data is any particular order. So you are better coding any transfer loop directly in C. Given the Nios instruction set having different 'strides' for the source and destination will have to effect on the code size.  --- Quote End ---    You are entirely correct wrt POSIX memcpy(). I have gotten too much used to the default (linear) copy implementation :).    --- Quote Start ---  Your slave must also look at the byte enable for the low 8 bits, you shouldn't assume it is set.  --- Quote End ---    I do require that the register is always accessed as a 32-bit DWORD (alt_u32). Doesn't that guarantee correctness ?    --- Quote Start ---  I'd also consider using a single Avalon slave and muxing your 32 devices below it. It might save logic (since the optimiser might effect that anyway).  --- Quote End ---    That's a good idea, but it somewhat defeats the purpose of the automatic fabric generation by SOPC Builder / Qsys, does it not ? Still, thanks for the useful comments and suggestions.

[Altera_Forum]

--- Quote Start ---   I do require that the register is always accessed as a 32-bit DWORD (alt_u32). Doesn't that guarantee correctness ?   --- Quote End ---   Depends if you can really guarantee it. If, for instance, you connect the slave to the PCIe to Avalon bridge, you'll see two 32bit cycles generated for a single 32bit host transfer (because there is a 64 to 32 bit bus adapter and all PCIe cycles are actually 64bit). So it really isn't worth ignoring the byte enable.