Strange SoPC Address Clash

[Altera_Forum]

Hi, 

 I have an SoPC system with a number of components interconnected via an Avalon Bus. The address bus is 8-bits wide, so the address space is fairly constrained. A number of the components are ViP (Altera Video Processing Suite) components. I have assigned the addresses in the normal way and SoPC builder is initially happy. When I generate the system, about half-way through the process, an error is generated indicating an address range overlap between components.   As an example, I have the VIP_SCL in Bilinear Mode with a start address of 0x40. SoPC builder then calculates the end address as 0x47, which is correct. If I, however, try to place anything in the area 0x47 to 0x5f, I get an address overlap error between the scaler and whatever I put there during the system generation. I assume that this is because the scaler could potentially occupy the address range from 0x40 to 0x5f, if you used the Polyphase mode. I do not, however, use it in this mode and since the mode is not run-time configurable, I cannot see why the full address range needs to be reserved.   The strange thing is that SoPC builder initially indicates an address range of only 0x40 to 0x47, and there are no error or warning messages in the message console. But if you generate the system, at some point, it seems to think that it requires the full 0x40 to 0x5f range.    I can work around this, although with an 8-bit address it becomes difficult, but I was wondering if anyone knows what is going wrong and if there is a way to correct it. (BTW I am using 9.0SP1).   Thanks! Niki

[Altera_Forum]

Out of curiosity, Are the VIP components behind a bridge? I saw this problem once before as well but it was the Clocked Video Input Block rather than the scaler that was causing the grief. I don't recall as to whether I ever found the cause. I'll go back through my emails to the Altera guys and see if we ever figured out the problem.  

 Jake

[Altera_Forum]

Hi Jake, 

 No, I have no bridges. I have two masters, though. I have seen this from more than one VIP core. It seemd as if it happens with cores that have options that, if selected, would increase the address space. The core seems to require its maximum address space, irrespective of whether it is actually required. I would have accepted this if SoPC Builder reserved the maximum address space from the start, but it does not - it seems to only reserve the address space required by the current selected compile time options, but when you generate the system, somewhere, the full address range is again applied.   Since you mentioned the clocked video input core, I might as well ask you about some weird behaviour I have seen from its registers. I read the Stable Video bit in the status register to see when stable video is being input. The first time I supply video, it works correctly, but it remains set. Even if I remove the video. I cannot seem to get this bit cleared once it is set. Am I missing something here? It is pretty useless if it indicates Stable Video with no video source connected! It would have made sense to make it a "sticky" bit so that the other status registers remain valid and stable while it is '1', and then once it is cleared, the video is again detected.   Thanks (sorry for the subject change!) Regards, Niki

[Altera_Forum]

I long ago replaced the clocked video input block with my own.  

 I would suggest two things: 1 - What type of video are you bringing into the clocked video input. If you take the video away, does it continue to receive input? Meaning, would the clocked video input block have any knowledge that the video was taken away? If it stops receiving a clock or a data valid signal (depending on the type of video) it may just be waiting for more data and not knowing that it actually lost a signal.  2 - Are there any changes to the other status bits (bits 1 - 7) of the status register when you've lost video?  Jake