Addressing unmapped memory space results in unpredictable behavior

[Altera_Forum]

Hi folks, 

 Searching for a stubborn error, I came across the following behavior:  When an avalon memory mapped master (for example NIOS) writes to an address, that is not mapped to any qsys component, the write will not get lost (as I would expect it), but any random component will get assigned!  By looking at the technology map, I can see the reason: Qsys interconnect does not perform full address correlation, but only checks on certain bits that are expected to get used.  Of course if someone writes to an unmapped memory address, there must be a problem with the code or something.   But anyway - is there a simple way to prevent random components to get accessed, when writing to an unmapped memory area?  Best Regards, Simon

[Altera_Forum]

Several versions of Quartus ago I had a similar problem. I created a custom component that triggered an interrupt upon any access to its Avalon slave port. It ignored writes and returned 0 for reads. I created several instances and set the addressing so that they collectively covered most of the 32 bit address space that wasn't used by other components. That was enough to debug where my rogue accesses were coming from.

[Altera_Forum]

The interconnect generated is supposed to handle read/write commands sent to unmapped address locations. Nothing should happen. Have you tested and proven that something is getting written somewhere that you don't expect?

[Altera_Forum]

In my case I needed to find out what was accessing invalid addresses. I had my ISR read several registers in the master devices which were later printed to the console. It helped me discover which master was generating bad writes.

[Altera_Forum]

Thanks for the ideas. 

 I'm using Quartus II 13.1 (latest version to support our Cyclone III FPGA).    --- Quote Start ---  Have you tested and proven that something is getting written somewhere that you don't expect?  --- Quote End ---    The actual error I'm targeting occurs only once per month or so, so it's very hard to find and I couldn't prove that it's actually caused by a write to unmapped memory. But what I proved is, that when NIOS writes to unmapped memory deliberately, the write gets assigned to another custom memory mapped component which as a result causes the error I'm looking for.    --- Quote Start ---  I created several instances and set the addressing so that they collectively covered most of the 32 bit address space that wasn't used by other components.  --- Quote End ---    I also thought about filling the unused memory space, just to cover all the addresses, but I haven't tried it yet.  I have two masters in my system that can write to the component in question (NIOS and an external DSP). It would help a lot, if I knew which (if at all) is causing the problem...

[Altera_Forum]

With a rate of once every month or so, look into single event upset as well.