Nios-II Address Bus XXXXXXXX normal?

[Altera_Forum]

About 5 cycles after reset has gone inactive, the Nios-II CPU drives 'X's (yes they are true X's, which typically means two signals are driving each other) onto the address and byte enable buses. This is an SOPC generated system, with a custom Avalon slave. The 'X' condition clears itself after 9 clock cycles. However, I see the 'X's again at a few points up to a couple hundred microseconds.  

 It's hard to debug the CPU IP since it is heavily obfuscated. However, when I debug using ModelSim (in the Objects window Event Traceback -> Show Driver) the drivers indicated appear to be only within the CPU. Again, due to the obfuscation it is hard to trace the signals to their original drivers.    Has anyone else seen this? This is a relatively new FPGA design along with untested software. So I cannot say with much confidence that it is a bug in the NIOS. But, all inputs are valid logic values - 1 or 0 - at all times.   Using Quartus 10.0.

[Altera_Forum]

Do you use a synchronized reset that is active for ~100ms (100 ms in order to make sure it reaches the entire board) ? I use the 

http://datasheets.maxim-ic.com/en/ds/max823-max825z.pdf IC, combined with VHDL code to make it synchronized. I use the NIOS II with Quartus 10.1 and I have no problems, but I'm no expert.

[Altera_Forum]

Thanks for the reply Thormodo. The problem is showing up in simulation (so even before we're getting to the board). In the sim, the reset is going inactive prior to the rising edge and is 'stable' during the edge.

[Altera_Forum]

Make sure you are resetting to a memory with valid instructions in it. Otherwise you'll probably have unknown data enter the instruction master then who knows what the masters will do after that. 

 If you are seeing an unknown address at the beginning of the simulation driven out but read and write are both idle then I wouldn't worry about that. If read or write are high and an unknown address is being sent then I would trace back in time to find out why.