Re: [myhdl-list] Restrictions for conversion

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

On 5/5/12 10:20 AM, Norbo wrote:
> Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
<snip>
>>>>>>
>>>>>> I don't know if the _doinit flag is actually needed? I believe the
>>>>>> conversion code can determine if the value should be written or not
>>>>>> without modifying the Signal or intbv objects. As your modified intbv
>>>>>> does, it can always create the initial value unless the Signal/intbv
>>>>>> init value is None.
>>>>> Yes this would be possible if the value (._val) of the intbv is set to
>>>>> None.
>>>>> But there are several things that raise, exceptions if the value is
>>>>> set
>>>>> to
>>>>> None. (Boundcheck, __getitem__, etc..)
>>>>> so i added the _doinit flag and set the (._val) to 0 (or to the min
>>>>> value
>>>>> if defined), and thereby avoided the error-prone changing of these
>>>>> functions which wouldnt work with the None value.
>>>>
>>>> Why do you need "None"?  It would be my understanding that the
>>>> conversion process will always create the init values in the converted
>>>> code.  You don't need the _doinit flag and you don't need None.
>>>
>>> My thought on this was that it may be usefull to have explicit controll
>>> on
>>> whether the initial values are written ot not. For example if a big ram
>>> is
>>> described
>>> and you don't need the initial values, the converted file would be
>>> filled
>>> up with a
>>> huge number of basically useless values. ->   Or in the words of "import
>>> this" in python:
>>> Explicit is better than implicit
>>>
>>
>> To me this is *not* explicit, you don't have direct control over _doinit
>> you have implicit control if the initial values are generated or not
>> (which I have even forgotten what the control is).
> The idea of the controll was if you write:
>       aList=[Signal(intbv(None)) for i in range(10) ]  -->  then the initial
> values are not written no matter what.
>       aList=[Signal(intbv(i)) for i in range(10) ]  -->  the initial values
> are written in verilog and vhdl when there is
> 							no combinatorical assignment ("as a path of least resistance right
> now")
>
>

I think we are both in agreement, now, that the None can be used for the 
explicit control (which means more changes in the implementation).  But 
I don't think I agree that there are cases when the values should *not* 
be written.  I think they should always be written (when not None).  I 
think we can work through the implementation changes.

If None is used, that should mean the _doinit is not required.

>
>
>> I hear the argument for the large inclusive of init values.  And with
>> FPGA embedded memories and ASIC available ROM/RAM growing these could be
>> long init lists.  But I am not totally convinced the inconvenience of
>> long inits are bad because it breaks the earlier argument "MyHDL to
>> Verilog/VHDL mismatch".
>
> I didn't get that.

It has been brought up in the past that if MyHDL simulation has initial 
values and the Verilog/VHDL does not have initial values.  Then you have 
a simulation mismatch at time 0 through time N (most cases, until the 
reset occurs).

I think we have a good design plan to cover the initial values that 
includes the pre-init RAMS (nice addition).  We should probably 
summarize in a separate post (new thread, not buried).  I boils down to 
adding support for None and then creating  initial values in 
Verilog/VHDL if the intbv initial value is not None.

Regards,
Chris