| |
 Время записи nand flash |
|
|
|
 |
Ответов
(1 - 7)
|
|
 Oct 31 2012, 11:51
|
Местный
Группа: Свой
Сообщений: 377
Регистрация: 23-12-06
Из: Зеленоград
Пользователь №: 23 811
|
Цитата(Sergey_Bekrenyov @ Oct 31 2012, 14:14)  Micron пишет 230-500 мкс на запись страницы, стирание 700 мкс. Стирание это установка всех битов в 1. Максимальное время записи зависит от количества нулей в информации? Потребление зависит от количества нулей, а время записи не должно, хотя есть небольшие флуктуации около среднего значения, но не думаю, что это связано с количеством нулей.
|
|
|
|
|
|
|
|
Nov 1 2012, 04:55
|
Местный
Группа: Свой
Сообщений: 323
Регистрация: 14-12-10
Из: Королёв
Пользователь №: 61 599
|
Цитата(Mad_max @ Oct 31 2012, 22:10) Я прогонял весь чип и фиксировал время записи каждой страницы, и по 262144 измерениям строил гистограмму.
Получилась хорошая гауссина с центром в районе 230-240 мкс.
Были единичные выбросы в сторону увеличения время записи, но ими можно пренебречь.
Завтра посмотрю, может быть картинка сохранилась.
Так что смело можно закладываться на 240 мкс. У нас получилась пропускная способность на single-plane чуть более 700Mbps, на two-plane более 1Gbps.
Посмотрите еще в интернете research papers на эту тему. Для micron был paper, где говорилось, что
с износом увеличевается время стирания, а время записи как раз уменьшается. Спасибо, я поищу. А что у Вас по битым блокам получилось? У меня пока картинка не складывается - то ли это только биты будут невалидные, то ли можно получить ошибку записи/чтения/стирания целой страницы. ECC делали? Цитата(Flood @ Oct 31 2012, 22:24) Всегда имеет смысл закладываться на макс. время, указанное в спецификации. Может быть, сейчас в реальности 250 мкс, а через 1000 стираний станет 550 мкс.
Зачем пытаться обмануть даташит? Вы абсолютно правы, буду строить из расчета 500 мкс. Будет несколько сложнее, но это уже вопрос времени
|
|
|
|
|
|
|
|
Nov 1 2012, 09:12
|
Местный
Группа: Свой
Сообщений: 377
Регистрация: 23-12-06
Из: Зеленоград
Пользователь №: 23 811
|
Цитата(Sergey_Bekrenyov @ Nov 1 2012, 08:55) Спасибо, я поищу. А что у Вас по битым блокам получилось? У меня пока картинка не складывается - то ли это только биты будут невалидные, то ли можно получить ошибку записи/чтения/стирания целой страницы. ECC делали? По "плохим блокам" для micron картина следующая. Есть блоки помеченные производителем как "плохие", соответствующие маркера они ставять в spare область. Эти блоки (все страницы) при чтение всегда возвращяют нули, причем при стирании такого блока в статусе возвращяется бит ошибки, а при записи нет, то-есть как-будто бы запись прошла успешно. С этими блока ничего не поделаешь их надо держать в "таблице плохих блоков" и обходить при работе. По даташиту количество "плохих блоков" не превышает 2% от общего количества. Но на деле их гораздо меньше. У нас в изделие массив из 128 микросхем. Анализ на "плохие блоки" по N изделиям показал, что на весь массив количество таких блоков от 6 до 20. То-есть достаточно большой процент микросхем вообще не содержит "плохих блоков". Что, кстати, выгодно отличает micron от samsung. В процесе эксплуатации могут появляться новые "плохие блоки". На износ мы тестов не ставили, но по логике операции стирания/записи должны возвращять ошибки. Так что "таблица плохих блоков" должна быть живая и обновляться с появлением новых блоков. Тут можно делать по разному, к примеру, сначала помечать блок как "подозрительный", если ошибки повторяются на этом блоке, то уже заносить в таблицу. Помимо "плохих блоков" есть битовые ошибки. Тут наоборот samsung показывал лучшие результаты. На 128 микросхем 5-6 битовых ошибок. У micron на 128 микросхем 500-1000 битовых ошибок. Здесь уже без ECC не обойтись. У нас используются коды Хэмминга.
|
|
|
|
|
|
|
|
Nov 1 2012, 12:58
|
Местный
Группа: Свой
Сообщений: 323
Регистрация: 14-12-10
Из: Королёв
Пользователь №: 61 599
|
Цитата(Mad_max @ Nov 1 2012, 13:12) По "плохим блокам" для micron картина следующая. Есть блоки помеченные производителем как "плохие", соответствующие маркера они ставять в spare область. Эти блоки (все страницы) при чтение всегда возвращяют нули, причем при стирании такого блока в статусе возвращяется бит ошибки, а при записи
нет, то-есть как-будто бы запись прошла успешно. С этими блока ничего не поделаешь их надо держать в "таблице плохих блоков" и обходить при работе.
По даташиту количество "плохих блоков" не превышает 2% от общего количества. Но на деле их гораздо меньше. У нас в изделие массив из 128 микросхем.
Анализ на "плохие блоки" по N изделиям показал, что на весь массив количество таких блоков от 6 до 20. То-есть достаточно большой процент микросхем вообще не содержит "плохих блоков". Что, кстати, выгодно отличает micron от samsung.
В процесе эксплуатации могут появляться новые "плохие блоки". На износ мы тестов не ставили, но по логике операции стирания/записи должны возвращять
ошибки. Так что "таблица плохих блоков" должна быть живая и обновляться с появлением новых блоков. Тут можно делать по разному, к примеру, сначала помечать блок как "подозрительный", если ошибки повторяются на этом блоке, то уже заносить в таблицу.
Помимо "плохих блоков" есть битовые ошибки. Тут наоборот samsung показывал лучшие результаты. На 128 микросхем 5-6 битовых ошибок.
У micron на 128 микросхем 500-1000 битовых ошибок. Здесь уже без ECC не обойтись. У нас используются коды Хэмминга. Огромное спасибо!!! А что за устройство записи если не секрет. Может присоветую знакомым для покупки и применения. А может и сам применю где Кстати если при записи возвращается ошибка - эти данные из регистра данных или кэша можно записать в другую область или надо заново записывать в микросхему?
|
|
|
|
|
|
|
 |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
