FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5741 Discussions

MAX 10 flash controller wrapping mode - non-functional

foft
Novice
463 Views

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? 

0 Kudos
1 Solution
JohnT_Intel
Employee
333 Views

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


View solution in original post

24 Replies
foft
Novice
384 Views

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/...

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
Novice
377 Views

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
Novice
375 Views

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/soluti...

JohnT_Intel
Employee
370 Views

Hi,


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


foft
Novice
367 Views

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
Novice
358 Views

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
Novice
357 Views

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
Employee
349 Views

Hi,


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


foft
Novice
344 Views

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
Novice
342 Views

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

foft
Novice
340 Views

With burst wrapping mode:

wrapping_gtkwave_screenshot.png

With burst incremental mode:

incremental_gtkwave_screenshot.png

 

  

foft
Novice
338 Views

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

foft
Novice
337 Views

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

JohnT_Intel
Employee
330 Views

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
Novice
329 Views

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
Novice
322 Views

Here they are with burst 2

foft
Novice
319 Views

Wrapping

wrapping_burst2.png

Incremental

incremental_burst2.png

  

JohnT_Intel
Employee
334 Views

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


View solution in original post

foft
Novice
299 Views

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:

flash_wrapping_hold_read.png

wrapping: 

flash_incremental_hold_read.png

foft
Novice
202 Views

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

Reply