Re: [myhdl-list] State machine modeling

[Christopher F. <chr...@gm...>]

On 11/9/2011 6:36 AM, Oscar Diaz wrote:
> Hi
>
> Recently I had some problems converting state machines to VHDL. In my
> models I use two generators: one with the state sequence and another
> with the output based on the states. For this second generator I use
> @always_comb, since its just combinatorial logic. Works perfect in
> simulation but fails on conversion. Then I did a workaround: put
> manually a sensitivity list with @always(list_of_signals) and then the
> conversion step worked fine.
>
> I wonder if it's a bug in conversion, or if there's a better way to
> model a state machine. I attach a small example to show my dilemma.
>
> Best regards
>
>


I believe the converter is limited at this point.  The converter 
verifies that only basic types are used in the always_comb.  I do not 
know if this was intentional or not.  This is kinda similar to "Signals" 
that are part of a class.  Complex types are not really supported.  You 
would have the same problem if you did something like this:

~~~ [Code Snip] ~~~
def mycode(x, y):

    class Structure():
       def __init__(self):
          self.SomeNumber = 2
          self.SomeOtherNumber = 3

    A = Structure()

    @always_comb
    def outputs():
       if x == A.SomeNumber:
          y.next = 99
       elif x == A.SomeOtherNumber:
          y.next = 34
       else:
          y.next = 0

    return outputs

~~~ [End Code Snip] ~~~

In the above code example, the class is being used as a fancy container 
for some information.  And the information is just an int.  But the 
converter will analyze A.<class member> as an instance of "Structure" 
and not one of the primitives int, long, Signal ...

I think this is simply a limitation right now but it isn't a trivial 
modification (at least I don't think so).  There has to be some thought 
and conversation around how this is resolved.

This has come up in other contexts as well.  It is a reasonable 
enhancement to be added.  But it will take some time to spec out the 
modification and make the changes.  Right now I would consider it a 
limitation and an item that might be addressed in the future.

If your current work around works, I would use that for the time being. 
  I don't see any issues with the @always(<Signal(enum)>).

Regards,
Chris