[SOLVED] Why initialize large array in Verilog is not successfully

This will generally work, if not, you probably experience a tool bug. Nothing we can discuss without mentioning tool and implementation details.

FvM said:

This will generally work, if not, you probably experience a tool bug. Nothing we can discuss without mentioning tool and implementation details.

Click to expand...

I build this code for FPGA Kintex 7 - 410T in Xilinx Vivado 20019. For memory with size of 255 it works but for more than 255,
My array reg initialize with zero...

Some links that is dicussed about this problom: But I can not understan the solution... Can anyone help me...

it is in the sections about inferring block rams. Also, Altera's tools are a bit dangerous in that in some cases they will fail silently. Eg, some use cases of inferred block ram will not use the readmemh line, but will not show any info/warning/error. Ironically, it becomes easier to mis-size (widths or depth) the entries in the readmem file as these conditions are warnings and will show that the RAM is initialized in synthesis.

https://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/xst_v6s6.pdf
This is described in the XST (13.1, v6s6) user manual on pages 86 and 221. The Quartus manual also shows how to use readmem. Just be sure to read the sections about all of the HDL issues with inferring specific hardware features, as they can be device dependent or non-obvious or benefit from additional synthesizer attributes. For example, many of Xilinx's non-slice registers only have synchronous resets, if any reset at all. Likewise, RAMs may need to register the address, but might not provide that registered signal back into fabric.

If you want to see something really interesting, look at the example of a true dual port inferred block ram starting on page 188 -- it uses VHDL's "shared variables".

I don't recognize anything related to the reported issue ($readmemh isn't working above a certain memory size) in the linked user manual and discussions.

You are aware that memory size (1025) and file size (1024) are mismatched in your code snippet?

Correction, the sizes are matched. We mostly use $readmemh without address specification.

I emphasize that size is 1025 and it is match with readmemh file.....but for large size more than 256 I faced with a strange bug....
I initialized reg array in initail block but in synthesis and running FPGA I see that reg array was not initialized.........

Finally the last reason that I found:readmemh is not synthesisable for vivado xilinx......it is ignored........

stackprogramer said:

Finally the last reason that I found:readmemh is not synthesisable for vivado xilinx......it is ignored........

Click to expand...

This tip is mentioned in The Verilog ® Golden Reference Guide

I'd trust Vivado user guide in the first place. It marks $readmemh as supported in the most recent version.

Presently I'm not using Xilinx devices in active projects, thus I can't tell about $readmemh detail issues. Perhaps a Xilinx practioner can comment.

FvM said:

I'd trust Vivado user guide in the first place. It marks $readmemh as supported in the most recent version.

Presently I'm not using Xilinx devices in active projects, thus I can't tell about $readmemh detail issues. Perhaps a Xilinx practioner can comment.

Click to expand...

ُThanks, But this case of being able to be synthesized is written in some documents that it can be synthesized, in some it is not possible to be synthesized, I don't know the reason, but for my FPGA case, it seems that it is not possible to be synthesized.

However, I would appreciate it if someone could come up with a better idea and reason.

Ok, first of all, your problem is that your memory is filled with zeros in simulation or in the FPGA? Is it a simulation problem or a synthesis problem?

For both cases you probably get a meaningful message in the log, giving a hint of why the memory could not be initialized. Please note you need to add the files (out_i.txt/out_q.txt in your case) to the project. Vivado may also be sensitive to path, so you must double check what the folder you are attaching the files.

So, try to check:

1 - Log files, they should give you some hint of why the memory is not initialized. Look for $readmemh/BRAM
2 - If your data files are added to the project
3 - Check if the path the tool is looking is the same path where the data files are present.

Thanks very much. My problem work in simulation but it not work in synthesis.........in build log I saw this warning.....I atteched out_i and out_q file....
But I can not found this warning and How I can solve it....

a same link had same problem...

WARNING: [Synth 8-2898] ignoring malformed $readmem task: invalid memory name [file.sv:50]
WARNING: [Synth 8-2898] ignoring malformed $readmem task: invalid memory name [file.sv:51]

I am not totally sure what exacts formats Vivado accepts or deny, but I always use <ENTER> as a separation of BRAM words. Also, I think BRAM expects a fixed length value.

So, in you file "out_i.txt" you have (first 8 words):


I would put this as


Of course, this should be applied to the whole data file. Also, careful with extra spaces after the data, there should be no spaces before <ENTER>.

I test with this files but warning is live yet......In simulation it works but i synthesis I faced with this warning........How can solve problem.........I
am sure that path to files is true.............

WARNING: [Synth 8-2898] ignoring malformed $readmem task: invalid memory name [file.sv:50]
WARNING: [Synth 8-2898] ignoring malformed $readmem task: invalid memory name [file.sv:51]

I don't know what "invalid memory name" means, I guess it's not related to the data file content.

Is it possible to setup a small test project demonstrating the error?

Could it be this problem? https://support.xilinx.com/s/article/58967?language=en_US

O.K., "ignoring malformed" seems to refer to a different problem https://support.xilinx.com/s/article/62935?language=en_US
In my words, you are using the memory in a way, that no block ram can be inferred.

I would suggest trying with the format of $readmemh(<file_name>, <memory_name>), i.e. without the address, Vivado's implementation of $readmemh may not support addresses. IIRC or it was changed: if the memory<file then file contents are truncated and if the memory>file then memory is zero filled.

I also think the issue with the link back in post #10 has more to do with the module inner using an array (input bit[15:0] things[256],) for a module port. This is probably something that wasn't supported (SV) in Vivado 2016.3 as Xilinx has traditionally been very slow adopting language updates. I also saw a post on Xilinx/AMD forum that says SV arrays aren't supported in Vivado 2018.3 either.