Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12590 Discussions

Problem with the new Nios II 1.1 release

Altera_Forum
Honored Contributor II
1,376 Views

Hello, 

 

Altera has released Nios II 1.1 for Quartus II 4.2. I downloaded the evaluation version and installed it. After generating the new system in SOPC Builder and synthesizing the system in Quartus I have a problem with the new release. My system includes an external bus (Avalon Tri-State Bridge) for Flash, CompactFlash and Ethernet. All devices are no more accessible! Has anyone the same problems? 

 

Bye, 

niosIIuser
0 Kudos
15 Replies
Altera_Forum
Honored Contributor II
424 Views

By not accessible do you mean you can't access them in software, they disappeared from the hardware, etc..... ? If it's partially working what are the components that do not seem to be working?

0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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 ?
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

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).
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

 

--- Quote Start ---  

originally posted by mir@Jan 12 2005, 10:24 AM 

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. 

--- Quote End ---  

 

Mike, 

 

Thanks for sharing your explanation here. One note, though, what you&#39;re describing is the difference between an avalon "memory slave" (called dynamic bus sizing) versus "register slave" (called native addressing). In a nutshell, the CPU always "thinks" in byte addresses, so when talking to a register slave the low two address bits may be shifted right (going from the CPU to the peripheral); thus, the CPU has to go to the next "word" in memory (address+4) to get to the next peripheral register, regardless of the data width of the peripheral. 

 

My hunch is that somewhere in the upgrade process this mode (for your peripheral) got changed. If you&#39;d like to pursue this further we can discuss more.. on the other hand if you&#39;re content with the current behavior I&#39;ll leave it at that. 

 

BTW -- if you are not talking to memory, but rather registers, I would reccomend keeping the avalon mode as it is now.
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

Here&#39;s a pretty good table showing what we mean. 

 

http://www.altera.com/literature/manual/mn..._avalon_bus.pdf (http://www.altera.com/literature/manual/mnl_avalon_bus.pdf

 

Page 100. In this case you have a 32 bit master talking to a 8 bit registered slave (native alignment).
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

Hello, 

 

Here is some new information about my design. The CPLD which is connected to the external bus is using only one address. And after changing the timing of this “Interface to User Logic” in SOPC it is possible to write to a register which is implemented in the CPLD. So now this one is working. But changing the timing of the others components has no positive result. At the moment I don’t have enough time to check the things with a logic analyzer (and unfortunately I don’t have one here) but I think the above information could help in finding a solution. 

 

 

Bye, 

niosIIuser
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

Hi Jesse, hi BadOmen, 

 

I know what you mean. But this (normal) behaviour has begun now with NIOS II 1.1. My design grew up as NIOS/Quartus grew up. So I don&#39;t know under which conditions I&#39;ve created these 8-bit-interfaces. But it worked in all previous versions (NIOS 3.1 to NIOS-II 1.01) with byte offsets. 

But this issue is obviously not niosIIuser&#39;s problem. I think about updating again to NIOS II V1.1. 

 

Thanks for your help. 

 

Mike
0 Kudos
Altera_Forum
Honored Contributor II
424 Views

Hello, 

 

Now the problem is solved. Like it was discussed several times in the forum I had to change the address when using IOWR and IORD. But this was not the only thing I had to change. The system was running with a system clock of 70 MHz. Now it is only running with 65! It’s the same design. Nothing has changed except using Nios II 1.1 and not Nios II 1.0.1. 

 

Bye, 

niosIIuser
0 Kudos
Reply