Memory data misplaced when initializing from .hex file

Actually, yes, using one word per line style fixes this problem. Still, this is not solution for me, because I`m going to use Atmel Studio generated hex files, and it output data in 16 bytes per line. Looks like I have to create a converter script, to parse file and reformat it after build.

Does anyone know, may be there is a better solution?

I guess that is the right thing to do. As you are using the Lite version, would you like someone else to file a bug report ?

How are you connecting this ROM to the rest of your design and how are you accessing it? Without more detail on the design, it's hard to figure out why this is happening.

In simulation, there is no connection to the system, I`ve simulated just the bare vhdl file, generated by IP core. Respectivery, signals clock, address and q are going directly to the component.

In FPGA trial, I`ve tested this component inside following top-level design:

where CLK is 50MHz clock from external crystal oscillator, and LEDS[15..0] are GPIO outputs connected to 16 test LEDs on the board. Timing analysis suggest, that I can run CLK pin at 113MHz, so there is no clock issue. I`ve scanned my ROM by changing lpm_const_rom value, re-compiling and re-uploading it via JTAG. Still, I`m getting zero values for addresses 0x08 - 0x0F, while actual content of these are shifted to 0x10 - 0x18, exactly the way it was simulated. This gap is inserted after every 8-word blocks of data and always consists of 8 words of zeros.

So, obviously there is compile-time error and both Quartus and ModelSim read this file wrong due to some formatting incompatibility. The question is: how then the file should be formatted, in order to get rid of memory content displacement?

I am too lazy to try to run your symbolic entry code, but it seems that your hex file is correct, the documentation that I found gives no indication that it should be different. You can find a description of the Intel hex file format in Wikipedia.

However, we have some files where we do it differently:

1. We have only one memory word per hex-file line:

:020000000001FD

:020002000002FA

:020004000003F7

:020006000004F4

:020008000005F1

...

:00000001FF

2. Our hex file has a header line that sets the start Extended segment address. This should not be necessary, but perhaps the tool expects it. So if point 1 does not help, you could try to add it as well:

:020000020000FC

<deleted>

Yes, I would like to write a bug report, I just can`t find a way to send it :-) Maybe You could help?

I`ve found the most basic way to replicate this issue. Take following *.hex file:

:1000000000010002000300040005000600070008CC

:100010000010001A001B001C001D001E001F002005

:00000001FF

If You open it in Quartus and specify 8-bit word length, it works just right:

If You open the same file specifying 16-bit word length, data addressing is broken:

As there was no gap in initial data, value 0010 supposed to be at address 08, value 001A at 09 and so on.

Exactly the same data displacement happens, if you initialize ROM or RAM from Basic Function IP with this file, and simulate this component in ModelSim, or compile it and upload to FPGA.

Tested in Quartus Prime Lite 18.1.0 Build 625 09/12/2018, ModelSim Intel FPGA Starter Edition 10.5b revision 2016.10, and on Cyclone IV EP4CE6E22C8N.

Temporary fix: reformat the hex file in one word per line style.