Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

SOPC builder reports "Generating non-optimal logic"

The SOPC builder seems to have a bug that causes it to report that it is "Generating non-optimal logic" for address decodes of tightly coupled address/data when there is nothing really wrong.

This seems to be reported whenever tightly coupled memory is placed at a lower virtual address than the main address/data interface.

I would have thought that the intention of this warning it to report when the tightly coupled address splits the other slave addresses.

My suspicions are raised somewhat by the error message which always reports a range of (0xffffffff-xxxxx) for the range of the address/data master. I would have thought that this would be a 'low-high' range! So the whole thing stinks of a signed v unsigned compare fubar in some code that scans through the slaves attached to the data/address master to find the bounds of all the slaves. The 'low' value being set to ~0u with the intention of it being reduced by each slave.

There is the associated issue that quite a few Altera documents suggest using single bits to identify slaves in order to reduce the amount of logic. Since the SOPC builder fails to give any useful information about how the addresses are decoded (and what aliases exist), it isn't actually clear that this is actually useful.

In order to generate small address decode logic for a system with a few 8k memory block, some small IO, and a 16MB SDRAM it seems to me that it is necessary to be rather more explicit about the address aliasing than the SOPC build allowes.

Anyone any thoughts or words of wisdom?

Should we just ignore this warnign message?

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Datasheet "Using Tightly Coupled Memory with the Nios II Processor", April 2009, p.11:

    "To simplify address decoding, you can map the high-order address

    bit to a unique location. By limiting the decoding logic to one bit, you

    minimize the effect of address decoding on fMAX. The Nios II

    component works correctly even if the address map is not optimal;

    however, it displays a warning during system generation.

    As an example of optimal address mapping, if all the normal

    memories and peripherals in your system occupy addresses below

    0x2000000, mapping your tightly coupled memories at addresses

    from 0x2000000 and above satisfies this requirement."
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    I'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).