Forum Discussion

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

Nios-II Address Bus XXXXXXXX normal?

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.

3 Replies

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

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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.