Re: [myhdl-list] Restrictions for conversion

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

On 5/5/12 4:00 AM, Norbo wrote:
> Am 05.05.2012, 06:49 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
>
>> On 5/1/12 1:00 PM, Norbo wrote:
>>>> I was taking a look at your patch, your patch is not based on the
>>>> latest
>>>> 0.8-dev branch. There are enough changes that it doesn't auto import to
>>>> the 0.8-dev branch.
>>>>
>>>> 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).  There are a set of 
rules that decide for you if initial values are to be generated or not. 
  I would think explicit would be the use of None, you are directly 
indicating no init values.

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 think the question; "Is the absence of initial values detrimental 
because it causes a co-simulation mismatch"?  If it decided this is a 
bad thing then I think we need to live with the long init list or 
support the None initial values on the MyHDL side.

>
>>>> Lastly, the changes do break the unit-tests. As mentioned, the patch
>>>> didn't auto import. I believe I got all the changes manually but
>>>> possibly something was missed in the manual addition of the changes. I
>>>> think removing the _doinit will fix the failures (but I didn't really
>>>> look that closely).
>>> The now appended patch file is based on the 0.8-dev branch, the core
>>> test
>>> passes but until now i wasnt able to
>>> run the conversion tests.
>>>
>>> The initial values in this patch for the array signal are now written in
>>> the following casess: for VHDL and Verilog:
>>>
>>> 1. reading it in a combinatorical process --- initial values are written
>>> 2. reading it synchron (clocked) --- initial values are
>>> written (could be used to describe inited ROM)
>>> 3. reading it synchron (clocked) and writing it synchron --- initial
>>> values are written (could be used to describe pre-inited RAM, or even
>>> pre-inited dual ported RAM)
>>> 4. reading it synchron (clocked) and writing it in a combinatorical
>>> process --- initial values are not ! written (because it is
>>> syntactically
>>> not possible in verilog)
>>> 5. reading and writing in a combinatorical process --- initial
>>> values are not ! written (because it is syntactically not possible in
>>> verilog)
>>>
>>>
>>> would this be acceptable/desirable?
>>
>> Lost me.  I don't understand why it matters how the Signal variable is
>> used to determine if the initial value should be written.  As mentioned,
>> shouldn't the initial values always be written?
>
> For example for the case 5. "reading and writing in a combinatorical
> process"
>
>     assign aListSig[3] = in_data;
>     assign out1 = aListSig[3];
>
>     endmodule
>

This might be the path of least resistance right now.  But I don't think 
there is a reason that the converted couldn't generate

      reg [7:0] out1 = 8'd0;
      reg [7:0] aListSig [0:10-1];
      // initial blocks ...
      @always_comb begin
          aListSig[3] = in_data
          out1 = aListSig[3]
      end

This is only an issue in Verilog and not VHDL.  Maybe a behavioral 
statement should be written instead of a continuous assignment.  To me 
it appears a lot of complexity would be added which could be avoided by 
simply converting the Verilog similar to how the VHDL is converted.

Regards,
Chris