Max10 on-chip-flash (UFM) resource utlisation

[Altera_Forum]

I have instantiated the 'Altera On-Chip Flash' megafunction to access the UFM on a 10M04DCF256 device. 

 1) there seems to be a discrepancy between the documentation and the tools in quartus prime (v7.0.2).  According to the documentation (UG-M10UFM chapter 2), a 10M04 doesn't have UFM0 (it's size zero), and a 'DCF' part (compact) does not have access to any of the CFM sectors regardless of the image type (table 2-3).  However, in the "IP Parameter Editor" tool, if I have 'single compressed image' selected then it insists that I have a second range of UFM in what looks like CFM1 (the address range given is 58kbyte long, matching the 29 pages of CFM1). It won't let me have this as hidden, so it bloats the address bus to address all of this extra memory that I'm not sure is really qualified for use on a 'DCF' part.   2) the megafunction is rather large - synthesises to 536 LEs (not including my own logic to interface with it), that's over 13% of the entire device:  |flash:ufm0| 536 (0) 268 (0) |altera_onchip_flash:onchip_flash_0| 536 (0) 268 (0) |altera_onchip_flash_avmm_csr_controller:avmm_csr_controller| 57 (57) 33 (33) |altera_onchip_flash_avmm_data_controller:avmm_data_controller| 479 (417) 235 (199) |altera_onchip_flash_a_address_write_protection_check:access_address_write_protection_checker| 3 (3) 0 (0) |altera_onchip_flash_convert_address:address_convertor| 35 (35) 0 (0) |altera_onchip_flash_convert_sector:sector_convertor| 1 (1) 0 (0) |altera_std_synchronizer:stdsync_busy_clear| 2 (2) 2 (2) |altera_std_synchronizer:stdsync_busy| 2 (2) 2 (2) |lpm_shiftreg:ufm_data_shiftreg| 32 (32) 32 (32)   I had expected that most of the flash management logic would be 'hard' and the megafunction would just be a shim to the hardware. Suspicious in that listing is lpm_shiftreg:ufm_data_shiftreg since I'm using the parallel interface - is the underlying hardware serial and lots of LEs being wasted here to construct a parallel bus to it?  Has anybody experimented with the different options to know what affects the size? It would be a fair bit of work for me to re-build my logic for the serial-interface option to the megafunction, but I could do if it is worth it.

[Altera_Forum]

Partly answering my own question: 

 Re-configuring the main project to single-uncompressed-image and then re-generating the module makes a modest saving (down from 536LE to 492), reducing the address bus from 15 bits to 12.  Changing read-burst-mode from "incrementing" to "wrapping" made a more significant difference - from 492LE to 410LE. This is somewhat surprising as I'd already configured the minimum burst size (2) and had hard-wired avmm_data_burstcount => "01" in the hope that this would cause logic related to burst count to get optimised away.   There's loads of minor errors in the documentation, for example the timing diagrams for simple read show the waitreq signal never going active (actually it does) and the one for wrapping burst implausibly shows waitreq going active on the clock before it registers the read request.