Re: [myhdl-list] Signal initialization

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

On 12/3/12 10:30 AM, Angel Ezquerra wrote:
> On Mon, Dec 3, 2012 at 3:29 PM, Christopher Felton
> <chr...@gm...> wrote:
>> <snip>
>>>>
>>>> Based on my recollection it has been agreed upon that using initialized
>>>> signals/variables in the converted HDL (both VHDL and Verilog) is
>>>> desired to avoid MyHDL simulation mismatch with the target HDL.  But in
>>>> some cases it was disabled because it was not supported by FPGA vendor
>>>> synthesis tools.  This was true with Verilog and Altera Quartus but my
>>>> guess is that the synthesis tools probably support the VHDL
>>>> initialization fine (have never ran into an issue).
>>>>
>>>> The initialization might have been disable because the converted Verilog
>>>> and VHDL would differ (a guess)?
>>>>
>>>> I quick test and the modified line 306 in _toVHDL.py in the latest
>>>> 0.8dev to:
>>>>
>>>>       print >> f, "signal %s: %s%s := %s;" % (s._name, p, r, str(s._val))
>>>
>>> I'll give this a try.
>>> Interestingly, the lines right above the one you modified are as follows:
>>>
>>>       # the following line implements initial value assignments
>>>       # print >> f, "%s %s%s = %s;" % (s._driven, r, s._name, int(s._val))
>>>
>>> They are commented, but they seem to be intended to do what we want
>>> although  the code looks different enough that I am not sure this
>>> would work with the current version of _toVHDL (there is no explicit
>>> "signal", it uses _driven() and converts the value to an int rather
>>> than calling str() on it).
>>
>> I am not sure what the comment line is but I do not believe it is
>> correct (at least not for VHDL).  Someone would have to review the
>> history to see
>
> I just did. That code is there since the toVHDL module was introduced,
> and it seems it was copied and pasted code from the toVerilog module
> (which predates it), since that exact line of code is found on the
> toVerilog module as well.
>
> By the way, I also tried your proposed "hack" and it almost works. The
> problem is that it just prints the initial value as is, wich means
> that it initialized std_logic values to False, for example, rather
> than to '0'.
>
>

Yes, the *quick* hack wasn't intended to be a completed feature.  As you 
point out the *quick* hack isn't that useful.

For a complete solution probably need to write a _getInitValue function 
which would be similar to the _getTypeString or _getRangeString.  Then 
it can format the the init value for the correct type.

Regards,
Chris