Forum Discussion

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

Good practice for handling user commands in an FPGA

Hello

In my applications, I am using an FPGA that is connected to a RS232. The PC sends commands including data that has to be processed by the FPGA. Sometimes the FPGA sends respond data if requested back to the PC.

Currently im am using a state machine for reading and processing the commands. As the number of commands grows the state machines is getting longer and longer.

As this could be a typical task in many applications I assume there is a good practice or maybe there is a reference archticture available.

In my opinion the approach should at least fulfill following requirements:

1.) easy extensions if there are new commands

2.) modular programming (Split logical function in different files or modules

3.) easy readable code

4.) suited use of FPGA ressources

5.) fault-prone

I am beginner in FPGA and come from micro controller programming. There I am also working with state machines and it works very well but maybe in the FPGA-world there are better approaches or at least the design of the state machine differs.

How would you manage this problem?

Best regards

Geri

4 Replies

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

    If your state machine is too complex, I suggest you consider instantiating a 8 bit microcontroller core within the FPGA.

    There are free 8051, z80, PIC and AVR cores available. As an alternative, you can consider the Mico8 micro-controller core.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    a free Nios II/e + UART (in QII 9.1+) is going to be the path of least resistance. :)

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

    Oh bugger! I hadn't noticed NIOS II/e was free since 9.1. Great news.

    So scrap my previous suggestions and go with NIOS. :)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Hello

    Thank you for your approaches. Ok, the processor is a solution but how could in your opinion a structured implementation without processor look like:)?

    For my current understanding an approach maybe could like this (I come from the software :) area):

    Step 1: Read new command including parameters

    1.) Create fifo buffer for command input that saves data from RS232

    2.) Create a status machine for processing of input commands

    3.) Read new command in a data array called DataPackage[...]

    4.) Indicate that new data are ready for processing (inPackageReady)

    Step 2: Processing of commands

    For any command that will be implemented define a wire:

    wire ProcssCmd1 = inPackageReady & (DataPackage[1] == COMMAND1);

    wire ProcssCmd2 = inPackageReady & (DataPackage[1] == COMMAND2);

    wire ProcssCmd2 = inPackageReady & (DataPackage[1] == COMMAND3);

    Step 3: Create a program module for each command and handover parameters

    Step 4: Process selected command and create output data if the processing flag ProcessCMDxxx ist enabled

    Step 5: Save output data to output fifo

    Step 6. Main status machine checks if output data are available and sends it back

    What do you think about that? There are probably better solutions...

    Friendly regards

    Geri