Re: [myhdl-list] Problems converting an integer assignment into VHDL

[Angel E. <ang...@gm...>]

On Thu, Oct 11, 2012 at 4:52 PM, Christopher Felton
<chr...@gm...> wrote:
> <snip>
>>
>>
>> so it turns out that the converter doesn't recognise the "s_my_signal.max"
>> as an const integer, but instead as a signal.
>> This seems to be also the case for the simulator.
>> e.g:  In a combinatorical process this leads to a -> combinatorical loop
>> error, when there is actually none.
>>
>>
>>       sigTest=Signal(intbv(0)[4:])
>>       @always_comb
>>       def comb_setConst():
>>         sigTest.next=int(sigTest.max)-1
>>
>>
>
> Yes, in a generator an "buried" constant can't be used.
> The converter will not walk down the structure (list,
> dict, class, etc) to find the value.  On the right hand
> side the only valid types are for conversion:
>
>      int, long, intbv, bool

Does this include the result of calling a function that returns one of
these types?

> A Signal can also be on the right hand side as lot as
> the Signal contains one of the above types.
>
>
> Another method vs. converting to an int would be
>
>     Max = sigTest.max
>     @always_comb
>     def com_setConst():
>         sigTest.next = Max-1
>
>
> The error that occurred in simulation is slightly different.
> Because you could use the above in an @always decorator and
> in simulation it will work but it will not convert.  The
> in / out is to protect from infinite recursive delta cycles.
>
>     @always_comb
>     def hdl():
>          sigTest.next = not sigTest
>
> Regards,
> Chris

I understand that (currently?) MyHDL limits the usage of containers in
synthesizable code. However, in this case I was not trying to use a
custom container that I created myself. I was trying to use one of the
fields of one of the built-in MyHDL data types.

Technical issues aside, wouldn't it make sense for MyHDL to support
those? This was quite surprising to me...

Angel