FPGA, SoC, And CPLD Boards And Kits
FPGA Evaluation and Development Kits
5924 Discussions

Does the onchip flash IP block take physical degradation into account?

JensVkb
Novice
846 Views

To support remote updating of my MAX10M08 device, I'm using the onchip flash IP block to access the CFM to erase sectors and program the new configuration.

From the user manual https://www.intel.com/content/www/us/en/docs/programmable/683180/18-0/user-flash-memory-overview.html I can see the onchip flash IP block will set the Write Failed bit when

  • The burst count is not equal to 1 (parallel) or 32 (serial). 
  • The given address is out of range.
  • The sector protection mode or write protection mode of the sector is not clear (the value is not 1'b0)

Similarly, the Erase Failed bit is set when

  • You send an illegal sector number
  • The sector protection mode or write protection mode of the sector is not clear (the value is not 1'b0)

Basically, those error flags are set when interacting wrongly with the IP block from VHDL.

Yet, if my device is to operate for multiple years in possibly harsh conditions, the Flash memory itself can also start to degrade, which could also result in failed Write or Erase operations.

Does the IP block take this into account and also set the Failed bit when the physical memory could not execute the desired operation? 

 

 

Or should I take care of this myself, by reading back the sector is completely empty and reading back the address I just programmed?

0 Kudos
1 Solution
ShengN_Intel
Employee
678 Views

Hi FvM,


Thanks for your sharing. Can't deny that readback and compare will be a good measure to ensure data correctness.


What I mentioned previously is just the ws (write successful) and es (erase successful) bits will always show '0' (failed) if the physical memory could not execute the Write or Erase operations properly.


Thanks,

Best Regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.


View solution in original post

0 Kudos
4 Replies
ShengN_Intel
Employee
802 Views

Hi,

 

Definitely, the ws (write successful) and es (erase successful) bits will be always '0' if the physical memory could not execute the Write or Erase operations. You may check the functionality from On-Chip Flash submodules altera_onchip_flash_avmm_data_controller.v check image:

ShengN_Intel_0-1670516288026.png

ShengN_Intel_1-1670516393603.pngShengN_Intel_2-1670516436502.png

So if physical memory fails to execute the Write or Erase operations, the write_timeout and erase_timeout will be '1'. Therefore, csr_status_w_pass and csr_status_e_pass will be always '0'.

 

Thanks,

Best regards,

Sheng

 

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

 

0 Kudos
FvM
Valued Contributor III
714 Views

Hello,
don't believe that you can be sure about correct flash content without actually reading it back.


Firstly, the most likely reason for getting incorrect flash content is data corruption on the transport path. Readback and compare will also reveal this error.


Secondly, I don't see an indication that write success status guarantees correct data. If you think I'm wrong in this point, please refer to the respective product spec.

Best regards
Frank

0 Kudos
ShengN_Intel
Employee
679 Views

Hi FvM,


Thanks for your sharing. Can't deny that readback and compare will be a good measure to ensure data correctness.


What I mentioned previously is just the ws (write successful) and es (erase successful) bits will always show '0' (failed) if the physical memory could not execute the Write or Erase operations properly.


Thanks,

Best Regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.


0 Kudos
JensVkb
Novice
667 Views

@FvM and @ShengN_Intel 

 

Thanks for your answers! Since I only could select 1 as a solution, I just chose the final reply, but both of you helped me out!

 

Good to know there is a link with the physical memory and that, as I suspected too, it doesn't hurt to implement a readback after each write operation.

0 Kudos
Reply