Forum Discussion

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

Very confused rank newbie looking for advice

Hello All:

I have been evaluating various ucontrollers such as the Atmel AVR line, the huge ARM family and PIC. In recent years, all my dev work has been high level PC based. The advances in embedded products has really blown me away.

In the process, I came across the BeMicro SDK. I have no idea whether the FPGA approach would fit into my plans, but need to know my options before I might go down the wrong path, which is why I'm here. I have tried to do my homework, but I still don't see where the FPGA fits in the whole embedded/micro picture.

Keep in mind, I'm an old fart and any FPGA work I've done is just using an FPGA or GAL to consolidate glue logic and perhaps add a peripheral such as a timer/counter to the design.

One of the NIOS features mentioned is multi-core support. Is a given core architechture re-created inside the FPGA, or is the FPGA configured to run, in hardware, the equivalent of a subroutine written for a certain processor? IOW, is a micro/FPGA decision an either/or or do the two work together? Unfortunately, the Altera/Arrow workshop has already been held in my area.

Does the FPGA i.e. NIOS replace a ucontroller, or does it act as a peripheral that provides hardware acceleration for specific tasks?

I'm frustrated because I'm not sure if I'm even asking the right questions. I think a real-world example of where NIOS might be used would help a lot.

The videos and appnotes I've viewed assume a lot of knowledge that I just don't have, so if someone could give me the Readers Digest version, or point me to a good introductory appnote, I would be in your debt. I don't want to be spoon fed, but I really need a starting point.

Much thanks in advance.

Bob

5 Replies

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

    Hopefully I can answer a couple of your questions. NIOS is just a CPU core that is implemented using the FPGA logic. As far a what a CPU does, NIOS and a stand-alone CPU (AVR for example,) are identical. The difference is in the features supported and the compiler needed. With NIOS however, you can choose which peripherals you want to add - USB, SerialPort, Ethernet... You can also add your own peripherals if you want.

    As far as the advantages of one vs the other, there are a few details to consider:

    - Performance: A stand-alone processor may have better performance depending on the FPGA used.

    - Price: ARM processors are really cheap. You have to figure out how much logic NIOS will take up in your FPGA and see if you can afford that logic. If adding the NIOS core pushed you into a bigger FPGA, then cost becomes a factor.

    - Board design: With NIOS, you don't need the extra real estate and layout required using a separate CPU chip.

    To get started, download the NIOS IDE and create a new project. I am a little rusty here since it's been a while since I needed to use NIOS, but I remember a hello world sample program taking less than 1 hour to create, configure, compile and run on the target. Once your target is setup though, the process only involves the compile and download steps (few seconds to a couple of minutes...)

    If your programs are small, you could configure the NIOS to run using the FPGA internal RAM. If you need more memory, you will have to interface NIOS to external RAM.

    Hope this helps.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks for taking the time Moose. You've cleared up things for me, I think. ;-)

    If I understand right, it's all about fit, functionality and optimization. The NIOS is just one core implementation on the FPGA. I assume, one could implement just about any core, if the FPGA is big enough.

    Option 1 - Choose an off-the-shelf micro that has the features closest to the application. Write the code and you're done.

    Option 2 - Choose an OTS micro that has more than is needed, for future expansion.

    Option 3 - Choose an OTS micro and add specialized peripherals e.g. LTC 2400 24 bit A/D

    Option 4 - Pick an FPGA, and a core design, design needed peripherals with remaining gates then write code. Extra peripherals/ram/flash may be needed.

    An FPGA has the advantage of being almost 100% reconfigurable but there's an extra step to configure (and debug!) the on-chip peripherals. There may be some speed gains in implementing some functions in hardware, which would be software in an OTS device.

    From where I sit, the FPGA solution is not really an option for prototypes or low volume runs. Any device cost savings would be lost in development costs. If I buy an OTS micro dev board, I can buy a micro that is over the top, but then I'm coding right away. Once my design is set, I can downscale to a more appropriate device.

    I'm not saying this as gospel; it's just how I see things right now.

    If I'm missing something, I encourage you, or anyone else, to set me on the right path.

    Cheers,

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

    You pretty much got it so far according to your summary. It kind of boils down to this:

    - If you have to have and FPGA for reasons other than a CPU core, then NIOS should be considered as an option.

    - If you are adding the FPGA just to have a CPU core, you have too much money or you work for the government.

    Keep in mind that with an FPGA core, once the peripherals are debugged, it becomes an asset that you can build on for later projects, just as you would a DLL or shared object in the software context.

    BTW, OTS solutions work great out of the box until you start adding your own drivers and such, then the fun begins... kernel re-compiles, build tools... you will have to deal with this in NIOS development too...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    - If you are adding the FPGA just to have a CPU core, you have too much money or you work for the government.

    --- Quote End ---

    D. None of the above

    --- Quote Start ---

    BTW, OTS solutions work great out of the box until you start adding your own drivers and such, then the fun begins... kernel re-compiles, build tools... you will have to deal with this in NIOS development too...

    --- Quote End ---

    Don't I know it. In a previous life I was knee-deep into 8051 territory, most of it assembler (drivers and rt kernels), upwards of 500k lines.

    I have a genetic defect that enjoys optimizing code & debugging, so it's not all bad. ;-)

    As for the FPGA route, it's not for this app, but I will keep it in my back pocket for the future. The geek factor of a totally configurable "virtual" device is appealing, but my age has taught me that it's potentially a serious time vampire.

    So, it's AVR for me. Wide product line, app notes galore, good dev suite & libraries and tons of cheap eval boards.

    ARM is very cool, (and cheap) but spread among too many vendors, so support seems very variable.

    Many thanks for helping me clear the fog.

    No longer confused Bob.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    With care you can get the nios to execute very small C functions with no external support libraries (you need to set 2 registers then jump to any C function).

    Rip out all the caches and run from 'tightly coupled memory' and the cpu footprint is about 2500 LEs - not a lot in the modern fpgas.

    So the whole thing will be a lot more flexible than the 8051/pic stuff.

    Not sure I'd want to run something as big as Linux (or even a normal embedded os) on the nios though.

    But for a bare board, run some code for a small app it requires a lot less hardware setup than the SoC systems - partially because the hardware config removes a lot of the stuff that the software would otherwise have to do.