ROM Hex file format required for Quartus Verilog
Cluso99
Posts: 18,069
Today I noticed the hub_rom_high.hex and hub_rom_low.hex files have invalid addresses in the intel hex format.
eg the length of each line is $20, and the first address is $0000. But the next address is $0008, then $0010, then $0018.
Obviously Verilog doesn't care.
Postedit: See Post #33 for the Intel Hex file format required by Quartus II v14.0 (Windows 8.1 64-bit)
http://forums.parallax.com/showthread.php/160734-Has-anyone-noticed-the-ROM-hex-files-have-invalid-addresses-(the-git-version)?p=1325747&viewfull=1#post1325747
I have renamed this thread's heading to be more appropriate to the topic.
eg the length of each line is $20, and the first address is $0000. But the next address is $0008, then $0010, then $0018.
Obviously Verilog doesn't care.
Postedit: See Post #33 for the Intel Hex file format required by Quartus II v14.0 (Windows 8.1 64-bit)
http://forums.parallax.com/showthread.php/160734-Has-anyone-noticed-the-ROM-hex-files-have-invalid-addresses-(the-git-version)?p=1325747&viewfull=1#post1325747
I have renamed this thread's heading to be more appropriate to the topic.
Comments
I think Quartus generates a warning about the files, but it converts the long words to bytes and stores them correctly using "ram_init_file" directives in the source code. However, this method is Quartus-specific and isn't compatible with the Xilinx tools. The old Github tree (from before Parallax created their community) contains a change where the Intel files were converted to hex files, and where the initialization was changed to use $readmemh. We also de-scrambled the code and split the files up into smaller parts to make it easier to do cherry-picking. I intend to integrate those changes into the current P1V repo but I've been very busy with work, a move from Arizona to California, and other projects.
===Jac
Yes, I just realised that the addresses were >>2 for long addresses. But the length is in bytes. Curious format!!!
Quartus cannot handle comments at the end of a line eg // -ascii-, but its fine with single line comments beginning with //.
I have yet to determine if it does not like the spaces between bytes, or if its the address it is complaining about.
I created the various scrambled and unscrambled files. I used $readmemb, but that required 4 byte files for my byte-configured hub memory.
The advantage of having the hub ROM byte-configured is that you can then permit writes to the ROM section of the hub memory.
Therefore, you can loadup the default ROM, but permit the user to overwrite it and use it as RAM. Sort of an each-way bet.
Before you put them in the repo, I am in the process of re-generating them again.
the different programmers as to what they considered to be the "correct" Intel hex format.
Some of these programmers even had tools to convert Intel hex files into other formats.
IIRC some hex file generators used little endian, some big endian, some words etc.
Depending on the programmer used dictated the file format required.
It never was as simple as it should have been.
Quartus seems to give warnings for all the different formats I have tried.
In the end the format used in Chips original hex files works fine so I went back to that.
I wonder what method Chip used to generate his files?
I have done a comparison between my files, both identical. The original gives no warnings and the new file gives a warning about incorrect lengths on each line
The warning is
113015 Width of data items in "...filename..." is greater than the memory width. Wrapping data items to subsequent addresses. Found 512 warnings, reporting 10.
I just tried cutting/pasting into Notepad. Still fails. It isn't the sort of warning that you should ignore.
All sorts of modified booters and spin hacks that have loaded correctly to the right destination.
From my experience all the failures I encountered were related to bad coding on my part.
I gave up fighting Quartus on the "warning" front as the proof is in the download to the fpga target.
All attempts at including timing files in my case made the warning count worse.
Open the hex file with Win8.1 Notepad. (I create this via a spin program and cut/paste from PST to PropTool and save. It is a complete ROM file).
Cut the desired section (from the start of the desired line to the end of the last desired line)
Paste New in Notepad
Save As rom_low/high_xxx.hex as a Unicode, *.txt file
Close Notepad (this is important)
Open the saved file with Notepad,
Save As rom_low/high_xxx.hex as an ANSI, *.txt file, replace=yes
Close Notepad. Your file is now ready for Verilog.
Note that I have Notepad selected as the default program for *.hex files, so the above Save As does not append .txt to the filename.
At least this process works. There must be some file header info in windows that quartus does not like ???
I have also had an attempt (months ago) to get rid of the errors, but had no success.
This addressing change was the only one that worked in the FPGA target.
I am preparing to load my faster spin interpreter
Still, as long as users know what works with no errors, and that variant looks easy enough to convert to.
One now hopes that some intern at Altrea does not fix the 'hex' file reader, to actually read hex files !
Oops! 32 bytes. I corrected my post.
Are you saying that the Notepad procesdure eliminates the following warning???
Width of data items in "...filename..." is greater than the memory width. Wrapping data items to subsequent addresses.
Both methods work fine in the FPGA target but the 32 byte variant produces the above warning.
However, no warning is always better than confusing warnings, so that promotes the 'fixed' version, but I would rename the files .qex. & maybe check every 6-12 months to see if Quartus removes the warning on a valid .hex file.
Other toolchains may need valid hex files, so that needs to also be possible.
My rom high file has 2 lines where the length is 4 bytes and 28 bytes (needed for the SIN table). This works fine too.
It seems that there is something wrong with the actual file header (not the data in the file).
I now have unscrambled roms working again. I will post them shortly as the files are based on the latest git files.
Quartus is obviously checking something else to do with the file header (ie file label, not data).
The correct intel hex file format has means to manage 32b address, Altera should properly follow that.
I still say name these Quartus variants .qex, to avoid confusion.
I created the "x" variant by opening the non-x file with Notepad, did Ctl-A to select all, and Ctl-C to copy all, then file/new, Ctl-V to paste all, and then Save As ANSI *.txt with the filename rom_high_v028x.hex
Notepad does not add ".txt" as I have made Notepad my default editor for ".hex" files.
Can anyone see any difference in the two files???
It is well documented.
Because the addresses are contained in each line, it is easy to merge two or more file sections with an editor.
I found similar problems with getting the syntax correct with $readmemb/h months ago.IIRC in the end I had to just use straight hex without any @ or addresses.
Notepad++ File Compare plugin says they are identical (39448 bytes, 514 lines)- however, I notice they both do lack CRLF on the last line, and some readers may not like that.
If you add a CrLf to the last line, does the difference persist ?
It still produces the warning at this end.
The Quartus "Vortex of weirdness!"
If it loads ok in both cases, suggests they are doing the right thing, just giving a bonus/bogus warning set then they do the bleedin' obvious of "Wrapping data items to subsequent addresses"
BTW I get 512 warnings, reporting 10.
I might try (later) to just output 4 bytes per line, but I need to do that with TeraTerm or equiv. The PST window is not long enough.
I just unzipped and the file works fine here. Thought it may be the recreating of the file header.
jmg,
I thought it worked better with the last cr removed.
BTW I am generating an FDX output to PST (with cr only, no lf). Then I copy and paste into Notepad.
Both work but the 32 byte version produces the warning.
I also get 512 warnings from your file too.
A quick way to check how Quartus will react to the hex files is to use the following function from the top menu
>Processing>Update Memory Initialization File
Quartus doesn't like ypur idea jmg.
I used TeraTerm to save the logfile and edited it down with Notepad.
Now works fine without complaints, including permitting the comments beginning with // to remain. Never could do this before!
Just regenerated the rom_low_v029.hex and rom_high_v029.hex files.
[/Oops! I goofed up and the extract didn't unscramble correctly.I]
My suggestion was .QEX not GEX, but it should not care what extension the file has, surely - if you give it a full file name?