Forum Discussion

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

Exchange C167 by FPGA and?

Hi,

we have an older electronic design running more and more in obsolescence issues and thus we need to do a redesign. My intention is to take the chance and switch this design to the actual FPGA based electronic. While this is no issue for hardware aspects and the functions implemented in VHDL even in this old desing, this approach raised the question on how to handle the µC software code. I "know" it is diffcult to estimate (that's why I ask the community) but I need at least a rough idea... In case I would use the C167 code and configure the NIOS II to have the used ADC, PWM, Timer, ... modules, will the C167 native C code either compile or at least compile with small modfications? Or - on the other hand - would I have to rewrite the code just using the actual one as the "guideline" and for "function description"?

I'm new to NIOS as up to now I did everything in pure VHDL and for that I tented to just take the C-code to extract the functionality and rewrite it in VHDL - which is quite some work, but implementation in VHDL is something I'm more familiar with...

Thanks a lot for any hint or information,

Sincerely, Carlhermann

2 Replies

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

    Really the only way to find out is to try to put your existing code through gcc and see what problems there are.

    Even compiling it for x86 might be informative - although building a standalone gcc for nios is fairly easy (info on the wiki), and that will give a more realistic idea of the size.

    If you only have a small amount of C code, and don't need anything thing like TCP/IP, then you can easily build something that does need any C library support. Everything will then (probably) fit in the internal memory.

    The ability to write 'custom instructions' in VHDL can help speed up the code without requiring massive and complex VHDL blocks.

    Debugging the C is also probably easier - and it goes wrong in more predictable ways! Especially if you write an avalon master interface for some external bus in vhdl (possibly multiple 8 bit transfers, or even a serial port!) that lets you read (and maybe write) any avalon address while the system is actually running.

    This is probably more use than the jtag debugger - as it lets you debug the code running in its production environment. Depending on that environment it might also be used to download the actual code.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    The C167 is a 16-bit micro with a clock speed of 20MHz. Any recent microcontroller should reproduce its functionality just fine.

    You first need to analyze the function of the C167 in the system, not just as a processor. Sure, a NIOS processor could replace your microcontroller core, but what about the peripherals used on the board? Is heavy use made of ADCs, DACs, and other microcontroller features that have some sort of 'analog' nature.

    Its very easy to interface ADCs and DACs to FPGAs, and you get the extra freedom to implement hardware-based control of these devices. However, if your design is cost-sensitive, then look at the microcontrollers on the market, eg., the Philips/NXP LPC series 32-bit ARM cores. These microcontrollers have ADCs, DACs, timers etc, and for less than $1 in some cases.

    As for code porting, it depends on how well the original code was abstracted from the hardware. For example, I use the uC/OS-II on DSPs and NIOS processors, and the code is easily ported between the two. If however, the code for your C167 uses a lot of compiler-specific extensions, then you will need to abstract those interfaces. What you can do is move the C167 compiler specific code into function calls in a separate C-file, eg. hw_access.c, and rebuild your code to confirm it operates correctly. Then rebuild the code using gcc, replacing the hardware access code with stubs, eg. hw_access_stubs.c. Your code would compile, but hardware accesses would be 'faked out' by the stubs code. This gets a little trickier with interrupt handling. But you get the idea.

    If you are considering using something like uC/OS-II (or uC/OS-III) in your new design, then you could port your existing code to this OS on the C167, and then port the code to NIOS, or perhaps one of the microcontroller boards that comes with the uC/OS-III books.

    Cheers,

    Dave