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