Re: [myhdl-list] State machine modeling

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

On 11/9/2011 9:29 AM, Oscar Diaz wrote:
> 2011/11/9 Christopher Felton<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.
>
> I had the same problems with classes that are signal containers in
> other designs; in fact I think we need to find an elegant way to use
> complex types for conversion, and that would be a big enhancement for
> myhdl. I find particularly annoying to keep two equivalent models just
> for conversion.
>
> Right now I use a generic class based on dict, when additional
> information can be added (Signal name on the key, description,
> complement signal on case of a bus interconnect, etc). Designs can use
> this class or subclass it for its own needs. There's nothing to be
> done on simulation, that works perfectly in my projects. Changes must
> be made in the conversion, I think that object can "unroll" to a
> signal list on the generated code.
>
>>
>> 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.
>
> I agree, Can this issue be a MEP or just reported as a bug?
>>
>> 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)>).
>
> Just what I feared :p
>

This is definitely a MEP, it is not advertised that the complex data 
structures are supported.  The MEP should cover, as you mention, 
classes, dicts, and heterogeneous list of signals (any others?).

A month (or more) ago I started to write a draft of a MEP on this topic 
and there have been some incomplete contributions.  I can post the 
(rough-de-rough) draft of the MEP here, we can refine some and then 
create a MEP on the wiki.  I didn't post it because I don't have much 
understanding of the back-end conversion (the Python.ast etc.) and time 
is a scarce commodity.

Regards,
Chris