Nios 1 vs Nios 2

[Altera_Forum]

We have an avionics lighting group in our company that is expanding into newer technology. It is only a matter of time that they will need a super low cost micro solution. I am in a group that designs avionics display products and they have approached me on micro suggestions. I believe that the NIOS is the way to go. However, I am divided on whether to suggest the NIOS1 or NIOS2. The applications will be unbelievably simple and straight forward. The reason I would even suggest NIOS1 is this group has no software engineers. They know just enough C to be dangerous. The NIOS1 SDK is easier for non software types, and there is a layer of abstraction in the NIOS2 that may be confusing to engineers who only know C. I know that NIOS1 will probably not be supported, but I know that they would have trouble with NIOS2. They will not be able to hire an engineer because there is a hiring freeze. They can only get some support from our group. The NIOS1 support may not be an issue to them because we archive all tools, drivers, debuggers, etc for every project because these products may be in service for more than 20 years. If they need a software change in 5 years, we would use the same tools as they used in the initial design (unless there is a bug or update). Thoughts....

[Altera_Forum]

If you already own NIOS I and speed isn't an issue then stick with it. 

 However, NIOS II is smaller, faster, and it's not too bad for programming (I'm a hardware guy and I have very little problems programming on NIOS II, mind you I don't do complicated stuff like OS programming).  If you have neither core take NIOS II because of the advantages (that and the assembly language of NIOS I is already obsolute so an upgrade to something else like NIOS II, or NIOS III (if it comes to that) if they did do ASM code they would have legacy problems).

[Altera_Forum]

Nios II supports the Nios I SDK so there really isn't any reason for you to use Nios I. 

 As you point out, you could stay with Nios I for many years without any problems  but you'll be more on the mainstream if you switch to Nios II. One of the great things about the Nios I and Nios II soft cores is that we just use normal VHDL/Verilog and Quartus synthesis so supporting a variety of FPGA devices is pretty straightforward. Altera is pretty good about having new devices be compatible with old ones so you should have few problems migrating Nios I or Nios II to newer FPGA devices as they become available. This is one of the advantages of soft-core CPUs over hard-core CPUs on FPGAs.  Given all this, I must say that our focus at Altera is now on Nios II development. Nios I is basically in maintenance mode with bug fixes.

[Altera_Forum]

If we opt for the NIOS2/SDK approach, is Altera going to support the SDK? As I said before, simplicity and code size would be the main goal for this product line. Our application must fit on a small fpga such as a Cyclone 1C3 or 2C5 (when it's available). I have been working on single chip solutions using a 1C3 and have done amazing things with it. FPGA, config device, xtal... doesn't get any better for a super small app! 

  Rick

[Altera_Forum]

I have a HW friend who grooves to the NiosI dev environment, but the Nios2 IDE might as well be straight from the Alien Spacecraft. Personally, I'm a software guy and prefer the new IDE, but until Altera gets real about code size and fixes a truckload of teething bugs, I'm sticking with NiosI as well. 

 A halfway approach would be to use NiosII but with Legacy SDK support.   But IMO there are plenty of LE's on the chips that make sense to us financially, but very little RAM and flash. Right now NiosI makes more sense for us.  Ken

[Altera_Forum]

Legacy SDK support will be there for Nios II for as long as I have a say :-) 

That's the main thing I test, so it is being tested and supported. Personally I prefer it to the IDE also. But I do see where software people would love the IDE.

[Altera_Forum]

Oh I almost forgot. Another difference between the two is if you need to optimize your code doing assembly, you'll have a much easier time with NIOS II then with I. I can't tell you how many time I've cursed outloud because I used the wrong cc_xx code due to the reverse logic in NIOS I.

[Altera_Forum]

--- Quote Start ---  originally posted by kenland@Aug 26 2004, 10:27 AM i have a hw friend who grooves to the niosi dev environment, but the nios2 ide might as well be straight from the alien spacecraft.  personally, i'm a software guy and prefer the new ide, but until altera gets real about code size and fixes a truckload of teething bugs, i'm sticking with niosi as well.  --- Quote End ---   KenLand,  You state that Altera need to "get real about code size". The new software scales to the same size as the old SDK, have you tried the recommendations in the Reducing Code Footprint section of the Software Developers Handbook?   It was a conscious decision to provide full featured systems by default, but if code size is your main focus the code scales down.

[Altera_Forum]

Ya the recommendations help a lot. 

 I took something that had a 70kB footprint and brought it down to 4kB with a few changes here and there (I'll admit as a hardware guy I was kinda lost on how to do those at first, but 30 minutes later I got things working fine).

[Altera_Forum]

rugbybloke, 

 IMO NiosI/II are primarily embedded products that should therefore assume footprint is of primary concern.  If you're going to create a slick GUI frontend then you need to go all the way and make it do what the customers need, comments in HelloWorld.c are not exactly the 'A' solution. Altera knows that and I'm confident they will address this in future releases. I fully plan to switch over to NiosII + IDE at some point. Different people will have different thresholds.  Sure I ported my 2 processor system over using Legacy Support and yes it "worked" but I made the subjective decision that the entire chain was not yet up to my idea of Prime Time. A lot of people consciously or subconsciously enjoy obscure procedures and workarounds. Not a problem, but that's not Altera's stated goal for this product chain. I've documented, as others have, some of the bugs and overly brittle work flows in other posts. (Project setup, custom board creation, footprint size, libraries, ALLCAPMACROS, etc.)  I'm looking forward to the day when the tools and all the parts are solid to the point that the embedded engineer can forget about the tools and focus on his application. I know its a journey and don't expect overnight miracles, but the discussion of goals and shortfalls among supporters is healthy and necessary.  Ken

[Altera_Forum]

Kenland, 

 You seem to have done a lot of evaluation and have lots of views on bugs and features we could add. I would really like to hear this feedback. I have searched the boards based upon your description and can find little detail on the problems mentioned.  Please send me a list of your feature requests/bugs by private email, if you could provide more detail that would be greatly appreciated.  Thanks

[Altera_Forum]

rugbybloke: 

 I just did a test on code size between Nios1 sdk and Nios2 sdk. I generated two projects (one Nios1 and one Nios2e) targeted for a 1C3. The SOPC devices/names are the same in both projects. I also wrote a simple test program that prints messages and has a irq driven timer callback. The code compiled in both environments with no errors or rehosting (NOW THAT&#39;s IMPRESSIVE! http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/tongue.gif ). The compiler options were both the same: -Os. The Nios1 code size was about 1400 bytes and the Nios2 code was about 1730 bytes. This as about a 20% increase in code size for the Nios2, but one must keep in mind that they are different processors. With such a small program, I wonder how much of it is the difference in overhead. In another words, if my program trippled in size, would the % drop or stay at 20%? Don&#39;t know.   I have not ported to this program to the IDE/HAL yet, but based on my experience the code size would be a magnatude larger - even with some of the "code size reduction activities". If I remember correctly when I did the reduced Hello world, the code size was > 3k.  The bottom line in my opionion is if you need small code size, stay with the SDk. If you have gobs of memory, you really should be using the SDK. I have used both, and will continue to use both depending on the app. I&#39;m mainly a software engineer, and I like both environments. Although I currently favor the sdk - just slightly.

[Altera_Forum]

As a follow up to my last post I thought I should make it clear that while the legacy SDK is currently a supported part of the product, there is no ongoing development on it; it&#39;s in maintenance mode with bug fixes only. New features eg. JTAG UART are likely only to be supported in the HAL. 

  If you have an existing Nios I project there is no problem using the legacy SDK. For a new project you should probably be using the HAL.  ** Basically new components and features may or may not get supported in the legacy SDK. Legacy being the key word here. All the old components should work as they did before.

[Altera_Forum]

That&#39;s a good point Kerri. If I need any new features, I&#39;ll use the IDE/HAL. Don&#39;t see any yet, but by the time I need one the 2C5 should be available. Case closed. I could really put some impressive stuff in that sucker! It should be an impressive standalone solution for many. The 1C3 is just barely too small for small aps. The 2C5 has a lot more memory. I do plan to go 100% with IDE when the 2C5 becomes available and I have a dev board.

[Altera_Forum]

One thing is the JTAG Uart. No legacy SDK support. 

Stratix II support is a new feature, so any new component for it won&#39;t necessarily be supported.

[Altera_Forum]

I think as a default -O3 should be enabled (who wouldn&#39;t want maximum optimization?)

[Altera_Forum]

Maximum optimization can bloat code. Loop unrolling and code inlining (where it inlines functions that you didn&#39;t specifically ask it to) are favorite examples. 

 It may not sound like much, but when speed is far less inportant than squeezing into an on-chip 2K ROM, every byte counts.  IMHO, the default should be either -Os or whichever level of optimization turns on everything except the things that can bloat code.

[Altera_Forum]

Thsoe are speed only optimizations? I figured it was for speed and size. 

 With NIOS I, I didn&#39;t see any difference between -O2 and -O3 when looking at the ojbect dump file. However -O0, and -O1 I do see a difference (larger memory footprint).  If I need to squeeze code that much then I jump to ASM since you can usually get a footprint thats twice as small or more, then the original C code at -O2. I&#39;ll need to give -Os a try since I don&#39;t think I&#39;ve ever tried that before.