myhdl-list

[myhdl-list] State machine modeling

[Oscar D. <osc...@gm...>]

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

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.spreadopendocument.org/

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

Re: [myhdl-list] State machine modeling

[Oscar D. <osc...@gm...>]

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

>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Best regards

--
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.spreadopendocument.org/

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