New Contributor
Regular ContributorHi,
I am able to observed that the hex file be used on Quartus. You should be able to observed the below message when you are compiling your design.
Warning (113007): Byte addressed memory initialization file "KBReader.hex" was read in the word-addressed format
Warning (113014): Width of data items in "KBReader.hex" is smaller than the memory width. Padding data items to fit in memory. Found 1024 warnings, reporting 10 .
Warning (113011): Data width of the data at line (1) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (2) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (3) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (4) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (5) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (6) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (7) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (8) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (9) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Warning (113011): Data width of the data at line (10) of memory initialization file "KBReader.hex" is smaller than that of the memory word. Padding with "1" on the LSB.
Critical Warning (127004): Memory depth (512) in the design file differs from memory depth (1024) in the Memory Initialization File "/data/ts_farm/zctio/ISVC/04439636/KBReader.hex" -- truncated remaining initial content value to fit RAM
New ContributorJust had an hour or so to look at this.
I re-did the data for the memory into 16bit tab delimited format and loaded it into the File /New/Memory files/Hexadecimai(intel-Format) File process. This has indeed produced a file with 2 bytes/line and address increment by 1 on each line. (I made sure it was expecting 9bit address and 16bit data width)
I then fed this into the Megawizard plug-in manager and generated the vhd file(s) for the read-only memory.(Only option here for 16bit data/ 9bit address)
The large(~41k) output file is similar to the one I saw previously (Blocks of '1's first as before).
But where the all '0's was before there is some indication of data in blocks 'mem1..5'
I'm still a little concerned as my data should only be in addresses 0..131 and use 16bits but the bits go from the start to near to the end of a used block and only use 5 mem lines. That may be just how the memory is organised for being programmed but seems odd
Just to complete the process I put the component into a basic schematic and tried compilation.
This succeeded with a few warnings about constraints and pin assignments and one that I had not actually included the component files but was using them anyway. (They were all in the project folder)
Nothing about data width mismatch or excess lines.
At this stage I am still not sure that the UFM data has been fully included in the final compilation.
I will try to attach the zipped folder (what a weird selection process!)
Phil
New ContributorJust had a few more minutes to apply here.
Definition: mem1 : STD_LOGIC_VECTOR(511 DOWNTO 0) -- from the 41k .vhd file
It seem that the data is put first into the array of mem1 with the lowest address word put at the end of mem1.
It then fills successive words towards the start (which seems to be mem1[511].
With this arrangement it only takes 5 mem blocks to accommodate my 131 words. (The rest being filled with '0's)
I'm now much happier that the data is being procesed correctly and should work when I complete the design (if it fits)
I'm not quite sure what the first block of '1's is - maybe it is to erase the UFM before loading the data.
It is one of those situations where once you have succeeded in doing the process it is simple but to get there the fine details of the necessary steps are somewhat unclear.
The error messages from JohnT were a great help in sorting this out - many thanks.
Phil
