Problem with the new Nios II 1.1 release

Hello,

Ok I should clarify the behaviour in more detail. I have the following configuration for the external bus:

ext_io_bus (Avalon Tri-State Bridge)

- ext_cf (Interface to User Logic, CompactFlash)

- ext_flash (Flash Memory, CFI)

- ext_cpld (Interface to User Logic, CPLD registers)

- ext_dm9000 (DM9000 Interface, Ethernet)

In SOPC Builder all is like before updating to Nios II 1.1. Generating makes no problems and synthesizing too. But when trying to access the devices of the external bus by software they can’t be reached. That means that there is no or nonsense communication between the processor and the external devices. All others components (internal modules like JTAG-UART, I2C, …) seems to work correctly.

I didn’t check the signals with a Logic analyzer yet. I only want to know if someone has the same problems after the update. I tested the design with Quartus II 4.2 and Nios 1.0.1 and all was working fine. Perhaps there is a mistake in the design which was ignored when using Nios 1.0.1 and now it is coming up.

Bye,

niosIIuser

Hi niosIIuser,

Yes, I had the same problem.

After updating to NIOS II V1.1 and recompiling my design, all shared avalon slaves had their own read_n / write_n pair even if sharing was selected.

( see thread (http://www.niosforum.com/forum/index.php?act=st&f=17&t=820) )

This could be solved by additional OR/AND gates. But the main problem was, that sub addresses of user logic blocks were scrambled. It looked as if some address lines were internally swapped. I checked this also with signal tap. So accessing a peripheral at a specific address offset results in an access to a quite other location (The base addresses were OK). I deinstalled V1.1 so I cannot figure out more details.

Mike

MiR,

Do I understand you correctly ... you went back to Nios-II 1.0.1 ???

[or whatever version of SOPC builder] ???

This sounds like a BIG problem. Did you contact Altera regarding this

issue? ... any reply?

Regards,

--Scott

All,

Do any of you have an archived copy of your pre-quartus-4.2 design somewhere? If so, can you carefully examine the top-level SOPC-Builder-generated module and look at the address bus(es) going to your external peripherals please (in comparison to the one that was just generated and doesn't function)? The reason I ask: there was a change in Quartus II 4.2 (SOPC Builder) -- a bug fix in how address busses are generated -- that may *remove* a top-order address pin in interfaces to certain external busses. So for example, you may have previously had A[6..0] popping out the top and now have A[5..0]. As you can imagine this can be a problem if software was written to use this address pin, or depending on how the A[] bus is hooked up to the outside world in your top-level HDL or schematic capture.

We are working on posting a detailed explanation of this problem and workarounds to the Altera website at the moment -- this *may* not even be the problem you're seeing in your system, but it sounds awfully familiar.

I'd type out a long-winded explanation this second but I am hoping to have a web-link that I can paste here shortly.

EDIT: what I say above applies for the symptoms niosIIuser is reporting. What MiR was seeing was something different, based on the new 'Component Builder' - that is a separate discussion but one that should not require going back to Nios II 1.01 to solve.

Hello Jesse,

If I understand you correctly you mean the top-level in the schematic of Quartus. The size of the external address bus has not changed. The device which is using most address pins is the flash (22 Address Bits -> 4 MByte). I don’t think that it is a problem with Quartus II 4.2 because when using Nios II 1.0.1 all is working fine.

I will wait for your long-winded explanation to see if it is the solution.

Thank you for your help,

niosIIuser

Thanks niosII... well it may be some other problem then -- I'd stilll examine things closely. Yes, I was referring to the top-level BDF schematic block.

This change would have occured the first time you re-generated your system using SOPC Builder from Quartus II 4.2. You're correct, its independent of Nios II version.

Hello Jesse,

Thanks for your response. Unfortunately I do not have a copy of my Quartus 4.2 / NIOS2 V1.1 compilation. After these problems I've done everything to get rid of it and restored my previous environment (Quartus 4.1 SP2 and NIOS II V1.01) . But I did not see that the size of the address bus had changed. The problem arose in a small peripheral interface while the size of the address bus was set by a 1MByte SRAM. I remember, when debugging with signal tab, the state of the address bus showed the correct value when I swapped the bit order of A[6..0] to reverse (LSB on Top, MSB on Buttom). So I think, that anywhere during compilation a wrong bit order occured. This interface originally was created as 'Interface to User Logic' and then rebuilt with 'Create New Component'.

I have now installed a Quartus 4.2 Web edition / NIOSII V1.1 on a notebook and will try to isolate this issue in the next days.

Regards

Mike

niosIIuser, could you check, if an access to any specific address really generates this address ?

After installing quartus 4.2 web edition together with NIOS II 1.1, I've figured out what happened. I've created now a CPU with two shared avalon slaves:

- a SRAM interface 256K x 32 (Memory with 18xAddr, 32xData, CS, RD, WR, 4xBE)

- a Port interface 1k x 8 (Register 9xAddr, 8xData, CS, WR)

With the new version of NIOS II (1.1) a 8-Bit register slave uses the same address scheme as a 32-bit register. Byte accesses to offset 0, 1, 2 and 3 always result in an access to address 0. So every software address has to be multiplied by 4.

This behaviour differs from previous NIOS versions, where avalon slaves with byte width are accessed in steps of one.

niosIIuser, could this perhaps be also your problem ?

Regards

Mike

If you generate the system, how many address lines do you see coming out for your 8 bit port? (I would have expected 10, but maybe you are seeing 12).

Also you said you installed Quartus II v4.2 web and Nios II 1.1, what did you have installed previously? (trying to figure out if it is specific to Nios or Quartus).

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

With the new version of NIOS II (1.1) a 8-Bit register slave uses the same address scheme as a 32-bit register[/b]

--- Quote End ---

In the past whenever I was using registered components this was how I would address them. Eventually your data has to become 32 bit since that&#39;s what the processor will be working with. So I&#39;m a bit confused on how this could be just occuring upgrading to version 1.1 (to me this has always been how I would address the peripheral).