I am having problems in creating and simulating HEX files for (here Stratix GX) block RAMs. I am having an output in the format of intel's hex, but with an increased number of columns per line. In fact, I have 32 words (8 bits) to load into a 64k x 32 BRAM::20000000F4E40000E9C8F4E4E9C8F4E4E9C8F4E4E9C8F4E4F4E4E9C800000B1C0B1C00000D The special thing about his ram is, that it has a 32bit input and a 64bit putput. I tried to simulate in Modelsim and It runs with Port B (the 32bit-Port), but the modelled output has gaps ! How must this be done then ? Then I tried the MIF-Editor, to create a MIF. I am having this here : WIDTH=32; DEPTH=65536; ADDRESS_RADIX=HEX; DATA_RADIX=HEX; CONTENT BEGIN 00000 : F4E40000; [00001..00004] : E9C8F4E4; 00005 : F4E4E9C8; 00006 : 0000B1C0; 00007 : B1C00000; 00008 : F4E40000; 00009 : 0000F4E4; 0000A : F4E40000; 0000B : 0000F4E4; 0000C : F4E40000; running to 095FE : 6380000E; 095FF : 9C80000E; [09600..0FFFF] : 00000000; END; Since I cannot simulate this in Modelsim, I changed to hex (save as) and found that the result can neither be simulated nor loaded into Quartus. ??? Now, how would a correct HEX file look like - beeing suitable to such a ram ? - This is the definition : ENTITY dpram_64_32 IS PORT ( clock : IN STD_LOGIC ; data : IN STD_LOGIC_VECTOR (31 DOWNTO 0); rdaddress : IN STD_LOGIC_VECTOR (14 DOWNTO 0); wraddress : IN STD_LOGIC_VECTOR (15 DOWNTO 0); wren : IN STD_LOGIC := '1'; q : OUT STD_LOGIC_VECTOR (63 DOWNTO 0) ); END dpram_64_32; Thanks in advace!
No, it only works with one Port of course and I got the right one: Modelsim accepted only the right declaration, but showed empty ram cells though. Only some of them are written. It seems, that the address naming of the HEX is not interpretated correctly.(To clarify: I worked with a HEX (not a MIF) in Modelsim.) I really need a solution for this. I tried again to write my data into a newly created HEX, but it is not saved the way, I expected this. What would be the correct size declaration for this ram ?
If I set to comfort to "PORT B" which is 64-bit in this case, what I usually did is to declare the HEX file format with 64-bit word size too rather than 32-bit word size. Writting HEX file with 32-bit word size, will append the "0" is the rest of the MSB. Unless this is what you want, then this it is okay. Hope it helps.
I tried so and still get an error with Modelsim: "IndexValue 32768 is out of range (32767 ... 0)" just as with the former file.I also cutted my ram into 4 peaces to partially load them. I currently have 4 rams like this here : ENTITY dpram_16_32_1 IS PORT ( clock : IN STD_LOGIC ; data : IN STD_LOGIC_VECTOR (31 DOWNTO 0); rdaddress : IN STD_LOGIC_VECTOR (12 DOWNTO 0); wraddress : IN STD_LOGIC_VECTOR (13 DOWNTO 0); wren : IN STD_LOGIC := '1'; q : OUT STD_LOGIC_VECTOR (63 DOWNTO 0) ); END dpram_16_32_1; ... and applied to each of them a individual hex like this here : :04000000F4E4000024 :04000400E9C8F4E46F :04000800E9C8F4E46B :04000C00E9C8F4E467 :04001000E9C8F4E463 :04001400F4E4E9C85F ...... Modelsim (AE+SE) still refuses to work with it, while synthesis runs to the end. What appears strange to me: It does no matter to which of the two Ports the HEX file is assigned to in the wizzard. Synthesis works in both cases. I checked the sources of the dpram.vhd and found , that the assignment worked: In one case PORTA was assigned and in the other case PORTB. ?
I found what is going on:Altera Q72 writes a continously filled sheet , with data like this : 1 00 01 02 03
2 04 05 06 07
3 08 09 10 11
4 12 13 14 15 ... as a hex file like this : :0400000001020304f2
:0400080009101112b8 ... where the 0004, 0008 are obviously byte adresses, while ModelSim wnats to have word adresses. So there is a mismatch.:mad: This hex above shows up in Modesim like this : 0000000000 0009101112
0000000000 0001020304 which means reverted in order and only every 4th word written.:( What is the right interpretation of this intel HEX ?:confused: ------------------------ I stepped back to MIF and found that the same HEX file saved as a MIF runs right in Modelsim. It worked with ModelSIM SE 6.3c :cool: - I have no Idea why it failed with 61.g AE before.