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