lpm_hint

I think its an old thing that looks like it's dissapearing.

IIRC, you used to have to use LPM_HINT on the DC/SCfifo to pass through memory paramters. But those paramters are part of the fifo params now.

its also becoming less of an issue now that inference is so prevalent, and there is much less need to use the basic megafunctions. Plus the synthesisor is getting much better at working stuff out for you.

Actually, this question raised because I am trying to generate an altsyncram and there are parameters I dont understand in the component instanciated:

--- Quote Start ---

lpm_hint => "ENABLE_RUNTIME_MOD=NO",

--- Quote End ---

So I looked the entity into the file /opt/altera10.1/quartus/eda/simlib/altera_mf.vhd, and there are few parameters I don't get either:

- sim_show_memory_data_in_port_b_layout

- init_file_layout

Do you know these?

Thx

also, I see both a parameter "byte_size" and parameters "width_byteena_a" and "width_byteena_b".

Shouldn't "width_byteena" be computed out of "width" and "byte_size", (or, on the contrary, "byte_size" be computed out of "width" and "width_byteena") ?

Or should I just specify all of them, in coherence?

There seem to be more paramters in the Altera Help than in the User guide. For INIT_FILE_LAYOUT:

--- Quote Start ---

Specifies the layout port used with the initialization file. Values are "PORT_A", "PORT_B", and "UNUSED". If omitted, the default is "UNUSED". If the OPERATION_MODE is set to "DUAL_PORT" mode, the default value is "PORT_B". If the OPERATION_MODE is set to other modes, the default value is "PORT_A".

--- Quote End ---

There are not that many paramters that are required. Ususally I just omit anything I dont want to mess with specifically.

Is there any reason you're using the mega-wizard and not using infered ram? Afaik, the only RAM you cannot infer is mixed-width true dual port dual clocked ram, or changing to write-before-read behaviour (this is annoying, because although a shared variable would allow you to do this, altera just infers read-before-write regardless. X does it properly). You can use attributes to specify some of the paramters like RAMSTYLE and init_files.

No, I just want to generate a simple 1 read/write port synchronous ram :)

But the usage in my company is to instanciate LPMs for FIFOs, RAMs, ROMs, multipliers, etc.

So I used megawizard, and even if the generated RAM works well, I am curious so I try to understand all the parameters :)

for anything you cannot find, or get a reply to here, I suggest opening a mysupport case.

The megafunctions are quite old in some cases, and in most cases have to support a wide range of devices, hence the wide range of parameters. So parameters keep getting added, when usually its usually better to let the synthesisor do most of the work picking paramters.

OK

Thx

P.S: when you talk about 'using infered ram', you mean declaring an array of std_logic_vector (for instance) and let the synthesizer implement it with a RAM block in the FPGA, right?

basically yes - assuming to follow the templates correctly for accessing that ram.

Its actually very good now. Ive had infered rams from arrays of unsigned, signed, sfixed and integer types without problems. I even messed around and used a character type as the address input and it infered a ram!! Means I dont have to keep converting to std_logic_vectors all the time!

cool :)

(But it will take me forever to convince people here ^^)