MAX 10 flash controller wrapping mode - non-functional

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?

JohnT_Altera
5 years ago
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

24 Replies

JohnT_Altera
Regular Contributor
5 years ago
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
  Occasional Contributor
  5 years ago
  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
    Occasional Contributor
    5 years ago
    I just noticed that leaving the read high until 'read data valid' causes a duplicate second read on the incremental case.
foft
Occasional Contributor
5 years ago
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
  Occasional Contributor
  5 years ago
  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...
  flashipbug_20.1.1.vcd.7z6 KB
  - foft
    Occasional Contributor
    5 years ago
    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_Altera
Regular Contributor
5 years ago
Hi,

Could you share with me your IP setting and maybe your Quartus design?
- foft
  Occasional Contributor
  5 years ago
  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
  flash_for_intel.tar.gz39 KB
  - foft
    Occasional Contributor
    5 years ago
    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.
    minimal_flash.tar.gz150 KB
JohnT_Altera
Regular Contributor
5 years ago
Hi,

I am not able to compile your design. Could you provide me the testing result of the STP file?
- foft
  Occasional Contributor
  5 years ago
  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.
  minimal_flash_compiled.tar.gz22.7 MB
  - foft
    Occasional Contributor
    5 years ago
    Here are the captures from signal tap as standard vcd files.
    minimal_flash_capture.tar.gz29 KB
JohnT_Altera
Regular Contributor
5 years ago
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
  Occasional Contributor
  5 years ago
  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
    Occasional Contributor
    5 years ago
    Here they are with burst 2
JohnT_Altera
Regular Contributor
4 years ago
Hi,

I am glad that the solution provided works.
JohnT_Altera
Regular Contributor
4 years ago
Hi,

I am glad that the solution provided works.