SOPC Address Funny

[Altera_Forum]

Hi, 

 I have video processing SOPC system containing a number of IP cores from the VIP library and my own custom library. Some of them have Avalon MM control interfaces. I have two masters - each with an 8-bit address bus and 16-bit data bus - connected to the slave interfaces. Since I have only an 8-bit address bus, addressing space is limited, but I have fitted all slave interfaces into the available address space and it has been working like this for a couple of months.    Today I wanted to do an experiment with the design and I moved a couple of connections (bypassing some modules, changing some parameters). All of a sudden I get an error that my Clocked Video Input module cannot be located at address 0x20 (it has been occupying 0x20 to 0x2f), and it suggests 0x00 or 0x40. The start and end addresses are currently indicated as 0x20 to 0x5F. It seems as if the span of the clocked video input module has changed from the usual 0x10 to 0x40! From the VIP user guide, the clocked video input has only got 7 registers, each 16-bits wide).    I have deleted all temporary files, refreshed the system, restarted SOPC Builder, but it still complains. I am at a loss of why all of a sudden, this one module spans 0x40 bytes instead of the usual 0x10.   Has anybody got any ideas?   Thanks! Niki

[Altera_Forum]

Well I do have one guess. I think it is actually a bug. I have seen all kinds of addressing mishaps in SoPC builder. It particularly seems to be a problem if the component is located behind a bridge (like a clock crossing bridge). I'd report it to your FAE. 

 Jake

[Altera_Forum]

If the slave doesn't use byte enables then the address span of the port will increase depending on the widest master connected to it. This is called native addressing and this behavior makes it possible for wide masters to access it properly. 

 So given your description of the span going from 0x10 to 0x40 and it using data path width of 16 bits so if you are seeing this behavior then I'm guessing you hooked up a 64-bit master to it.

[Altera_Forum]

Hi, 

 I have tracked the problem down to the de-interlacer core I have in the design. I have two separate Avalon MM buses in my design - the one is the control bus (8 bit address, 16-bit data, with two masters) and the other is a memory bus connecting the a frame buffer and the de-interlacer to an SDRAM controller (24-bit address, 16-bit data)   What I have seen is if I change the Avalon MM MAster Port Width setting in the DeInterlacer parameters to 64 bits or more, then I start seeing errors regarding memory range overlaps and invalid locations on my control bus side. I cannot see why the address width on the one bus should affect the address width on the other bus. I have no bridges between the two buses. They are completely separate. The deinterlacer is not connected to the control bus at all.   BadOmen, it seems that what you are saying is happening, but I cannot see why a wide master on one bus affects the other bus.   Regards, Niki

[Altera_Forum]

That's the unfortunate thing about native addressing and is why I always recommend to people creating new components to stick with dynamic slaves (use byte enables). Masters provide byte addresses and slaves provide word addresses (except for tri-state slaves which use byte addresses as well). 

 I could see this issue happening if you have two masters connecting to a native slave port. The fabric uses slave side arbitration so when you connect two masters to a slave port conceptually you can think of that as being like a shared bus. If you can attach a screenshot we might have some suggestions you can try.