Re: [myhdl-list] Restrictions for conversion

[Christopher F. <chr...@gm...>]

On 5/23/12 4:01 AM, Jan Decaluwe wrote:
> On 05/23/2012 04:37 AM, Christopher Felton wrote:
>> On 5/22/12 4:32 PM, Jan Decaluwe wrote:
>>> On 05/22/2012 05:34 PM, Christopher Felton wrote:
>>>
>>>>
>>>> FPGAs support pre-init RAM.  Synthesis will extract the array initial
>>>> values from the HDL and during configuration program the BRAM (internal
>>>> FPGA RAM).  When the FPGA comes out of reset (not logic reset, FPGA post
>>>> config reset) the RAM will contain the initial values.  The RAM is a RAM
>>>> so the values can be overridden by the logic, i.e not a ROM.  This is
>>>> only possible in an FPGA and is supported by X&A synthesis tools.
>>>>
>>>> I don't know a reasonable method to achieve the pre-init RAM, currently.
>>>
>>> Do you mean no reasonable method from MyHDL, or no reasonable method
>>> at all?
>>
>> That was somewhat missed phrased, "... reasonable method ...".
>> Currently initial values are not supported (enabled), for basic types or
>> arrays (memories).  Currently you cannot do either.  I should have
>> said, pre-init RAM is not supported in MyHDL.
>>
>> Known, reasonable, RAM pre-init methods are available for Verilog/VHDL.
>>     It seems reasonable to include with the initial value support.
>
> Yes. Now, from the altera literature it seems they also support
> $readmemb, which would make it possible to initialize a RAM with
> arbitrary values. But I don't know how to do that with VHDL.

The Verilog initial and the VHDL function just get ugly to the human 
reader.  Nothing says you can explicitly list each array element.  This 
is where the concern to disable arose.

     initial begin
         mem[0] = 123;
         mem[1] = 78;
         ...
         mem[31] = 9;
     end

     FUNCTION ...
     BEGIN
         result(0) := to_unsigned(natural(123), natural'(8)
         result(1) := to_unsigned(natural(78), natural'(8)
         ...
         result(31) := to_unsigned(natural(9), natural'(8)
         RETURN result;
     END

This is what was prototyped.

>
> Would it be sufficient to support memory initialization to
> an identical value for each location?
>
>> Norbo prototyped this and it all seemed good but we have been discussing
>> the overall behavior.  I think this is where we sit right now.
>>
>>       1.  Initial value support should be added, it resolves
>>           the time 0 mismatch.  It has been verified with
>>           the latest versions of Quartus and ISE.
>
> Yes.

The one implementation detail we ran into, was that the continuous 
assign statements in Verilog will need to be replaced with an @always block.

>
>>       2.  Intial value support for arrays should be included
>>           (all types are initialized).  Verdict is still out
>>           if the ivs for arrays should be "synthesizable".
>
> Yes.
>
> In summary: I think initial values should be written, regardless of
> what synthesis does with it, because of the exact match in
> simulation.
>
>
>>       3.  Unresolved, should there be a method to disable
>>           ivs.  The current proposed method is to use None.
>
> As a fallback method, I think it would be wise to be able
> to disable initial value writing by a control parameter
> to toVerilog/toVHDL. A separate control for plain signals
> and arrays probably. But this would be purely because some
> synthesis tools may not support the syntax.
>
> I don't see a value in adding support for None to intbv,
> as discussed before.
>

Sounds fine to me, to disable you would need to explicitly send the 
argument to the conversion for plain signals and/or for arrays.

Regards,
Chris