Re: [myhdl-list] Restrictions for conversion

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

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


>>> 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"
a example in for verilog could look like this:

   Myhdl code:
   ------------------------------------------------------
   def TOP(out1,in_data):
       aListSig=[Signal(intbv(i)[8:]) for i in range(10)]

       @always_comb
       def comb_logic():
	  out1.next=aListSig[3]

       @always_comb
       def comb2_logic():
	  aListSig[3].next=in_data
	
       return comb2_logic ,comb_log


   Verilog code:
   ---------------------------------------------------
   module TOP (
       out1,
       in_data
   );
   output [7:0] out1;
   wire [7:0] out1;
   input [7:0] in_data;
   wire [7:0] aListSig [0:10-1];

   //hypothetical inital block would be placed here
   //but if a initial block is placed here
   //the code is no longer valid because "aListSig" is defined as wire.
   //but it needs to be defined as wire because somewhere in the code  
someone
   //writes to the variable "aListSig" in combinatorically assignment.
   //therfore the initial signal cant be written in the case when a  
combinatoricall
   //assignment to the variable "aListSig" takes place somewhere in the  
code.
   //Anyway a initialvalue is not needed when a combinatorical assignment  
to the variable "aListSig" is made,
   //because the "aListSig" then gets its value imidiatley at the beginning  
of the simulation by this
   //assignment.(or after some delta cycles with zero delay).
   //In verilog the complete signal array is defined as wire, so if only  
the variable
   //with index 3 is (as below aListSig[3]) used combinatorically then the  
complete array
   //needs to be defined as "wire" and therfore no initialvalues are  
possible

   assign aListSig[3] = in_data;
   assign out1 = aListSig[3];

   endmodule




greetings
Norbo