Re: [myhdl-list] Restrictions for conversion

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

Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton  
<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).
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 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.




> 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

nice: @always_comb begin a myhdl artefact ;)

>           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.

Damm, i overlooked that. The synthesis of the follwing is succesfully.

   ....
   reg [7:0] aListSig [0:10-1];

   initial
   begin : INIT_aListSig
   aListSig[0]=0;
   aListSig[1]=1;
   aListSig[2]=2;
   aListSig[3]=3;
   aListSig[4]=4;
   aListSig[5]=5;
   aListSig[6]=6;
   aListSig[7]=7;
   aListSig[8]=8;
   aListSig[9]=9;
   end

   always @(in_data,aListSig[3]) begin // or   always @* begin
       aListSig[3] = in_data;
       out1 = aListSig[3];
   end

summary:
this means the "assign" in the verilog conversion needs to be replaced (by  
always @* begin ... end) and
also if it gets declared as "wire" would need to be defined as "reg".


another point is that i think it is a good thing to have all the variables  
by default not to be initialized
with values in the converted code. Initialisation should only occour if  
you really want to describe (pre-init RAM)
or ROM.
because for example in VHDL all the std_logic signals are set at startup  
of a vhdl simulation to the value 'U' (stands for uninitialized) if there  
is no other initial value given. After the reset all values should have  
changed from this
'U' to something usefull. This allows you to see imidiatly if you have  
messed up or missed something in the reset code.
If all values are set by default to something usefull you can easyl  
overlook some resets, you couldnt even check it
with a testbench at startup if the reset is done properly, when the  
initial value has the same value as the reset value you have forgotten in  
the code.

The point is, by default no initial value should be written in the  
converted code, only when you need it explicit to describe something.
Maybe a default None value in the intbv?

grettings
Norbo