MAX 10 flash controller wrapping mode - non-functional

[foft]

I've been using the MAX 10 internal flash with success on the 10M08SCU169.  I am not using bursts.

I ran out of space on the device and was looking for ways to reduce my resource usage. The IP for the flash access is very large. So much that it is really impractical to use at all on the smaller 10M02, at least if ones own ip is wanted as well!

I found a post that the utilization can be cut a bit by changing from incremental to wrapping burst mode. Since I'm not using bursts I thought this was an easy way  to save some space easily. It all synthesized fine, however reads no longer worked. I verified on the signaltap logic analyzer that the inputs are provided correctly but still nothing other than 0 s returned from the ip.

I thought that using burst size of 1 was no supported, I changed it to 2 with on improvement.

Has anyone managed to get the internal flash ip to work with wrapping mode and, if so, what is the trick?

Has anyone attempted to write a replacement version of the ip, that works better without such high resource utilization? 

[foft]

Adding a link to where I saw the logic element utilization notes on incremental vs wrapping:

https://community.intel.com/t5/Programmable-Devices/Max10-on-chip-flash-UFM-resource-utlisation/m-p/265620

Also I saw a typo in my message, it should read:

"I thought that perhaps using burst size of 1 was not supported, I changed it to 2 with no improvement."

[foft]

I forgot to include software versions.

I am running Quartus Lite 20.1.1 under Ubuntu 20.04.1 LTS. I have regenerated the ip this version.

A signal tap capture in vcd format is attached. As can be seen an address and request is provided by the data read stays at ffffffff. I verified that the flash has content, if I flash a sof in incremental mode it works.

So read data valid goes high, but no data...

[foft]

I switched back to incremental mode and found that it no longer works on the latest ip either! However diffing the file I see this fix is not applied. It is also conspicuously within a burst mode=0 section, which leads me to believe there might be an equivalent needed for when burst mode is enabled.

https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/solutions/rd10162015_230.html

[JohnT_Intel]

Hi,

Could you share with me your IP setting and maybe your Quartus design?

[foft]

Hi John.

Thanks. Here is my flash_controller that wraps the intel flash ip. I've also included the flash ip itself so you can see the settings that I'm using, along with how I applied the knowledge base patch I mentioned above. That patch seems to still be required in Quartus 20.1.1, although I do see changes to the ip since the Quartus 19.1 version.

I have several clients who can read-write and I process them in round robin fashion. The two clocks are because I run the flash controller at 2x my system clock to get fast access.

If you use the controller to debug, set one of the addr inputs, leave request high, write_n high, addr_config low. Supply a clock and that should be enough.

Would be great to be able to use the lower level access at altera_onchip_flash_block directly if there is documentation on this. 

Thanks,

Mark

[foft]

Here is a very minimal project to illustrate the problem.

Extract the tar and run ./build.sh to build two identical examples.

I didn't use any external pins and used the internal oscillator to ease running on your max10.

[foft]

I should note identical examples except for burst or incremental mode. Incremental mode works but burst mode does not.

There is a signaltap included in order to inspect the results.

[JohnT_Intel]

Hi,

I am not able to compile your design. Could you provide me the testing result of the STP file?

[foft]

OK, here are the compiled projects.

Note for if you recompile it: I was scripting the convert programming files to add the hex file to the UFM. 

I'll send signal tap traces in a subsequent message.

[foft]

Here are the captures from signal tap as standard vcd files.

[foft]

With burst wrapping mode:

With burst incremental mode:

  

[foft]

Note I ran signal tap in transitional mode, I think when exporting as vcd it does not understand the clock timing.

[foft]

Though look at avmm_data_readdata, it should be 0x400 since I stored the address of each location in the flash.

[JohnT_Intel]

Hi,

From the screenshot provided, you are using burst count of 1 while the wrapping mode only support burst count of 2. Could you check if the issue is fixed if you are using burstcount of 2?

Please also check if the issue occur if you are using external CLK?

[foft]

I thought it may be the burst count too so tried that before, but changing that to "10" in the controller does not help.

I'm using an clock from the pll on my real project, I just used the internal oscillator here so that you can run on your own max10 hardware to try it.

[foft]

Here they are with burst 2

[foft]

Wrapping

Incremental

  

[JohnT_Intel · Accepted solution]

Hi,

From the SIgnalTap, I observed that you only provide read signal for 1 clock cycle when you are using burst count of 2. I would recommend you to provide read signal at least 2 clock cycle when you are using burstcount of 2 in wrapping mode.

Please refer to Figure 18 in https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/max-10/ug_m10_ufm.pdf

[foft]

Fantastic that works.

Regarding that patch I applied to the ip, is that still needed? Perhaps that was related to not holding the read long enough as well. Since the avalon mm says it snaps the address on the first cycle I had assumed it also snapped read too.

incremental:

wrapping: 

[foft]

I just noticed that leaving the read high until 'read data valid' causes a duplicate second read on the incremental case.