Re: [myhdl-list] Signal initialization

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

On Sun, Dec 2, 2012 at 12:57 AM, Christopher Felton
<chr...@gm...> wrote:
> On 11/30/12 6:20 AM, Angel Ezquerra wrote:
>> Hi,
>>
>> I have a question that probably is quite basic, but I don't seem to
>> get it right and I have not found an answer on the documentation
>> (perhaps I missed it though).
>>
>> I am making a simple MyHDL module, and in it I define several
>> std_logic signals as follows:
>>
>>     captured, demet, sync1, sync2 = [Signal(bool(0)) for n in range(4)]
>>
>> I expected these to be converted into the following VHDL:
>>
>>      signal captured: std_logic := '0';
>>      signal demet: std_logic := '0';
>>      signal sync2: std_logic := '0';
>>      signal sync1: std_logic := '0';
>>
>> Instead I get:
>>
>>      signal demet: std_logic;
>>      signal sync2: std_logic;
>>      signal sync1: std_logic;
>>      signal captured: std_logic;
>
> 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).

That being said, I don't really know about Verilog, but default signal
values are part of the VHDL standard syntax. I don't understand why
would we not support it. IMHO it is _very_  surprising to have the
convertor ignore the init value that you explicitly set on the python
code, when the VHDL standard supports such a thing.

Do you know if there are any plants to add this to 0.8? Maybe Jan
could give his opinion on this?

>>
>> Other than the order not being the same, which I guess is unavoidable,
>> the values are not being initialized to zero as I expected (which
>> causes my simulation to fail).
>
> Why does it cause your simulation to fail?

By "fail" I meant "it does not work as expected". If I compare the
(modelsim) simulation results of the generated VHDL code with and
without the default values the result is quite different. Without the
initialized values a lot of the signals have an undefined value at the
beginning, which causes my circuit to miss the first event on my test
bench.

This could be fixed by changing the reset code, but I do not want to
do that. The project I work on often relies on initial values to avoid
reset code which is sometimes expensive in terms of FPGA routing and
area. Our resets are often "light" in the sense that they just make
sure that the processing does not start until the reset is deasserted.
They are not meant to be able to reset the whole FPGA to its initial
state. It is "cheaper" for us to just reload the FPGA whenever we want
to do a real reset.

>> Additionally, I see in the converted code that the following code:
>>
>>      captured.next = not demet
>>
>> which uses the signals declared above is converted into:
>>
>>      captured <= stdl((not bool(demet)));
>>
>> rather than into:
>>
>>      captured <= not demet;
>>
>> The conversion from std_logic to bool and then back to std_logic is
>> unnecessary... I guess it probably does not matter except perhaps
>> during simulation before the reset, but maybe it can cause some
>> problems in simulation as well?
>
> I can't think of any simulation issues that may occur?  Simply cast
> std_logic to a bool perform the not on a bool then cast back to a std_logic?

I was thinking of the behavior of the code when some signals are still
not initialized (i.e. undefined). The "stdl" and "bool" functions on
the pck_myhdl helper file use comparions with 0 and '1'
(respectively), and I am unsure as to how those will behave when fed
and undefined value:

    function stdl (arg: integer) return std_logic is
    begin
        if arg /= 0 then
            return '1';
        else
            return '0';
        end if;
    end function stdl;

    function bool (arg: std_logic) return boolean is
    begin
        return arg = '1';
    end function bool;

In addition I wonder if this will not make VHDL simulations slower
unnecessarily? I don't know... it just feels a bit unnecessary.

Cheers (and thanks for your reply!)

Angel