I want to generate a .vhd file to load UFM (parallel - read only) with data in Quartus 2 using the wizard. The generated file does not contain the data

[PWalk14]

Quartus 2 v13.0.1 SP1

Megawizard generating parallel UFM

I want to load the UFM in a EPM240 CPLD with data to be used for a look-up table.

I have finally found the required format (Tab delimited) to load it into 'Hexadecimal(Intel format) File' and have created a file with apparently 1 byte per line (1024 of them + file end).

(Could intel format files with 32bytes per line which I can create elsewhere be used?)

Trying to use the Megawizard to generate a .vhd file incorporating the data from the .HEX file seems to not work. What seems to be the memory blocks in the .vhd file are all '1's in one block and '0's in the other.

The top of the file is:

-- megafunction wizard: %ALTUFM_PARALLEL%

-- GENERATION: STANDARD

-- VERSION: WM1.0

-- MODULE: ALTUFM_PARALLEL

-- ============================================================

-- File Name: BLU_New.vhd

-- Megafunction Name(s):

--         ALTUFM_PARALLEL

--

-- Simulation Library Files(s):

--         maxii

-- ============================================================

Near what I take to be the memory definitions I see:

above the first (all '1's)

'INIT_FILE   :   STRING := "UNUSED";'

[ 16 lots of 512bits ]

 and above the second (all '0's).

'INIT_FILE => "KBReader.hex",' (The file I had specified in the wizard)

[ 16 lots of 512bits ]

Near the end of the file I see:

-- Retrieval info: CONSTANT: INTENDED_DEVICE_FAMILY STRING "MAX II"

-- Retrieval info: CONSTANT: LPM_FILE STRING "KBReader.hex"

-- Retrieval info: CONSTANT: LPM_HINT STRING "UNUSED"

-- Retrieval info: CONSTANT: LPM_TYPE STRING "altufm_parallel"

Is this correct operation and is there something else needed to be done to get the data in the right place?

Thank you (hoping this is the right place)

(Can't seem to upload relevant files - sorry)

[Rahul_S_Intel1]

Hi ,

May I know which file you take it as reference for the above code

[PWalk14]

Thanks for the reply.

The file from which these are extracted is 'BLU_New.vhd' size ~41k which appears after the wizard has run.

(There is also a small 'BLU_New.qip' file containing:-

set_global_assignment -name IP_TOOL_NAME "ALTUFM_PARALLEL"

set_global_assignment -name IP_TOOL_VERSION "13.0"

set_global_assignment -name VHDL_FILE [file join $::quartus(qip_path) "BLU_New.vhd"]

set_global_assignment -name MISC_FILE [file join $::quartus(qip_path) "BLU_New.bsf"]

set_global_assignment -name MISC_FILE [file join $::quartus(qip_path) "BLU_New_inst.vhd"]

set_global_assignment -name MISC_FILE [file join $::quartus(qip_path) "BLU_New.inc"]

set_global_assignment -name MISC_FILE [file join $::quartus(qip_path) "BLU_New.cmp"]

and

'BLU_New_inst.vhd' file containing :-

BLU_New_inst : BLU_New PORT MAP (

      addr   => addr_sig,

      nread   => nread_sig,

      data_valid   => data_valid_sig,

      dataout   => dataout_sig,

      nbusy   => nbusy_sig

   );

also BLU_New.bsf, BLU_New.cmp and BLU_New.inc

generated by the wizard

)

I would have uploaded all these but the website would not accept a '*.zip' file.

(Also could not access the info as to what was allowed - got a site error message)

My input file is 'KBReader.hex' (~16k) generated from the 'File' menu as recommended.

This is intel HEX format with 1 byte per line and does contain the reqired data.

(I tried with an independently generated HEX file with 32 bytes per line without apparent success but maybe just the same as now)

The HEX file is referenced in the 'BLU_New_inst.vhd' file above the second block of '0's as noted originally and near the end as a comment.

I'm just a bit reluctant to instatiate the rest of the code until reasonably sure the memory loading will succeed.

If this approach is possible it will allow the use of the smallest device instead of requiring the next size up ( and leaving the UFM unused)

Hope that is sufficient.

Phil

[Rahul_S_Intel1]

Hi Phil ,

I was looking your code, and also I m trying to get a help from the configuration expert. Please allow me some time

[JohnT_Intel]

Hi,

May I know which Quartus version are you using? Could you share with me your Quartus rpt file which is generated after Quartus compilation? Please also share with me your .hex file and exact device that you are using so that I can help to generate the file to see if I am able to observed the same issue.

[PWalk14]

from first message:

Quartus 2 v13.0.1 SP1

EPM240 CPLD

============

Exact device intended: EPM240T100C5

I don't have a .rpt file yet as I would have to generate the complete design for that.

My query is just about the file which is supposed to load the UFM area.

If that is not correct then doing the whole design would be a waste.

I already know I can do it with logic apart from UFM but that requires a larger device.

The .HEX file is then input to the:

'Megawizard Plug-in Manager'/Memory compiler/ALTUFM Parallel

which generates the 41k main output and collection of other files

My data (in intel format but 32 bytes/line)

(Don't know if site will like the 1byte/line >1000 lines)

:2000000000001919000000001313111112121C1C00001A1A18181616000009096000000008

:2000200000000000000000000000715131210000000000007A5A735361417757322200004E

:2000400000006343785864446545342433230000000020207656664674547252352500008C

:2000600000006E4E6242684867477959365E0000000000006D4D6A4A75553726382A000065

:2000800000002C3C6B4B69496F4F30293928000000002E3E2F3F6C4C3B3A70502D5F0000C5

:2000A00000000000274000005B7B3D2B00000000000000000D0D5D7D0000000000000000A7

:2000C0000000000000000000000000000808000000003131000034343737000000000000D8

:2000E00030302E2E3232353536363838030C00001B1B2B2B33332D2D2A2A39390000000079

:200100000000000000001717FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCA

:20012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0

:20014000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0

:20016000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0

:20018000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80

:2001A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60

:2001C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40

:2001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20

:00000001FF

I'll reply separately to try uploading the 1byte/line version generated by

the 'File/New/Hexadecimal(intel format)file' process.

Phil

[PWalk14]

Trying 1 byte per line as generated by 'File' process:

Firstly try to attach .hex file - seems to have worked so here it is

Phil

[JohnT_Intel]

Hi,

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

[PWalk14]

Many thanks for your reply JohnT.

The response you quote makes some sense.

Indeed the memory width required is 16bits x 512 locations and is what I want.

The zip file in my last post is that resulting from the 'File' process and possibly should have contained 2 bytes per line if correctly formatted ( and I'm guessing here - Address should be by word? -I could generate that by other means if required)

The data I generated it from was in 16bit tab separated format but the result was as shown.

I don't think I had an option for anything other than 16 bit when I generated that file but subsequent attempts have shown an 8 bit option (after the program has been shut down and re-opened).

(I would have expected something like the warnings you saw from the wizard when generating the 41k file and not have to wait until compilation - I saw nothing AFIK)

I will pursue this further as soon as I can (~2days) 

Many thanks

Phil

[PWalk14]

Just 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

[PWalk14]

Just 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

[JohnT_Intel]

Hi Phil,

May I know if you have any other issue regarding this memory initialization issue?

[PWalk14]

( I tried to send this as a reply to the email but it wouldn't go - some sort of Authentication error)

Many thanks for your interest and the pointers (error messages) to where my problem lay.

I had not wished to go fully to design compilation and was only examining the .vhd file.

After your message I carefully reconstructed the .vhd via the 'File' and wizard using a new tab delimited source.

On close examination of the resulting .vhd I was more optimistic of the outcome and generated a bare-bones project.

This compiled without error (a few warnings mostly expected) so I am happier to proceed.

I must now implement this with the rest of my design - may take a while.

If successful I hope to have some space left to add another design to the same device but just getting this design in a smaller device would be good. (The bare-bones does seem to need quite a lot of other resources)

To summarise : I think my main problem was trying to make sense of the rather sparse instructions as to how to generate the source file and lack of error messages up to the stage I got to. ( My original source was two blocks of 8bit data which I had to process using Excel and Notepad both to merge and format - once I knew what the required format was! - lots of search and replace)

I'm still not sure of the first block of '1's in the .vhd file but I may not need to know.

If I will have problems later I don't know but many thanks for your help to now.

Phil

[JohnT_Intel]

Hi,

I would recommend that you follow the memory block that you initiated in order to create the mif or hex file so that it is able to initiate into the memory block correctly.