Judge complex degree by state numbers?

Hi, I have met some situations that people evaluate a design's complex degree by asking "How many states does the state machine have". I think any designs based on state machine can be rewritten to counter style, which does not have any state. And in many times a combined mode is used, which means only using a few states and each state has a counter inside. By using state machine, syn_encoding value can be adjusted dynamically. For example, when we cannot get the desired speed, we can set syn_encoding to onehot. But when the speed is ok, is the counter style enough?

Thanks

Reply to
topweaver
Loading thread data ...

I suppose that would be one measure of complexity...not necessarily a very good one but a measure nonetheless.

While true, the obvious question would be "Why rewrite something?"

Obviously you don't have a clue about what constitutes a 'state'. A counter certainly does have a state...the value of the counter at a particular time.

Or in more general terms, state machines that fire off activity in other state machines (which may happen to be counters)...do it all the time when necessary.

When code performs the function that one wants at the performance level that one requires and does not violate any timing then it really doesn't matter what style was used to get one there.

What you should be aiming for after function and performance is supportability which is rather loosely the clearness of the source code for someone else (or yourself) to pick it up some point down the road and change it or improve it in some manner. Using state machines and counters properly where they are appropriate is one facet to that.

KJ

Reply to
KJ

Hi,

I think in many cases the direct idea is to use a counter. When there are not many branches, code in counter style may be more concise because we need not to explicitly describe the next state for each state.

You are right. But the synthesis tool does not regard a counter as a state machine, so conventionally we separate these two styles.

Thanks.

Reply to
topweaver

Still you're not answering 'Why rewrite something?' If the current code a. Does what it needs to do b. Runs at the clock speed you need c. Doesn't take up significantly more resources

then all you can hope to accomplish by rewriting is to expend effort to produce a functionally darn near similar hunk of code...maybe more concise but at this point that's probably a moot point unless points a.b.c are not the case.

Synthesis tools consider counters and state machines (and many other source code input forms) to be flip flops fed by combinatorial logic.

The only thing synthesis tools do 'differently' is when they encounter the user defined type definition and a signal of that type being used it knows that the particular binary encoding needed to physically synthesize the code is unimportant to the user so the synthesis tool is free to choose whatever encoding style it wants to implement the design. While user defined types are frequently used when creating state machines they can be used in other places as well in which case the synthesis tool will again be free to choose the binary encoding for signals of that type...even though they are not 'state machines'.

Kevin Jennings

Reply to
KJ

Hi, By "Style A can be rewritten to Style B", I just mean "A is something equal to B", I do not want to change the existing A to B. When starting coding, maybe style B is sometimes easier to be thought. Thanks.

Reply to
topweaver

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.