MAX10 UFM writing takes much longer than expected

[Altera_Forum]

Hi Folks, 

 in my design on a MAX10 10m08sau169 I am using the internal user flash UFM to store some data. I am NOT using a NIOS to do the writing through the avalon interface. Instead of this I have instantiated the ufm ip core directly in my design and I drive it from a small state machine that is generating the signals to control the writing to the flash (as well the reading, but this is not the issue here).  To design the state machine, I took my information from here: https://www.altera.com/en_us/pdfs/literature/hb/max-10/ug_m10_ufm.pdf - especially page 13 fig. 8.  At first glance everything seems to work perfectly well: I can erase pages and rewrite them with new content.  The only thing that bothers me is that it is taking *very* *VERY* long to write the flash content: I am writing a block of 8192 32-bit words (in total 32 kBytes) and this is taking over a minute to get written. The UFM user guide tells me that an average write takes 100usecs and a max time of 305usecs per word. That would mean that the memory content should get written within 2.5 seconds. But why does it take one minute in my case?  What I am doing in my state machine is that I am waiting for the waitrequest signal to go low again after I wrote something to the flash. Then the state machine checks the status register and waits until the status register shows that the operation is done (which is usually immediately the case). Then the next word is getting written... . Data is written to increasing addresses - no random access or similar.  I checked the configuration of the IP core and the only thing that I can imagine could affect the timing is the clock of the ufm ip core which I configured correctly to the 80MHz that I am using there.   So what else could be wrong? Or is it simply normal that programming takes so long and the times given in the UFM user guide are simply wrong? The UFM can be written via JTAG in a few seconds so I would say in principle it should run much faster.  Anyone can help???

[Altera_Forum]

I'm using a 10M04DCF256 in a similar setup - no NIOS, just my own logic around the IP core. As it happens, my main clock is also 80MHz. 

 I didn't record the precise numbers, but for debugging I routed the signals of interest out to I/O pins and viewed them with a 'scope - the waitreq was going active for a reasonable amount of time, somewhere around the 100us specified in the manual.  There are a number of minor errors in the documentation - the one which upset my state machine was the fact that waitreq also goes active during a read cycle (fig 10 in the manual says it doesn't!). On the write cycle, fig8 shows the waitreq going active on the same cycle as the write strobe - which is impossible unless there's asynchronous logic (or a time machine) inside the IP core.  So, I agree you ought to be able to write your data in about 1 second. Probably something has gone wrong with your state machine....

[Altera_Forum]

--- Quote Start ---  the one which upset my state machine was the fact that waitreq also goes active during a read cycle (fig 10 in the manual says it doesn't!).   --- Quote End ---    Oh, that would explain something... the state machine is constantly reading data from the flash unless it is explicitly trying to write something. When waitreq goes high for reads as well, I'll have to check if this is causing my state machine to wait endlessly (and then run into a very high timeout I have implemented).   Thanks for helping me out with your experience - I'll check and come back to tell about the result.

[Altera_Forum]

--- Quote Start ---  Thanks for helping me out with your experience - I'll check and come back to tell about the result.  --- Quote End ---    OK, I promissed to come back with the results:   I checked the waitrequest and found that in my case it is actually active for up to 4 milliseconds! :(  So then I put other signals in the write timing chart into question:  In the chart the write signal stays active over the whole process of writing data. I wondered if that was actually required. So what I did was to convert it into a strobe signal that is just active for a single clock cycle just the same way as the control registers gets written.  And Bingo! That seems to solve my problem! :) The whole data is written within one second and it seems that it is realiably flashed into the memory (I have to run more tests to assure that this is actually true). :cool:  So I can only recommend not to follow the Altera flash memory user guide too closely!  edit: the above observation is not entirely true! see my next post below!

[Altera_Forum]

Curious! 

 I also wondered whether it should really be a strobe, but I followed the book and kept my write active until waitreq goes away, and that seems to work for me.

[Altera_Forum]

--- Quote Start ---  Curious!  I also wondered whether it should really be a strobe, but I followed the book and kept my write active until waitreq goes away, and that seems to work for me.  --- Quote End ---    Meanwhile I found out that the problem may also have been caused by my state machine not returning the write signal to inactive one clock cycle after the waitreq goes inactive but some clocks later. Still have to check this, but it would explain the same bug...  So maybe you are right with leaving the write high for the whole duration.  Edit: I confirmed this. It's OK to leave the write signal high and the problem in my case was that I left it high for too long triggering a second write right thereafter. My statemachine sits in an enabled subsystem and therefore does not see every clock cycle. That was causing the issue... :oops:

[Altera_Forum]

I suggest you look at the following link 

 https://www.pulserain.com/m10-high-speed-config  It is an open source solution for config the MAX10 in high speed. It might have what you need.   In particular, look at the TRM https://github.com/pulserain/m10_high_speed_config_rtl/raw/master/docs/m10_high_speed_config_trm.pdf

[Altera_Forum]

If waitrequest is active, you always have to hold all the signals (address, write, writedata on writes; address and read on reads) until the clock cycle after waitrequest is released. See the Avalon spec: 

 https://www.altera.com/en_us/pdfs/literature/manual/mnl_avalon_spec.pdf