Clock enable for MAX V altufm_none ignored in simulation

[Altera_Forum]

Moin, 

 I'm using Quartus II Version 13.0.1 Build 232 06/12/2013 SJ Web Edition with the included ModelSim ALTERA STARTER EDITION 10.1d Revision: 2012.11. My project uses Verilog HDL and is targeting the MAX V device family (device currently set to 5M160ZT100C5). I need to/want to use the MAX V user flash memory, with no interface logic. I haven't done this sort of thing before, so in order to not mess up the clocks (e.g. through the use of combinatorial logic in the clock path) I want to use the clock enable functionality of the UFM block (both for data and address clocks).  I have used the MegaWizard Plug-In Manager (Quartus II menu "Tools"), selected to create a new custom megafunction variation, choose ALTUFM_NONE, MAX V device family, Verilog HDL output. In the parameter settings I ticked both »Use 'arclkena' input port« and »Use 'drclkena' input port« and selected to initialize the memory content from a provided HEX file. After completing the rest of the code the project compiles fine, but does not work in the simulation. I run simulation using Quartus II menu Tools -> Run Simulation Tool -> RTL Simulation, using a test bench file written in Verilog. (So far I can only really test RTL Simulation since I have an unrelated problem with Gate Level Simulation.)  Investigation reveals that both arclkena and drclkena seem to be ignored in the simulation model. The lower-most simulation entity of type maxv_ufm (from file altera/13.0sp1/modelsim_ase/altera/verilog/src/maxv_atoms.v) contains two wires named "gated_arclk" and "gated_drclk", but these are assigned as follows:  assign gated_arclk = i_arclk & !sys_busy; assign gated_drclk = i_drclk & !sys_busy; In simulation they have the raw, ungated clock input. The maxv_ufm block doesn't even have arclkena/drclkena input ports! Also no gating is done on the higher levels.   I would assume this to be a bug in the software and/or supplied simulation models, correct? Is Altera aware of the problem (I found no reference whatsoever on Google), or whose fault is this?   Will this work in hardware (I don't have a development board yet, but the order is out)?  Is there a recommended workaround? Either simulation only or for both simulation and synthesis.  --  Henryk Plötz Grüße aus Berlin