0
\$\begingroup\$

There are several ways to encode state machines. However, since a circuit is required to decode the next state and output, implementing a bigger state machine would possibly reduce fmax of a design anyway.

One way to deal with such an issue is to use a soft core to implement the state machine in software. However, having multiple softcore processors e.g Nios II may not be practical as well.

Now if it becomes clear that the design requires multiple state machines where each has maybe 10s of states, does this mean that the design must be simply implemented fully in software and not in hardware or techniques exist to implement multiple large state machines which also ensure that we get large fmax? How about one designing a very basic processor that can only do basic arithmetic logic operations and write a short program that goes into a hard memory block? This adds the complexity in that debugging the assembly type code will be another new issue to deal with.

\$\endgroup\$
9
  • 3
    \$\begingroup\$ No it doesn't. Large (but fairly well structured) SMs in VHDL are quite easy and certainly faster than a software implementation! stackoverflow.com/questions/29465674/… stackoverflow.com/questions/31138152/… stackoverflow.com/questions/19463359/… \$\endgroup\$ Feb 9 at 13:39
  • \$\begingroup\$ What you do in these states (especially in most time consuming ones) gives us higher chance to help you. Are there some arithmetic operations? How about time response, tell us the critical Fmax value? \$\endgroup\$ Feb 9 at 14:18
  • \$\begingroup\$ yes, arithmetic operations exist, addition subtraction and multiplication \$\endgroup\$ Feb 9 at 14:39
  • \$\begingroup\$ Try to optimize these operation according your compiler. Ensure the most time consuming states will be handled quicker (give them priority against low time consuming). \$\endgroup\$ Feb 9 at 14:50
  • \$\begingroup\$ Like put them into first places of switch(), etc. \$\endgroup\$ Feb 9 at 15:02
6
\$\begingroup\$

implementing a bigger state machine would possibly reduce fmax of a design anyway.

That would imply a state machine where the "next state" decision is overly complex. That's a criterion for "not well-designed"!

One way to deal with such an issue is to use a soft core to implement the state machine in software.

A processor is a state machine. Instructions and data alter its state.

It's just meant to be more general.

However, having multiple softcore processors e.g Nios II may not be practical as well.

I'm not advocating for this here, you should probably just optimize your regular FSMs, but having multiple processors in one design is far from unusual. Actually, especially for things that handle multiple interfaces, it's somewhat usual to have application-specific processors for each and let them talk via a common internal bus or shared memory.

(In fact, often a layered approach: hardware FSM to handle the physical layer, software FSM to handle logical things)

Now if it becomes clear that the design requires multiple state machines where each has maybe 10s of states,

You're certainly not calling "10s of states" a large state machine? You might want to read protocol standards (USB, Ethernet...)

does this mean that the design must be simply implemented fully in software and not in hardware or techniques exist to implement multiple large state machines which also ensure that we get large fmax?

Certainly not.

\$\endgroup\$
2
  • \$\begingroup\$ A processor might take more clock cycles but not reduce the fmax of the design due to its "general purpose" FSM nature. \$\endgroup\$ Feb 9 at 14:39
  • \$\begingroup\$ no. That happens due to its pipelined nature, which perfectly applies to other FSMs too. \$\endgroup\$ Feb 9 at 16:15
1
\$\begingroup\$

A task-specific FSM is most likely going to consume far less logic and be far faster than a NIOS core (unless that task is really complex - in which case the NIOS core will take a long time to evaluate). Another benefit is that the function timing will be much easier to predict. Everything will happen exactly when the FSM determines it will happen.

It is perfectly fine to implement multiple state machines in an FPGA.
If performance or space aren't issues, then using a NIOS core might be fun for learning. If you are doing floating point math or stuff like that, then NIOS certainly might be interesting just so that you don't have to reinvent the wheel on math. It won't be fast, but you can leverage man-centuries of development in c-libraries.

\$\endgroup\$
1
  • \$\begingroup\$ Quartus has IP blocks for floating point maths which is quite helpful! \$\endgroup\$ Feb 17 at 9:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.