Memory data misplaced when initializing from .hex file

[VMize]

I`m using Quartus Prime 18.1 Lite, Model Sim 10.5 Starter, and Cyclone IV FPGA.

I`ve created a 1-PORT ROM from Basic Functions library, with 256 words of 16 bits. I`m trying to initialize it with following *.hex file:

:1000000000010002000300040005000600070008CC

:100010000010001A001B001C001D001E001F002005

:00000001FF

That represents following table:

However, when I simulate this memory component in ModelSim, memory content is misplaced, and I get 8-word wide gap of zero data:

And if I try to upload this to real FPGA, then I get exactly the same behaviour.

I`ve tried to verify my hex file by opening it in various hex viewers, and all of them read correct data.

I can`t use Quartus to edit and save hex file, because later I`ll initialize my memory with Atmel Studio generated files. These files also suffer from the same problem.

Is there any way to fix this? May be I need to use some file format convertor? And why, in first place, only Quartus/ModelSim read this file wrong, while any of 3rd-party viewers do it right?

[sstrell]

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.

[VMize]

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?

[schendel_nsf]

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

[VMize]

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?

[schendel_nsf]

<deleted>

[schendel_nsf]

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 ?

[VMize]

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.