Re: [myhdl-list] Restrictions for conversion

[Christopher F. <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.

>
>
>> 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?
Note: these are only simulation and or "special" synthesis mapping 
initial values.  Reset values are still reset values.

The only thing that needs to be determined is if the initial block needs 
to be added.  That should simply be based on list of signals or not.

Regards,
Chris