Re: [myhdl-list] List Of Constants

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

On 3/18/15 11:54 AM, Josy Boelen wrote:
>>>         x = [Signal(intbv(...) ...]
>>>         b = tuple(map(int, [round(1/N*xmax) for ...]))
>>>
>>>         def sop(N, x, b ):
>>>         <at> always_seq(clock.posedge, reset=reset)
>>>         def sop():
>>>             ssum = 0
>>>             for ii in range(N):
>>>    	      ssum = ssum + x[ii] * b[ii]
>>>             y.next = ssum
>>>         return sop
>>>
>>
>> No, even with the enhancement request the above would
>> not be converted because the index is not constant.
>> For that to be convertible the loop would need to be
>> unrolled.
>> <snip>
>
> Chris,
>
> did you trick me? :)

Not intentionally.

> I overlooked that fact. Aren't the two codes doing the same in the end?
> Or perhaps the second doesn't convert?
> In my code a loop would, almost always, be unrolled or rather be
> replaced by a, probably pipelined, tree-structure so the indexes would
> become constants.

They are doing the same thing in the end from a code
perspective but not from a hardware perspective.  The
only way to do the second is to unroll the loop with
literals or with initial value support.

You would need an array of signals in the converted
code with an initial (constant) value.  The initial
value support is too inconsistent across tools (best
of our knowledge).

The safe method, is to set the initial values your
self.

     def m_initial_values(coef, coef_init):
         assert isinstance(coef, list)
         assert isinstance(coef_init, tuple)
         N = len(coef)
         @always_comb
         def assign():
             for ii in range(N):
                 ival = coef_init[ii]
                 coef.next = ival
         return assign

Using a generic module like the above will let you
use the second version of code directly and then
you don't have to mess with the synthesis tools
inconsistent support of initial values.

Regards,
Chris