Forum Discussion

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

Nios 1 vs Nios 2

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....

17 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

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

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

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

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

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

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

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

    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.