Re: [myhdl-list] Object type is not supported in this context

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

On 5/12/2012 8:03 AM, Jan Coombs wrote:
> This error message points to a blank line, which is always
> immediately before the start of a code block:
>
> myhdl.ConversionError: File
> /home/jan/work/projects/MyHDL/SDP_3o4/work/sdp3o4.py, line 123:
> Object type is not supported in this context: ExST
>
> Does it refer to the next or previous block of code?

I do not know for certain but my guess is the previous block as well. 
But it is hard to line up the line number with the code pasted.  In 
general (AFAIK) the error messages and lines numbers depend heavily on 
the Python ast package.  The conversion code doesn't try and re-parse 
but uses the information provided by the ast package.

>
> I assumed that it would be the previous block of code, and
> commented out all lines referring to the state constants, but the
> error remains the same, even the line number.
>
> ExST = enum('Fetch1','Fetch2','NewAddr','Skip',  \
>                          'Gap','Broken', encoding='one_hot')
>
>
> The next block of code would be difficult without the enum, but
> this seems to be where the problem is:
>
>     @always_comb
>     def execNextStateLogic_AsyncNoVar():

I think your issue with using the enum() is in combination with the 
always_comb decorator.  The enums don't seem to work in an always_comb? 
  I didn't realize this limitation existed.  The following is the simple 
example I used (one of your previous questions) to see if this was true 
or not.

     from myhdl import *

     def case_ex1(clk, key, led):
         tKey = enum('UP', 'DOWN', 'LEFT', 'RIGHT')
         @always(clk.posedge)
         def hdl():
             if   key==tKey.UP:    led.next = 0xDE
             elif key==tKey.DOWN:  led.next = 0xCA
             elif key==tKey.LEFT:  led.next = 0xFB
             elif key==tKey.RIGHT: led.next = 0xAD
             else:                 led.next = 0x00

         return hdl

     def case_ex2(key, led):
         tKey = enum('UP', 'DOWN', 'LEFT', 'RIGHT')
         @always_comb
         def hdl():
             if   key==tKey.UP:    led.next = 0xDE
             elif key==tKey.DOWN:  led.next = 0xCA
             elif key==tKey.LEFT:  led.next = 0xFB
             elif key==tKey.RIGHT: led.next = 0xAD
             else:                 led.next = 0x00

         return hdl

In the above, the second does not convert correctly and fails the 
freevar check in the _analyzeGens, determines the enum is an unsupported 
type.

In your example you do not need to write you state-machines with the 
separate "next state" and "state" blocks.  If you convert your 
state-machines to a single always(clock.posedge) you should be able to 
avoid the issue you are seeing with the enums.

<snip>
>     File
> "/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py",
> line 743, in visit_Call
>       self.write(f.__name__)
>     File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_Signal.py",
> line 479, in __getattr__
>       return getattr(self._val, attr)
> AttributeError: 'intbv' object has no attribute '__name__'
> jan@T60:~/work/projects/MyHDL/SDP_3o4/work$
>
>
> I did start looking at the MyHDL source, but suspect that this
> would be a very long route to a solution.  My code is only three
> pages, should I try to convert smaller pieces?  Or can anyone else
> suggest the type of problems/typos I should look for?

Sandbox examples are usually easier to work with.  If you think the 
error is XYZ then create a small generic example to try and expose the 
issue and then present to the group.  Large code examples can be hard to 
dissect quickly.

Regards,
Chris