myhdl-list

Re: [myhdl-list] Restrictions for conversion (initial values)

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

Am 26.04.2012, 05:49 Uhr, schrieb Christopher Felton  
<chr...@gm...>:


>> .. signal cant be defined as reg when you write to in a combinatorical
>> process. So if you write to just one signal in the array the whole array
>> needs to be defined as wire and you cant use the
>> initial statment for that signal array, so you cant initialize all the
>> other signals which are not written in a combinatorical process.
>> it normally makes sense that  if you have a inital value in a signal  
>> that
>> you are not allowed to overwrite it immidiatly with an combinatorical
>> assignment.
>> But the problem is that if you just use one signal of the array to write
>> to it in a combinatorical process, you "lose" the hole array.
>>
>> Addition: "if there is a asynchron reset in a clocked process where you
>> assign on of the array signals a reset value, then the verilog synthesis
>> works with the initialized array"
>
> This is an alternative to the initial block initial values (pre-init  
> RAM)?

If you initialize the signals in the reset part of the code, then the  
synthesis tool
will map this to a register. So there is no change that the synthesis tool  
can map
this to RAM or BRAM, because average RAM doesnt have an asynchron reset  
input.



The question on the myhdl side for me is really more if i can express all  
sort of different things (e.g pre-init RAM).
This should then give synthesisable code, and  wheter the synthesis tool  
maps it to RAM, ROM, BRAM, registers,LUTs, etc is then dependend on what  
fpga device is used, what synthesis setting are made or how much RAM, ROM,  
logic, etc blocks are left in the device. The last process should be an  
issue of the synthesis tool. And from my expirence in 99% of the cases  
they do a good job
if you give them synthesisable vhdl or "verilog" code.


myhdl side      -> being able to express all sort of things (also pre-init  
RAM), with the goal to produce synthesisable vhdl or verilog code
synthesis tool side -> optimize, map to RAM, ROM, logic, registers  
dependend on what device it is synthesised for. If the device
has no ROM or no RAM, then it will be mapped to logic und registers anyway.





>>
>> 5. reading and writing in a combinatorical process
>> same problem in verilog ->  you cant have the signal array be defined as
>> "wire" and use the init block statment in verilog.
>> Or in other words: If the signal array is defined as "reg" you cannot
>> write to it in a combinatorical process.
>>
> In the above can you clarify between what synthesizes and what creates
> RAM/ROM as expected.

In the above everything is mapped into logic and register, because i used  
the initialized
array with multiple indexes in one expression. -> then everything was  
mapped to logic.
But this doesnt mean that other synthesis tools, or even quartus, could  
map same parts of it to RAM, or ROM blocks, i didn't
looked to deep into the settings.

For me the idea is to produce a code for the synthesis tool, so that the  
synthesis tool at least has the opportunity to map it to a RAM block. If I  
have to assign the initial values at the asynchron reset part to the  
signal, then the synthesis tool as no opportunity to map it into RAM. This  
is where the initial values and initial blocks come into play, beeing able  
to express this.



greetings
Norbo

Re: [myhdl-list] Restrictions for conversion

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

Am 10.05.2012, 04:06 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> On 5/5/12 10:20 AM, Norbo wrote:
>> Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton
>> <chr...@gm...>:
> <snip>
>>>>>>>
>>>>>>> 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 think we are both in agreement, now, that the None can be used for the
> explicit control (which means more changes in the implementation).  But
> I don't think I agree that there are cases when the values should *not*
> be written.  I think they should always be written (when not None).  I
> think we can work through the implementation changes.
>
> If None is used, that should mean the _doinit is not required.
>
>>
>>
>>> 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.
>
> It has been brought up in the past that if MyHDL simulation has initial
> values and the Verilog/VHDL does not have initial values.  Then you have
> a simulation mismatch at time 0 through time N (most cases, until the
> reset occurs).
>
> I think we have a good design plan to cover the initial values that
> includes the pre-init RAMS (nice addition).  We should probably
> summarize in a separate post (new thread, not buried).  I boils down to
> adding support for None and then creating  initial values in
> Verilog/VHDL if the intbv initial value is not None.

yup i think that hits it.
So i would summarize it like this:
* Adding support for None in the intbv (also setting None as the default  
value?)
* Creating initial values in Verilog/VHDL (when not None)
* Changing the verilog continuous assignment to the behavioral statement  
in the verilog conversion
* Work through the implementation changes needed, because of the None in  
the intbv (boundchecks, etc ..)