myhdl-list

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

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

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 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():
     ''' determine what next execution state will be '''
     ''' line 159: Object type is not supported in this context: 
ExST '''
     if reset:   execNextState.next = ExST.Skip
     else:
       if (execState==ExST.Fetch1):
         if (memRdSlice==ToMem)|    \
            (memRdSlice==Alu2op)|   \
            (memRdSlice==Alu1op)|   \
            (memRdSlice==FromMem):  \
                 execNextState.next = ExST.Fetch2
         elif (memRdSlice==Branch):   \
                 execNextState.next = ExST.NewAddr
         elif (memRdSlice==Skip)|  \
              (memRdSlice==Lit)|   \
              (memRdSlice==Call):  \
                 execNextState.next = ExST.Skip
         else:   execNextState.next = ExST.Gap
       elif execState==ExST.Fetch2:  \
                 execNextState.next = ExST.Gap
       elif execState==ExST.NewAddr:
         if (memRdMore==0):  \
                 execNextState.next = ExST.Gap
         else:   execNextState.next = ExST.NewAddr
       elif execState==ExST.Skip:
         if (memRdMore==0):  \
                 execNextState.next = ExST.Gap
       elif execState==ExST.Gap:  \
                 execNextState.next = ExST.Fetch1
       elif execState==ExST.Broken:  \
                 execNextState.next = ExST.Broken
       else:     execNextState.next = ExST.Broken


Now I have converted the code using enum to use constants, and 
don't get the improper use of ExST error.  The simulation still 
looks ok, but I now get this:

jan@T60:~/work/projects/MyHDL/SDP_3o4/work$ ./testSdp3o4.py
<class 'myhdl._SuspendSimulation'>: Simulated 350 timesteps
Traceback (most recent call last):
   File "./testSdp3o4.py", line 46, in <module>
     toVerilog(sdp3o4, clk,reset, addr, doSim)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 151, in __call__
     _convertGens(genlist, vfile)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 374, in _convertGens
     v.visit(tree)
   File "/usr/lib/python2.7/ast.py", line 241, in visit
     return visitor(node)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 964, in visit_Module
     self.visit(stmt)
   File "/usr/lib/python2.7/ast.py", line 241, in visit
     return visitor(node)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 1285, in visit_FunctionDef
     self.visit_stmt(node.body)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 1141, in visit_stmt
     self.visit(stmt)
   File "/usr/lib/python2.7/ast.py", line 241, in visit
     return visitor(node)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 667, in visit_Assign
     self.visit(node.value)
   File "/usr/lib/python2.7/ast.py", line 241, in visit
     return visitor(node)
   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?

Jan Coombs
-- 

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

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

On 12/05/12 14:03, Jan Coombs wrote:
> This error message points to a blank line, which is always
> immediately before the start of a code block:

The complex error messages were caused by confusion about intbv 
indexing, using:
     memRdNetSlice.next = memRdSlice(NSW,0)
instead of:
     memRdNetSlice.next = memRdSlice[NSW:0]


As the code now converts to Verilog, although not VHDL, I tried to 
restore the enum code, just in case, but this still fails, likely 
in the block shown below:

> 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():
>       ''' determine what next execution state will be '''
>       ''' line 159: Object type is not supported in this context:
> ExST '''
>       if reset:   execNextState.next = ExST.Skip
>       else:
>         if (execState==ExST.Fetch1):
>           if (memRdSlice==ToMem)|    \
>              (memRdSlice==Alu2op)|   \
>              (memRdSlice==Alu1op)|   \
>              (memRdSlice==FromMem):  \
>                   execNextState.next = ExST.Fetch2
>           elif (memRdSlice==Branch):   \
>                   execNextState.next = ExST.NewAddr
>           elif (memRdSlice==Skip)|  \
>                (memRdSlice==Lit)|   \
>                (memRdSlice==Call):  \
>                   execNextState.next = ExST.Skip
>           else:   execNextState.next = ExST.Gap
>         elif execState==ExST.Fetch2:  \
>                   execNextState.next = ExST.Gap
>         elif execState==ExST.NewAddr:
>           if (memRdMore==0):  \
>                   execNextState.next = ExST.Gap
>           else:   execNextState.next = ExST.NewAddr
>         elif execState==ExST.Skip:
>           if (memRdMore==0):  \
>                   execNextState.next = ExST.Gap
>         elif execState==ExST.Gap:  \
>                   execNextState.next = ExST.Fetch1
>         elif execState==ExST.Broken:  \
>                   execNextState.next = ExST.Broken
>         else:     execNextState.next = ExST.Broken
>
>
> Now I have converted the code using enum to use constants, and
> don't get the improper use of ExST error.

Now I can get on, wrap my code in a test harness, and try it with 
the on-chip RAM block.

Jan Coombs.

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

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

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

On 14/05/12 12:28, Christopher Felton wrote:
> 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.

Yes, the error line was always the one before a new code block 
started, i.e. when the parser/ast knew it had to complete clean-up 
of the previous block.

> 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?

Agreed, the error changed/disappeared when I temporarily tested 
with a clocked process.

>    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.

Thanks for checking.  I'm so good at writing dodgy code that it 
could easily have been just me.  Hopefully this will get better, 
and I will also be able to provide some insight into what is happening.

> 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.

Yes, this is true for the sample code, but in the processor design 
I need the next state decode to drive some register transfers. I'll 
continue to use plain constants to describe the states, but it is 
much easier to trace in gtkwave with the states named.

>> I did start looking at the MyHDL source,  ...

To debug conversion, I turned off simulation, then selectively 
edited the top level return line to find the non-convertible code. 
  After that, selectively editing the block(s) that failed to 
convert isolated the problem.  This may be obvious to others, but 
it took me a while to figure out the method.

> 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.

With the processor, the three pages of code seemed to me to be 
about the minimum convenient size for initial testing.  There is 
another monolithic block to add soon, so I'll try to find ways of 
testing this thoroughly before next big integration.

Jan Coombs
--