myhdl-list

[myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

Is there a way to set an enum to have a specific value?

Looking at the code, it seems the enum value is set by the argument 
order, so I can't see how to do it trivially.

The use case is to interface with a library block that has the states 
already defined, and I don't really want to implement every enumeration 
for my usage.

I suppose the simple workaround is to wrap the library with the state 
logic and let the synthesis tools worry about any optimisations.

Cheers,

Henry

Re: [myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

On 28/12/14 11:24, Henry Gomersall wrote:
> Looking at the code, it seems the enum value is set by the argument
> order, so I can't see how to do it trivially.

It strikes me that the problem is that the class definition is inside 
the enum factory function. Is there a reason for this?

AFAICT it doesn't acquire any state from the enum function so it could 
just as easily be at the module level, allowing more flexible usage when 
needing to fit the enum to an existing definition.

Cheers,

Henry

Re: [myhdl-list] Setting of enum values

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

On 12/28/2014 11:44 AM, Henry Gomersall wrote:
> On 28/12/14 11:24, Henry Gomersall wrote:
>> Looking at the code, it seems the enum value is set by the argument
>> order, so I can't see how to do it trivially.
>
> It strikes me that the problem is that the class definition is inside
> the enum factory function. Is there a reason for this?

I don't know about the original design decision.

>
> AFAICT it doesn't acquire any state from the enum function so it could
> just as easily be at the module level, allowing more flexible usage when
> needing to fit the enum to an existing definition.

I am sure there are many ways to implement it, this may
not have been a use case envision or desired.  We can
propose a modification to have the "Enum" class public
and then various custom functions can be created to
implement the codedicts, etc.  I think this would provide
flexibility but also maintain a minimal / logical enum.

Note, I am thinking out loud here.  I don't know if there
was a design decision to limit the use - I can't think
of one ...

Regards,
Chris

Re: [myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

On 29/12/14 18:26, Christopher Felton wrote:
>> >AFAICT it doesn't acquire any state from the enum function so it could
>> >just as easily be at the module level, allowing more flexible usage when
>> >needing to fit the enum to an existing definition.
> I am sure there are many ways to implement it, this may
> not have been a use case envision or desired.  We can
> propose a modification to have the "Enum" class public
> and then various custom functions can be created to
> implement the codedicts, etc.  I think this would provide
> flexibility but also maintain a minimal / logical enum.

I'm keen on this. I don't see any reason why Enum should be so hard to 
access. I agree enum should be kept as is.

Cheers,

Henry

Re: [myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

On 06/01/15 20:50, Henry Gomersall wrote:
> On 29/12/14 18:26, Christopher Felton wrote:
>>>> >> >AFAICT it doesn't acquire any state from the enum function so it could
>>>> >> >just as easily be at the module level, allowing more flexible usage when
>>>> >> >needing to fit the enum to an existing definition.
>> >I am sure there are many ways to implement it, this may
>> >not have been a use case envision or desired.  We can
>> >propose a modification to have the "Enum" class public
>> >and then various custom functions can be created to
>> >implement the codedicts, etc.  I think this would provide
>> >flexibility but also maintain a minimal / logical enum.
> I'm keen on this. I don't see any reason why Enum should be so hard to
> access. I agree enum should be kept as is.
Further to this, why not just extend the existing python Enum:

https://pypi.python.org/pypi/enum34

Cheers,

Henry

Re: [myhdl-list] Setting of enum values

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

On 1/7/2015 6:23 AM, Henry Gomersall wrote:
> On 06/01/15 20:50, Henry Gomersall wrote:
>> On 29/12/14 18:26, Christopher Felton wrote:
>>>>>>>> AFAICT it doesn't acquire any state from the enum function so it could
>>>>>>>> just as easily be at the module level, allowing more flexible usage when
>>>>>>>> needing to fit the enum to an existing definition.
>>>> I am sure there are many ways to implement it, this may
>>>> not have been a use case envision or desired.  We can
>>>> propose a modification to have the "Enum" class public
>>>> and then various custom functions can be created to
>>>> implement the codedicts, etc.  I think this would provide
>>>> flexibility but also maintain a minimal / logical enum.
>> I'm keen on this. I don't see any reason why Enum should be so hard to
>> access. I agree enum should be kept as is.
> Further to this, why not just extend the existing python Enum:
>
> https://pypi.python.org/pypi/enum34
>
> Cheers,
>
> Henry
>

I think this is a reasonable request, I think the next
steps would be to create a feature request in the main
bitbucket repository [1].

For the near term, create a fork and move the Enum
object(s) outside of the function, add Enum to
__init__ (so it can be imported), and see how it
works ...

Regards,
Chris

[1] https://bitbucket.org/jandecaluwe/myhdl/issues?status=new&status=open

Re: [myhdl-list] Setting of enum values

[Jan D. <ja...@ja...>]

On 01/07/2015 01:23 PM, Henry Gomersall wrote:

> Further to this, why not just extend the existing python Enum:

MyHDL's enum was needed and implemented long before a
python Enum proposal emerged.

It may be useful to review the python Enum and reuse
if possible. I have not done that.

However - MyHDL's enum is intended to be modeled
after VHDL, not C or C++ which blur the distinction
between abstract enum types and integers.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

On 10/01/15 08:53, Jan Decaluwe wrote:
> On 01/07/2015 01:23 PM, Henry Gomersall wrote:
>
>> >Further to this, why not just extend the existing python Enum:
> MyHDL's enum was needed and implemented long before a
> python Enum proposal emerged.
>
> It may be useful to review the python Enum and reuse
> if possible. I have not done that.
>
> However - MyHDL's enum is intended to be modeled
> after VHDL, not C or C++ which blur the distinction
> between abstract enum types and integers.

There is an argument to be made (which I'm trying to make :) ) that 
enums should be handled and enforced at the MyHDL level, and converted 
to whatever types make sense at the HDL level. Requiring that MyHDL 
enums map to VHDL enums rather limits their scope (isn't the point of 
MyHDL to surpass the existing languages?).

The python enum has two parts:
i) The genuine symbolic enum class Enum, which distinctly removes the 
blurring between ints and enums, and is analogous to the VHDL enum 
(though it does allow explicit numbering of the symbols).
ii) The IntEnum class which makes the relationship with ints quite explicit.

I think there is room and use cases for both types in MyHDL:
* Interfacing with libraries that have certain enumerations defined 
would naturally fit with an IntEnum (even if it's only at the level of a 
sane, well-constrained namespace). This would map to an intbv at conversion.
* Defining new e.g. states would do well to use a proper Enum. This 
could map to VHDL enum if the numbering made sense (or was ignored).

Some of the benefit of IntEnum can _almost_ be had in 0.9 - with values 
mapping to constants, the only problem there being the conversion issue 
of integer attributes on an object being transcribed with the dot 
notation included - the same issue that is discussed in MEP 107 for 
interfaces. The other issue is that it is up to the user to specify the 
bit vector length for the values.

There is clearly a nod to different encoding schemes in the enum class 
as it stands (with the encoding kw arg).

Cheers,

Henry

Re: [myhdl-list] Setting of enum values

[Jan D. <ja...@ja...>]

On 01/10/2015 11:41 AM, Henry Gomersall wrote:

>
> There is an argument to be made (which I'm trying to make :) ) that
> enums should be handled and enforced at the MyHDL level, and converted
> to whatever types make sense at the HDL level. Requiring that MyHDL
> enums map to VHDL enums rather limits their scope.

That is not the requirement.

The enum was modeled after the VHDL enums because
I consider that a better model than alternatives in
other languages that I know of.

The fact that they map naturally to VHDL enums is simply
a consequence of that modeling decision.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Setting of enum values

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

On 1/10/2015 5:44 AM, Jan Decaluwe wrote:
> On 01/10/2015 11:41 AM, Henry Gomersall wrote:
>
>>
>> There is an argument to be made (which I'm trying to make :) ) that
>> enums should be handled and enforced at the MyHDL level, and converted
>> to whatever types make sense at the HDL level. Requiring that MyHDL
>> enums map to VHDL enums rather limits their scope.
>
> That is not the requirement.
>
> The enum was modeled after the VHDL enums because
> I consider that a better model than alternatives in
> other languages that I know of.
>
> The fact that they map naturally to VHDL enums is simply
> a consequence of that modeling decision.
>

I understand Jan's point with keeping the enum but
I would like to explore the options to solve the
original issue - third party interfacing.

I imagine, you would be stuck with an explicit
variable definition, e.g.

     # third-party state definitions
     S_S1,S_S2,S_S3 = range(3)

Considering, third-party interfaces (might) be limited
this is a reasonable approach(?).

Regards,
Chris

Re: [myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

On 16/01/15 03:07, Christopher Felton wrote:
> On 1/10/2015 5:44 AM, Jan Decaluwe wrote:
>> >On 01/10/2015 11:41 AM, Henry Gomersall wrote:
>> >
>>> >>
>>> >>There is an argument to be made (which I'm trying to make:)  ) that
>>> >>enums should be handled and enforced at the MyHDL level, and converted
>>> >>to whatever types make sense at the HDL level. Requiring that MyHDL
>>> >>enums map to VHDL enums rather limits their scope.
>> >
>> >That is not the requirement.
>> >
>> >The enum was modeled after the VHDL enums because
>> >I consider that a better model than alternatives in
>> >other languages that I know of.
>> >
>> >The fact that they map naturally to VHDL enums is simply
>> >a consequence of that modeling decision.
>> >
> I understand Jan's point with keeping the enum but
> I would like to explore the options to solve the
> original issue - third party interfacing.
>
> I imagine, you would be stuck with an explicit
> variable definition, e.g.
>
>       # third-party state definitions
>       S_S1,S_S2,S_S3 = range(3)
>
> Considering, third-party interfaces (might) be limited
> this is a reasonable approach(?).

I think this can be done with a explicit support of something akin to 
the IntEnum class. This makes a clean separation between the existing 
enum and areas where the enum/Int boundary is blurry.

Henry

Re: [myhdl-list] Setting of enum values

[Jan D. <ja...@ja...>]

On 12/28/2014 06:44 PM, Henry Gomersall wrote:
> On 28/12/14 11:24, Henry Gomersall wrote:
>> Looking at the code, it seems the enum value is set by the argument
>> order, so I can't see how to do it trivially.
>
> It strikes me that the problem is that the class definition is inside
> the enum factory function. Is there a reason for this?

Sure - the enum factory function is intended to create
a brand new type, like in VHDL.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

On 10/01/15 08:50, Jan Decaluwe wrote:
> On 12/28/2014 06:44 PM, Henry Gomersall wrote:
>> >On 28/12/14 11:24, Henry Gomersall wrote:
>>> >>Looking at the code, it seems the enum value is set by the argument
>>> >>order, so I can't see how to do it trivially.
>> >
>> >It strikes me that the problem is that the class definition is inside
>> >the enum factory function. Is there a reason for this?
> Sure - the enum factory function is intended to create
> a brand new type, like in VHDL.

Right, that makes sense in light of the view that enum should more than 
just a symbolic representation of an int down to the HDL level.

This is handled rather differently in the standard enum that allows 
quite a bit more flexibility in the design - the uniqueness of the items 
is enforced through the Enum metaclass.

Cheers,
Henry

Re: [myhdl-list] Setting of enum values

[Jan D. <ja...@ja...>]

On 01/10/2015 10:55 AM, Henry Gomersall wrote:
> On 10/01/15 08:50, Jan Decaluwe wrote:
>> On 12/28/2014 06:44 PM, Henry Gomersall wrote:
>>>> On 28/12/14 11:24, Henry Gomersall wrote:
>>>>>> Looking at the code, it seems the enum value is set by the argument
>>>>>> order, so I can't see how to do it trivially.
>>>>
>>>> It strikes me that the problem is that the class definition is inside
>>>> the enum factory function. Is there a reason for this?
>> Sure - the enum factory function is intended to create
>> a brand new type, like in VHDL.
>
> Right, that makes sense in light of the view that enum should more than
> just a symbolic representation of an int down to the HDL level.
>
> This is handled rather differently in the standard enum that allows
> quite a bit more flexibility in the design - the uniqueness of the items
> is enforced through the Enum metaclass.

In MyHDL uniquness is enforced by the factory function.

I have briefly looked at the Python enum, and I don't like it.
It seems incredibably complicated with metaclasses and
full of magic.

Confusing also. To construct an enum, you have to assign
integers to names. Those integers don't really have a meaning,
but you can still use them to access items. Ugly.
The class is "strongly recommended", but then they still provide
an IntEnum that further blurs the distinction betweens integers
and enum items.

The whole blurring of integers with enum items comes from
languages that unlike VHDL don't have a good enum model.

The whole point of a enum is to have an abstract type
where nothing matters but the item name. The MyHDL enum makes
that very clear - no integers in sight.

Therefore, I'll stick to MyHDL's enum, clean and to the point.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

On 11/01/15 08:33, Jan Decaluwe wrote:
> The whole blurring of integers with enum items comes from
> languages that unlike VHDL don't have a good enum model.
>
> The whole point of a enum is to have an abstract type
> where nothing matters but the item name. The MyHDL enum makes
> that very clear - no integers in sight.

You make a reasonable case that the normal Enum is fine as-is except for 
the fact that it doesn't really work with external libraries (not least 
because the Verilog support for enums is missing).

Given that, I still think that there is a use case for something like 
the IntEnum - if only as a namespace encapsulation device. One usage of 
enums is to remove the reliance on magic numbers. Of course it's 
possible to have your own naming convention, but it quickly gets mucky 
with lots of FOO_X, FOO_Y, BAR_X, BAR_Y floating around.

If it was a supported concept, then useful things like bit length could 
be inferred.

At a very minimum, it would be useful to have namespace mangling that 
allows integer class attributes to be supported, as suggested in another 
post. This would a provide a similar feature for other types as 
interfaces do for Signals.

To be clear, I think MyHDL is fantastic - the neat mapping of HDL 
concepts into standard python constructs is rather beautiful. I thank 
and congratulate your for it.

Henry

Re: [myhdl-list] Setting of enum values

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

On 12/28/14, 5:24 AM, Henry Gomersall wrote:
> Is there a way to set an enum to have a specific value?

No, but you can set the "encoding" type.

     States = enum("IDLE", ..., encoding='binary')

http://docs.myhdl.org/en/latest/manual/reference.html#myhdl.enum

Regards,
Chris

Re: [myhdl-list] Setting of enum values

[Jan D. <ja...@ja...>]

On 12/28/2014 12:24 PM, Henry Gomersall wrote:
> Is there a way to set an enum to have a specific value?

The enumeration values of an abstract enum type are set
at construction time.

If you mean an integer value - that is not the purpose
of enums. Use a symbolic constant.


>
> Looking at the code, it seems the enum value is set by the argument
> order, so I can't see how to do it trivially.
>
> The use case is to interface with a library block that has the states
> already defined, and I don't really want to implement every enumeration
> for my usage.
>
> I suppose the simple workaround is to wrap the library with the state
> logic and let the synthesis tools worry about any optimisations.
>
> Cheers,
>
> Henry
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Setting of enum values

[Marcel H. <1he...@in...>]

Hello everyone,

As far as I can see, there is no action on this topic anymore. I'm
currently encounter a Problem with exactly this.
My Problem is, that I have some (cpu-)modes, which I'd like to have in
an extra file, because I use them from some points in my code. So I
create a file cpumode.py with the following content:

cpumode.py:
> class CpuMode(object):
>     User = 0b10000
>     FIQ = 0b10001
>     IRQ = 0b10010
>     Supervisor = 0b10011
>     Abort = 0b101111
>     Undefined = 0b11011
>     System = 0b111111

In the next file, I import it via

> from cpumode import CpuMode


Now, myhdl tells me:

> myhdl.ConversionError: in file xxx.py, line 63:
>     Unsupported attribute: User

line 63:
> if mode == CpuMode.User:

This is garbage... :/ If I declare User outside of the class, but
directly in the cpumode.py, the same error occurs. Only iff I delcare
User, FIQ, IRQ, ... in the same file (in this case xxx.py) it will work.

Is there any way out or thoughts about implementing a enum with given
values? (In the thread, there was a tought about exporting the Enum
class and create it via that :/

Greetings,
Marcel

Re: [myhdl-list] Setting of enum values

[Jan C. <jen...@mu...>]

On Wed, 20 Jan 2016 23:11:46 +0100
Marcel Hellwig <1he...@in...> wrote:

> As far as I can see, there is no action on this topic anymore.

Agreed, it is a complex one, and I accept the reasons for not
pursuing this. Where I want to have close control of bits I
import values.  These are created using simple assignments, 
which are sometimes shortened using range(x,y,z)

> I'm currently encounter a Problem with exactly this.
> My Problem is, that I have some (cpu-)modes, which I'd like to
> have in an extra file, because I use them from some points in
> my code. So I create a file cpumode.py with the following
> content:
> 
> cpumode.py:
> > class CpuMode(object):
> >     User = 0b10000
> >     FIQ = 0b10001
> >     IRQ = 0b10010
> >     Supervisor = 0b10011
> >     Abort = 0b101111
> >     Undefined = 0b11011
> >     System = 0b111111
> 
> In the next file, I import it via
> 
> > from cpumode import CpuMode
> 
> 
> Now, myhdl tells me:
> 
> > myhdl.ConversionError: in file xxx.py, line 63:
> >     Unsupported attribute: User
> 
> line 63:
> > if mode == CpuMode.User:

I had this type of problem with VHDL, something like 'data not
locally static' but have not seen it with MyHDL.  Perhaps this
is because simple named constant values are just converted
into numbers in the Verilog or VHDL files.  

In one large processor design most of the ~24 source files
import basic configuration parameters, like buss width, and
perhaps a third import opcode constants. There seems to be no
problem using this method. 

Hope this helps, else, for sample code email me directly.

Regards, Jan Coombs.

Re: [myhdl-list] Setting of enum values

[Thomas H. <th...@ct...>]

Am 20.01.2016 um 23:11 schrieb Marcel Hellwig:
> Hello everyone,
>
> As far as I can see, there is no action on this topic anymore. I'm
> currently encounter a Problem with exactly this.
> My Problem is, that I have some (cpu-)modes, which I'd like to have in
> an extra file, because I use them from some points in my code. So I
> create a file cpumode.py with the following content:
>
> cpumode.py:
>> class CpuMode(object):
>>      User = 0b10000
>>      FIQ = 0b10001
>>      IRQ = 0b10010
>>      Supervisor = 0b10011
>>      Abort = 0b101111
>>      Undefined = 0b11011
>>      System = 0b111111
>
> In the next file, I import it via
>
>> from cpumode import CpuMode
>
>
> Now, myhdl tells me:
>
>> myhdl.ConversionError: in file xxx.py, line 63:
>>      Unsupported attribute: User
>
> line 63:
>> if mode == CpuMode.User:

I had the same problem and currently only see these two possibilities:

1. Import each constant and assign it in the myhdl code, like this:

from cpumode import CpuMode
cpumode_User = CpuMode.User
...

2. Define the constants as module level constants
and use 'from mymodule import *' in the myhdl code.


Thomas

Re: [myhdl-list] Setting of enum values

[Marcel H. <1he...@in...>]

On 21.01.2016 09:47, Thomas Heller wrote:
> [...]
> I had the same problem and currently only see these two possibilities:
> 
> 1. Import each constant and assign it in the myhdl code, like this:
> 
> from cpumode import CpuMode
> cpumode_User = CpuMode.User
> ...

ugly as hell :D but yeah, it kind of works...

> 
> 2. Define the constants as module level constants
> and use 'from mymodule import *' in the myhdl code.

I decided myself to this design. Would be nice though to have some kind
of namespace seperation.


On 21.01.2016 01:33, Jan Coombs wrote:
> Agreed, it is a complex one, and I accept the reasons for not
> pursuing this



I have an Idea and would like to know your thoughts about this:

> from myhdl import enum
> 
> procmode = enum(('User', 0b10001, ('System', 0b11111), (...), ...)


so giving them tuples (or a dict) with predefined values? This means
that you can pass constant values and names to it. You can check the
nrbits and everything else while creating the enum. I find this is an
quite elegant solution. What do you thinK?


Greetings,
Marcel

Re: [myhdl-list] Setting of enum values

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

On 1/21/2016 5:15 AM, Marcel Hellwig wrote:
> On 21.01.2016 09:47, Thomas Heller wrote:
>> [...]
>> I had the same problem and currently only see these two possibilities:
>>
>> 1. Import each constant and assign it in the myhdl code, like this:
>>
>> from cpumode import CpuMode
>> cpumode_User = CpuMode.User
>> ...
>
> ugly as hell :D but yeah, it kind of works...
>
>>
>> 2. Define the constants as module level constants
>> and use 'from mymodule import *' in the myhdl code.
>
> I decided myself to this design. Would be nice though to have some kind
> of namespace seperation.
>

Disclaimer: I quickly review the previous posts in this
thread (I might not understand the intent) - if this is
off base ignore.

You should be able to use constant values in an object,
this code snip might help:


     from myhdl import *

     class MyConstants(object):
         def __init__(self):
             self.const1 = int(intbv("1111_0001"))
             self.const2 = int(intbv("1010_0101"))

     def const_select(sel, x):
         const = MyConstants()

         @always_comb
         def beh_select():
             if sel == 1:
                 x.next = const.const1
             elif sel == 2:
                 x.next = const.const2
             else:
                 x.next = 0

         return beh_select


The above converts as expected.  You could also
convert the object to a tuple of ints, something
like (for this example):

     rom = [int(v) for k, v in vars(const)]

Regards,
Chris

Re: [myhdl-list] Setting of enum values

[Henry G. <he...@ca...>]

On 21/01/16 16:34, Christopher Felton wrote:
> On 1/21/2016 5:15 AM, Marcel Hellwig wrote:
>> > On 21.01.2016 09:47, Thomas Heller wrote:
>>> >> [...]
>>> >> I had the same problem and currently only see these two possibilities:
>>> >>
>>> >> 1. Import each constant and assign it in the myhdl code, like this:
>>> >>
>>> >> from cpumode import CpuMode
>>> >> cpumode_User = CpuMode.User
>>> >> ...
>> >
>> > ugly as hell :D but yeah, it kind of works...
>> >
>>> >>
>>> >> 2. Define the constants as module level constants
>>> >> and use 'from mymodule import *' in the myhdl code.
>> >
>> > I decided myself to this design. Would be nice though to have some kind
>> > of namespace seperation.
>> >
> Disclaimer: I quickly review the previous posts in this
> thread (I might not understand the intent) - if this is
> off base ignore.
> 
> You should be able to use constant values in an object,
> this code snip might help:

Is this a relatively recent fix?

Cheers,

Henry

Re: [myhdl-list] Setting of enum values

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

On 1/21/2016 10:38 AM, Henry Gomersall wrote:
> On 21/01/16 16:34, Christopher Felton wrote:
>> On 1/21/2016 5:15 AM, Marcel Hellwig wrote:
>>>> On 21.01.2016 09:47, Thomas Heller wrote:
>>>>>> [...]
>>>>>> I had the same problem and currently only see these two possibilities:
>>>>>>
>>>>>> 1. Import each constant and assign it in the myhdl code, like this:
>>>>>>
>>>>>> from cpumode import CpuMode
>>>>>> cpumode_User = CpuMode.User
>>>>>> ...
>>>>
>>>> ugly as hell :D but yeah, it kind of works...
>>>>
>>>>>>
>>>>>> 2. Define the constants as module level constants
>>>>>> and use 'from mymodule import *' in the myhdl code.
>>>>
>>>> I decided myself to this design. Would be nice though to have some kind
>>>> of namespace seperation.
>>>>
>> Disclaimer: I quickly review the previous posts in this
>> thread (I might not understand the intent) - if this is
>> off base ignore.
>>
>> You should be able to use constant values in an object,
>> this code snip might help:
>
> Is this a relatively recent fix?
>

Not sure and it depends on your definition
of recent.

Yes, there was a fix for constants in an object
at some point I don't recall the time frame.

Regards,
Chris

Re: [myhdl-list] Setting of enum values

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

>>> You should be able to use constant values in an object,
>>> this code snip might help:
>>
>> Is this a relatively recent fix?
>>
>
> Not sure and it depends on your definition
> of recent.
>
> Yes, there was a fix for constants in an object
> at some point I don't recall the time frame.
>

Looks like it was fixed for VHDL (always worked
for Verilog) here:
https://github.com/jandecaluwe/myhdl/pull/64

Regards,
Chris