Re: [myhdl-list] Restrictions for conversion

[Norbo <Nor...@gm...>]

Am 10.05.2012, 04:06 Uhr, schrieb Christopher Felton  
<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.

yup i think that hits it.
So i would summarize it like this:
* Adding support for None in the intbv (also setting None as the default  
value?)
* Creating initial values in Verilog/VHDL (when not None)
* Changing the verilog continuous assignment to the behavioral statement  
in the verilog conversion
* Work through the implementation changes needed, because of the None in  
the intbv (boundchecks, etc ..)