Honored Contributor
Honored ContributorI'm not sure that comment has anything directly to do with reality - especially with respect to that warning message.
If you do some experiments you'll discover that the 'non optimal logic' message does not appear when all tightly coupled data areas are higher than all Avalon MM data addresses - even when a lot of address bits have to be decoded in order to determine whether an address is tightly coupled or not. If you look carefully at the error message, I think it is trying to report a 'window' error, but the code has a signed v unsigned fubar and has failed to correctly determine the upper bound of all the tightly coupled data. The 'single bit' selection between tightly coupled and Avalon MM data addresses should be valid for the 'bit set' and 'bit clear' cases. Unfortunately it isn't possible to look at the decode logic, nor have any control over what is generated. Related to the fMAX stuff, is that I've not seen any address aliasing (where intermediate address bits are ignored), so it looks as though all address bits are checked. Consider a system with a variety of small peripherals (including M9K memory blocks) and a large block of SDRAM. The smallest SDRAM is about 16MB (DDR2 is likely bigger), everything else is probably much less than 1MB - so could be aliased 16 times to save address decode. Similarly a small block of PIO (which might only be 32 bytes) could be aliased to fill (say) 8k - again reducing decode logic. There are other places where address aliasing can be useful. For instance aliasing a memory block used cyclically by software can significantly save code (you don't need to check for wrap anywhere near as often).
