S29GL01GP11FFI020 Programming Speed Slow and Random

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

We have been using the S29GL01GP11FFI020 and S29GP0512P11 Flash Memory chips since about 2008. We have a lot of experience with them and have shipped a large number of products with them.

   

I have been trying to speed our product up, and have been taking detailed measurements of the programming speed.

   

Which is given in the Data Sheet as "Typ 60us for one word" and "480us for 32 words for Write Buffer Programming".

   

I'm measuring the chips as being nearly three times slower for single word writes, and 2.4 times faster for Write Buffer operations than those figures, and would like to understand why.

   

The terminology I'm using below is complicated by our having two FLASH chips in parallel across a 32-bit bus. We're programming them in parallel and monitoring the RY/BY#" pin for completion. So when I write "4 bytes", they're being written as two 16-bit words into the two chips at the same time with the same operation. The "32-word Write Buffer" operation writes 128 bytes.

   

I've compared single writes and "Write Buffer" operation writing a single word and they seem to take about the same time. It doesn't seem to take longer to program "a buffer with only one valid word in it" than a single word.

   

Our hardware has a dedicated microsecond counter in the CPU, and I'm disabling all interrupts while taking the following measurements. The first column is a timestamp in seconds and milliseconds. The "764" is the line in the code that is printing. "4" is the number of bytes written (as a single 32-bit write into the two chips in parallel). "A:Bus" means is took "A"us to write the commands and data into the chips, and then it took "B"us until they signaled "Ready".

   

014.418 flash_write_page:764 4 4:142us
014.498 flash_write_page:764 4 2:77us
014.578 flash_write_page:764 4 2:143us
014.658 flash_write_page:764 4 4:159us
014.738 flash_write_page:764 4 4:142us
014.818 flash_write_page:764 4 2:159us
014.898 flash_write_page:764 4 3:159us
014.978 flash_write_page:764 4 2:160us
014.978 flash_write_page:764 4 3:76us
015.058 flash_write_page:764 4 4:161us
015.138 flash_write_page:764 4 3:176us
015.218 flash_write_page:764 4 2:160us
015.298 flash_write_page:764 4 2:159us
015.378 flash_write_page:764 4 2:159us
016.018 flash_write_page:764 8 4:175us
016.018 flash_write_page:764 4 3:142us
016.098 flash_write_page:764 4 3:175us
016.178 flash_write_page:764 4 3:158us
016.258 flash_write_page:764 4 2:176us
016.338 flash_write_page:764 4 3:161us
016.418 flash_write_page:764 4 3:172us
016.498 flash_write_page:764 4 3:158us
016.578 flash_write_page:764 4 4:158us
016.658 flash_write_page:764 4 3:175us
016.738 flash_write_page:764 4 3:175us
016.818 flash_write_page:764 4 3:159us
016.898 flash_write_page:764 4 3:159us
016.978 flash_write_page:764 4 4:155us
017.058 flash_write_page:764 4 2:143us
017.138 flash_write_page:764 4 2:175us
017.218 flash_write_page:764 4 3:142us
017.298 flash_write_page:764 4 2:143us
017.378 flash_write_page:764 4 3:142us
017.458 flash_write_page:764 4 3:142us
017.538 flash_write_page:764 4 3:174us
017.618 flash_write_page:764 4 3:177us

   

It gets down to 76us (close to 60us, but still more than that) sometimes. In 576 writes, it only managed around 70us 9 times. That's 1.6%. The rest of the time it averaged around 160us.

   

Checking the data written, it seems to manage "76us" about half the time when writing all zeros, and always takes a lot longer for other numeric values (with more ones-bits in them).

   

Does the programming time depend on the number of ones and zeros in the data being written?

   

Since I've got two chips in parallel, I'm measuring the time to the slowest of the two chips. It only manages to be "fast" when both chips are "fast".

   

Here's how long it takes to write 128 bytes (full 32-word Write Buffer). The last three values printed are the last words written into the Flash. For this test it is mainly writing all-zeros. It is always a LOT faster than the specified 480us:

   

004.245 flash_write_page:764 128 10:187us 0 0 0
004.248 flash_write_page:764 128 10:166us 0 0 0
004.248 flash_write_page:764 128 10:195us 0 0 0
004.250 flash_write_page:764 128 10:235us 0 0 0
004.255 flash_write_page:764 128 10:221us 0 0 704
004.258 flash_write_page:764 128 10:210us 0 0 46137344
004.259 flash_write_page:764 128 10:160us 0 0 0
004.261 flash_write_page:764 128 11:168us 0 0 40173568
004.264 flash_write_page:764 128 10:206us 0 0 0
004.267 flash_write_page:764 128 10:205us 0 0 0
004.267 flash_write_page:764 128 10:204us 0 0 0
004.271 flash_write_page:764 128 10:160us 0 0 0
004.274 flash_write_page:764 128 11:196us 0 0 0
004.278 flash_write_page:764 128 10:237us 586 0 0
004.279 flash_write_page:764 128 10:176us 0 0 0
004.281 flash_write_page:764 128 10:164us 0 0 0
004.284 flash_write_page:764 128 10:163us 0 0 704
004.287 flash_write_page:764 128 11:221us 0 0 0
004.287 flash_write_page:764 128 11:200us 0 0 0
004.291 flash_write_page:764 128 11:191us 0 0 0
004.293 flash_write_page:764 128 11:198us 0 0 0
004.293 flash_write_page:764 128 10:166us 0 30736384 0

   

Can anyone help me with explaining and understanding this variability?

   

Thanks,

   

Tom

   


 

0 Likes
1 Solution
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi Tom,

   

Thanks for the details explanation. I don't think there are significant time differences in programing with different data patterns. 

   

It seems to me that you want to acquire more information about how the typical timing parameters in the datasheet are derived. If you open a case and ask for QDB (Qualification Database) for this part, you will see how we define the typical times. 

   

My hypothesis for the variance you were observing is relating to the interleaving configuration. We know even with the same Flash, with the same second, two operations may result in different times. This is just the nature of the operation. By measuring the slower device for each operation, you will get much bigger variances when the elapse time is shorter. If the operation elapse time is naturally longer, the variance caused by the slower device is much less. Of course, this does not explain why the WB programming time is 3x faster than the datasheet number. I don't know the reason yet.

   

After you get the QDB, if you have more questions, we can certainly discuss further.

   

Best regards,

   

Zhi

View solution in original post

0 Likes
8 Replies
Anonymous
Not applicable

Hi Tom,

   

Q) Does the programming time depend on the number of ones and zeros in the data being written?

   

A) On higher level,the unprogrammed state of a flash memory cell is a high signal level or logical one. Changing a flash memory cell (or bit) to a low voltage level or zero is called programming. One key point to note is that programming only changes ones to zeros.

   

 chip or sector erasing is changing zeros to ones. So if you want to change zero to one you need to erase and program so it will might take more time.

   

Thanks,

   

Krishna.

0 Likes
AlbertB_56
Moderator
Moderator
Moderator
500 replies posted 50 likes received 250 replies posted

Hello Tom,

   

In addition to either Sector Erase and Chip Erase operation, any bits that have the value of "ONE" will be pre-programmed

   

to "ZERO"; then (sector or chip) erased back to a "ONE'.  The Pre-Programming Time is identical to that of the Program Time.

   

The Pre-programming algorithm, which occurs first, is within the Sector or Chip Erase operation and is transparent to the end user,

   

and cannot be altered or disabled.  If any Sector is set as protected, the specific protected sector will be bypassed and not erased.  

   

 

   

Thank you and regards,

   

Albert

0 Likes
Anonymous
Not applicable

Krishna and Albert, thanks for posting, but your responses don't address my questions at all. The answers seem like a cut-and-paste after a cursory "pattern match" of words in my post.

   

> Q) Does the programming time depend on the number of ones and zeros in the data being written?

   

Are you asking me that question, or are you pasting in part of a FAQ Q & A?

   

The "A" you give to the above "Q" is:

   

> A) On higher level,the unprogrammed state of a flash memory cell is a high signal level or logical one. Changing a flash memory cell (or bit) to a low voltage level or zero is called programming.

   

That doesn't answer the question. It doesn't say if the programming time depends on the number of ones and zeros.

   

I wrote that the programming time DID seem to depends on that, and wanted to know why. The rest of your post is "Flash programming 101". I said in my post that we have a lot of experience. I've been writing code to program Flash chips for at least 15 years, probably more.

   

Albert, your post is on erasing Flash and the pre-programming. I don't care about that. My problems are with the variable Word and Buffer PROGRAMMING times, and my questions are solely related to that.

   

I'll repeat the summary-question from my original post:

   

I'm measuring the chips as being nearly three times slower for single word writes, and 2.4 times faster for Write Buffer operations than those (Data Sheet) figures, and would like to understand why.

   

I would like to get the speeds quoted in the Data Sheet. Is the Data Sheet wrong maybe?

   

Thanks,

   

Tom

0 Likes
Anonymous
Not applicable

Hi Tom,

   

Q) Does the programming time depend on the number of ones and zeros in the data being written?

   

A) Yes it depends on the number of ones and zeroes. Programming 1's to the locations which has 0s earlier will take more time rather than programming 1s to 0s. For ex : converting 7 (0111) to 5 ( 0101) you need to make 2nd LSB bit 0 from 1 which is faster. Where if 7 needs to be converted to 8 (1000) will take more time as the MSB bit needs to be converted to 1 from 0 and the remaining bits tp 0 from 1. 

   

Hope the above example is useful.

   

Regarding speeds mentioned in the datasheet I am not too sure how it is measured. I will check internally and will update you.

   

Thanks,

   

Krishna.

0 Likes
Anonymous
Not applicable

> Programming 1's to the locations which has 0s earlier will take more time rather than programming 1s to 0s.

   

I'm using NOR FLASH and the bits can ONLY be Programmed from ones to zeros. They CAN NOT BE Programmed the other way. You may be thinking about a different type of memory, like an EEPROM.

   

The whole flash block has to be erased (taking about 0.5 seconds) back to all-ones in order to make a single bit change from zero to one. I don't consider that to be part of "programming a bit". The Data Sheet is pretty clear about separating these operations too.

   

If you're writing very high-level code through a driver that takes care of this for you, then yes; "writing one to zero" should take 60us, but "writing zero to one" will take 500,000us. That's four orders of magnitude longer, and not the same sort of operation.

   

Tom

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi Tom,

   

Firstly, can you clarify what commands you were using to do the experiments? When programming a single word, do you use Single Word Programming command or still use Write Buffer Programming command sequence?

   

Secondly, to get a better understanding of the performance number, can you repeat your test with only one device, instead of interleaving configuration to measure the time? You may still program to both devices but only monitor RY/BY# pin from one. That way it may give more accurate result.

   

BTW, as you can see from the datasheet, the 60us single word programming, 480us WB programming times are typical values. It may vary on different devices or ambient temperatures.

   

Thanks,

   

Zhi

0 Likes
Anonymous
Not applicable

> Firstly, can you clarify what commands you were using to do the experiments?

The underlying programming code (our "Flash Driver Code") uses "Write Buffer", even if there's only one word to write. I ran a series of measurements with this, where half of the calls wrote two words and the other half wrote one. I then changed the underlying code so it recognized when only a single word was being written and used "Single Word" programming instead. There were no significant differences between the two tests. I said that in my original post.

The RY/BY# pins from the two chips are bussed together, so I can't monitor them separately. I don't need to.

I can write "half words" through the "Driver" and it will only write to one chip. I can do this fairly easily, but can only get around to that next week.

> It may vary on different devices or ambient temperatures.

Maybe, but that has nothing to do with the same chips giving multiple results different by 200% within the same SECOND. Also with the full "Write Buffer" programming being THREE times faster than the Data Sheet. If my programming time is likely to get three times slower under some circumstances (back to "Typical", or even slower than that), then I'd like to know why and how to avoid that.

You should have lots of test results available to you of all the tests that were run to derive that "60us typical". There must be a lot of documented assumptions behind those tests that just aren't in the Data Sheet. There should also be Minimum and Maximum values. If the writing time is data dependent, then that should be in your internal documentation too.

If you don't have this available, your Technical Support people should be able to run a series of tests fairly easily.

Internally, these chips have to have a "Charge Pump" to generate the programming and erasing voltages. That's obvious from the basic technology, as well as having the "12V Programming Acceleration" mode. I would expect the "Charge Pump" to switch off to save power when not programming. Maybe I'm getting unlucky with my timing and the chip is having to wait for the pump to start up again. There are two "Power Conservation Modes" listed in the Data Sheet. Maybe there are undocumented "power save modes" related to programming and the Charge Pump activation that could explain the figures I'm seeing.

Should I try an open a "Support Case" on this issue instead?

Tom

   


 

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi Tom,

   

Thanks for the details explanation. I don't think there are significant time differences in programing with different data patterns. 

   

It seems to me that you want to acquire more information about how the typical timing parameters in the datasheet are derived. If you open a case and ask for QDB (Qualification Database) for this part, you will see how we define the typical times. 

   

My hypothesis for the variance you were observing is relating to the interleaving configuration. We know even with the same Flash, with the same second, two operations may result in different times. This is just the nature of the operation. By measuring the slower device for each operation, you will get much bigger variances when the elapse time is shorter. If the operation elapse time is naturally longer, the variance caused by the slower device is much less. Of course, this does not explain why the WB programming time is 3x faster than the datasheet number. I don't know the reason yet.

   

After you get the QDB, if you have more questions, we can certainly discuss further.

   

Best regards,

   

Zhi

0 Likes