Качественный (параноидальный) тест ОЗУ

[vlad6502]

На своей Микро-80 столкнулся с трудноуловимой неисправностью 565РУ5 - память без проблем проходила разнообразные тесты: паттерн $55/$АА, walking 0/1, address code (в ячейку записывается ее адрес), полный перебор всех комбинаций ячеек, периодический подсчет CRC для проверки регенерации.
Но на реальной программе - происходил сбой. Дефектную микросхему удалось идентифицировать по изменениям в тексте выдаваемых программой сообщений, но осадок остался...

Посоветуйте алгоритм качественного теста ОЗУ, желательно для процессора 8080.

P.S. на просторах инета нашел интересную работу «Исследование методов проверки работоспособности микросхем памяти РЭА» (http://www.google.com.ua/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CBwQFjAA&url=http%3A%2F%2Flibrary.ziyonet.uz%2Fuploads%2Fbo oks%2F555273%2F54250449e0092.docx&ei=-cWWVMSQCavGygPLkYHwCw&usg=AFQjCNGYd5BUd0Qc19KAq3GL3Z3dn3cbBQ&bvm=bv.82001339,d.bGQ),

[haywire]

Посоветуйте алгоритм качественного теста ОЗУ


Таких нет. Многократно в этом убеждался.

[Mdesk]

? MM @ - 29.12.2012 00:01
Самый вредный и длинный тест ОЗУ:
1.Копируем в А-адрес массив (например, из ПЗУ) длиной Б.
2.Размножаем в ОЗУ вышеупомянутый массив.
3.Сравниваем с Оригиналом.
4.Сдвигаем на 1 бит по всей длине ОЗУ.
5.Сравниваем с оригиналом с бит-поправкой.
6.Повторить циклы сдвиг-контроль много раз.(например, 10000 раз)
7.Не забывать между циклами делать паузу не менее 0.5 с без обращения к ОЗУ вообще (например, какой-либо цикл в ПЗУ).
8.Считается, что такой цикл, пройденный 2 самых полных круга (полных - по количеству бит в массиве - например, 100000 бит) -
гарантирует от ошибок "утечка в смежный конденсатор в матрице ДОЗУ". Применяется для выходного контроля милитарисских ЭВМ.
П.С.Для сельской месности выбирать массив длиной больше 8 кбайт не рекомендуется. (смайл).

Источник: http://bk0010.org/forum/?id=6749 MM 29.12.2012 00:01

[TSL]

Хуже того что нету софтверных - хдльные точно так же не помогают. Реальные софты умудряются создавать хитрые комбинации сигналов, которые могут вызвать глюк, недостижимый в синтетических тестах. То же самое бывает на мамках РС.

[perestoronin]

Тест (http://azmaster.narod.ru/Ocean-240/) достаточно хороший есть для ретро-машинки Океан-240.2 (http://zx-pk.ru/showthread.php?t=14176). Он тоже на КР580ВМ80А (8080), думаю можете позаимствовать.

[vlad6502]

Океановский тест ожидаемо ничего не выявил :( Это, по сути, модификация алгоритма Address Code который я уже пробовал

Остается одна надежда на алгоритм с БКшного форума

P.S. В атачменте - дизасемблер теста Океан240

[MM]

1.Если нужно работать, а не "шашечки" - удалить ДОЗУ, поставить СОЗУ. Если абсолютно нет возможности удалить мультиплексоры ДОЗУ - сделать переходничок на ИР для СОЗУ.
2. Можно использовать стандартный классический быстрый тест ДОЗУ, но выкрутить питание по типу 4.75 в, 5.00 в, 5.25 в. на плате ДОЗУ - это поможет от гнилых ИС ДОЗУ .
2.1. В промышленности особо важные изделия испытывают в термокамерах - при +70 градусах ( температура корпуса ИС ДОЗУ ), и при минус 10 градусах - по полчасика. ( Минус можно брать, например, на балконе :v2_dizzy_christmas2 )
3. Спонтанные сбои ( выпадения ) - зловещий признак радиации.
Например, при 1 миллирентгене в час у классической пластиковой РУ5 выпадает до 1 бита в сутки ( плюс минус полсапога ).
4. Если именно во время работы программы пользователя идет выпадение битов во всех ИС ДОЗУ - проблема регенерации, точнее её отсуствия.
5. Около каждой ИС ДОЗУ должен быть установлен СОВЕТСКИЙ керамический конденсатор, для особо тяжелых случаев - от 1 мкф, например К10-17-2в. Это объясняется тем, что при регенерации внутри ИС 565РУ5 256 конденсаторов емкостью порядка 100 пф подключаются одновременно к шине питания, причем в полуразряженном состоянии, одновременно через 256 мощных ключей, создавая иголку порядка 30 нс тока до 200 ма. и более. ( Особенно это относится к РУ7 - до 500 ма.).
6. При создании паттерна тестирования ДОЗУ следует обращать внимание так же и на шины адреса / данных ЭВМ - при частотах обмена от 500 кгц там начинаются крайне нежелательные процессы - например, при обмене с классикой ИНТЕЛ 8080 данные на шине М-ЭВМ размером с лист А4 выставляются через порядка 150 нс или даже более. В момент времени от 0 до 150 нс на шинах адреса/данных - звон. Помогает от звонка 4-слойка с внутренними общим и питанием, а так же избыточная силовая буферизация - это может сократить звон до 20 нс ( и поднять потребление тока в разы ). При избыточной буферизации применяют резисторные сбоки НР1-3 ( 330 ом +5в, 680 ом общий ). В быстродействующих системах с шиной 2-3 мгц применяют подтяжки 180 ом / 330 ом. Классический буферный усилитель для сложных М-ЭВМ - КР531АП2 ( открытый коллектор ) , для простых - КР531АП6 ( закрытый коллекор ). Типовой постоянный ток - 60...96 ма в каждой линии шины.

[SoftFelix]

Самый вредный и длинный тест ОЗУ:
Именно такой алгоритм применён в ТЕСТ-ПЗУ 128К для Спекка от Андрея Хахонова. Если у меня на этом тесте (бесконечном) Спекк отработал часов 12 без ошибок - за память можно быть спокойным. Есть исходник, если что. Но это полый дизассемблер всего ТЕСТ-ПЗУ. Под 8080, имхо, вряд ли пойдёт без переделки, т.к. широко используются регистры и команды, характерные только для Z80.

[vlad6502]

MM, спасибо за полезную информацию ! Есть интересные моменты.

Насчет "шашечек" - в моем случае, это скорее академический интерес - как в принципе качественно протестировать память, т.к. свою техническую проблему я уже решил заменой глючившей РУшки.

[vlad6502]

Портировал "ТЕСТ-ПЗУ 128К для Спекка от Андрея Хахонова" - проблема не выявляется. Попробовал также "Программу тестирования ОЗУ" С.П.Тюлькина из журнала МПСС N1 1987г. с.54 (обещается агрессивный доступ к ОЗУ через инструкции push / pull) - тоже мимо. Пока что едиинственным надежным тестом является оболочка shell.rk от vinxru ;)

Я уже подумываю прицепить сверху еще одну РУшку, ловить несоответствие сигналов и определять в каком месте программы это проявляется. Хотя, будет все равно очень сложно выявить ошибку на этапе записи

[Reobne]

А не может такого быть, что память глючит при определённой температуре-влажности, поэтому тест её не распознаёт? :)
Или микросхема была припаяна с микротрещеной. После ремонта, эта микротрещена была пропаяна, а "бракованная" микросхема, на самом деле не такая-уж и бракованная?

[vlad6502]

Микросхемы установлены на панельках (http://vlad6502.livejournal.com/11796.html), условия тестирования абсолютно идеинтичны и результаты многократных тестов стабильно повторяемы, поэтому ошибка измерения навряд ли имеет место

[Reobne]

Ещё версии, для мозгового штурма:
Нарушается регенерация (например прога пишет в R)
Не хватает скорости (прога пишет-читает слишком быстро)

[vlad6502]

Меня интересует не столько root cause анализ, сколько надежное выявление сбоев тестами. А пока получается по тестам все Oк, а прикладная программа валится.

Тесты на регенерацию тоже пробовал

[Reobne]

Методом исключения найти ту часть программы, на которой глючесть проявляется. Анализирую программу, разбивая её на куски, и тестируя каждый кусок.
Записать цифровым осциллографом протокол работы ОЗУ с плохой и с хорошей микросхемой, потом сравнить протоколы.

[vlad6502]

Методом исключения найти ту часть программы, на которой глючесть проявляется. Анализирую программу, разбивая её на куски, и тестируя каждый кусок.
Приблизительно так и нашел глючную РУшку


Записать цифровым осциллографом протокол работы ОЗУ с плохой и с хорошей микросхемой, потом сравнить протоколы.
это и имел ввиду, когда говорил о подключнии исправной РУшки в параллель

тут уже просто спортивный интерес - подобрать/написать тест памяти который сможет отлавливать подобные глюки

[HardWareMan]

Прикрутить четность и потом на сбойном адресе анализировать в микроскоп.

[SoftFelix]

Портировал "ТЕСТ-ПЗУ 128К для Спекка от Андрея Хахонова" - проблема не выявляется.
У меня когда-то давно, при отладке какого-то Спекка, была тоже не выявляемая проблема с памятью. Т.е. в ТЕСТ-ПЗУ всё писалось-читалось без проблем, но реально Спекк не работал. Причина была в чтении кода операции только из DRAM. Получалось так, что при чтении КОПа из ДРАМ, содержимое памяти разрушалось. Может копнУть в этом направлении?

[HardWareMan]

У меня когда-то давно, при отладке какого-то Спекка, была тоже не выявляемая проблема с памятью. Т.е. в ТЕСТ-ПЗУ всё писалось-читалось без проблем, но реально Спекк не работал. Причина была в чтении кода операции только из DRAM. Получалось так, что при чтении КОПа из ДРАМ, содержимое памяти разрушалось. Может копнУть в этом направлении?
Особенность Z80 в том, что КОП он защелкивает по 1=>0 в тактах, а обращение к данным по 0=>1. Именно поэтому, в большинстве клонах на DRAM Z80 "сидит" на сигнале RAS, получая автоматический синхронизацию с памятью в циклах записи и чтения данных, а для КОПа стоит регистр-защелка ИР22 и вырабатывается сигнал WAIT по циклу М1.
http://savepic.ru/6543475.png
Таким образом, это вина не памяти.

[vlad6502]

Прикрутить четность и потом на сбойном адресе анализировать в микроскоп.

Интересная мысль, тем более что конструктивно моя плата динамического ОЗУ позволяет пристегнуть дочернюю платку с дополнительными банками. Вместо этого можно попробовать прикрутить контроллер четности.

Может есть несложная схема на примете ?

[HardWareMan]

В схемках XT и первых PS/2 была. А по сути: микра ставится параллельно остальным, кроме данных. Вход микры подключаем к выходу схемы XOR всех бит данных (т.е. в нашем случае 8XOR). Выход на XOR с тем же 8XOR. Если будет неравенство - то генерировать NMI и желательно защелкнуть адрес возникновения.

[Reobne]

Интересно узнать побольше про реальную программу, на которой происходит сбой. Большая-ли она? Реально-ли её дизасемблировать, расчленить, составить на её основе тесты?

[vlad6502]

Интересно узнать побольше про реальную программу, на которой происходит сбой. Большая-ли она? Реально-ли её дизасемблировать, расчленить, составить на её основе тесты?

Программа - shell.rk из комплекта ПО SD контроллера от vinxru
(http://vinxru.livejournal.com/235725.html) Есть исходники на C и ассемблере. Я ее поковырял немного, чуть сузил круг поиска, но всерьез внутрь пока не лез - 12кб бинарник.

Нашел тут микруху 155ИП2 - как раз занимается контролем четности. C NMI сложновато в Микро-80, поэтому при обнаружении ошибки можно сбрасывать сигнал READY и на инженерном пульте смотреть адрес

[HardWareMan]

Да, можно и так. Вполне себе.

[Reobne]

Смотрю в SHELL.ASM и вижу команду INR M.
Можно её проверить, на удачу:
берём память в аккумулятор.
Делаем цикл 16 раз.
В цикле 16 команд INR M.
Сравниваем аккумулятор с памятью.
Если NZ, то печатаем HL, A и (HL).
Переходим на следующую ячейку.

Как-бы тест на скорость. А то обычно тесты сначало пишут, потом ждут, потом проверяют.

[vlad6502]

еще в самом начале я пробовал полный перебор значений ячеек - там как раз было циклическое запись/чтение значений каждого байта

но, для очистки совести, можно попробовать Ваш вариант

[HardWareMan]

INR M отличается от LDA/STA/LDAX/STAX/MOV M тем, что это RMW команда. А это значит, что тайминги будут следующие: 4-3-3. 3 такта между чтением и записью. Самое короткое из возможных. Т.е., я хочу сказать, что надо пробовать разные методы чтения и записи.

[Barmaley_m]

Нужно гуглить в интернете научные труды на тему тестирования динамической памяти. Там много разных нюансов. Например, некоторые ошибки проявляются только если одновременно идет изменение уровня на многих (всех) линиях адреса или данных. Это приводит к появлению помех по питанию, и иногда (особенно на дефектных микросхемах) такие помехи приводят к ошибкам.

Много дельных мыслей высказал MM, спасибо. И я поддержу сказанное им. От разводки платы зависит 90% работоспособности схемы. И для микросхем ОЗУ это тоже актуально. Очень критична разводка питания. Нужно много блокировочных конденсаторов разных номиналов, поближе к выводам питания микросхем, чтобы сглаживать пики потребления тока как на низких, так и на высоких частотах. Дорожки питания должны быть толстыми и вести прямо к источнику питания. По возможности еще и короткими.

При разводке питания удобно представить себе, что микросхема является источником импульсов тока на своих выводах питания. И нужно эти импульсы тока замкнуть наиболее коротким путем, чтобы они не распространялись по схеме. И словосочетание "наиболее коротким" следует понимать очень серьезно. Каждый лишний миллиметр дорожки - зло.

[vlad6502]

В начале этого топика я как раз давал ссылку на диссертацию «Исследование методов проверки работоспособности микросхем памяти РЭА», там большой раздел по алгоритмам тестирования ОЗУ

Вчера попробовал тест от DDp (http://zx-pk.ru/showpost.php?p=615016&postcount=177). Успех можно назвать частичным - тест просто завис :) Когда я перекомпилировал его в область памяти статического ОЗУ - заработал, но проблемную РУшку так и не обнаружил.

Идея с INR M - интересна, попробую.

[Reobne]

Для дополнительной парноидальности можно заполнить память нулями, прогнать по 256 раз INR M, потом по 256 раз DCR M.
Заполнить память FF-ами, опять прогнать.
Заполнить память FF-ами, прогнать.
Заполнить память AA-ами, прогнать.
Заполнить память 55-ами, прогнать.
Заполнить память рандомом, прогнать.
Инвертировать память, прогнать.

[shurik-ua]

Когда я перекомпилировал его в область памяти статического ОЗУ - заработал, но проблемную РУшку так и не обнаружил.
Напрашивается версия что в вашем компьютере что-то не так с чтением опкода из ДОЗУ - где-то какой-то сигнал генерируется не так как надо.

[vlad6502]

Сигналограммы проверял в первую очередь - никакого криминала. Проблема не только с чтением кодов операций - битую РУшку я вычислил по искажению выводимого на экран текста, потом сразу смотрел код программы в памяти - строковая константа была с искажением, так и выявил проблемный бит.

Попробовал тест с использованием INR M, DCR M - тоже мимо... Прям мистика какая-то ;)

[ivagor]

Насчет команд 8080 с минимальным промежутком между чтением-записью - кроме inr/dcr m стоит упомянуть xthl

[Reobne]

xthl
В Shell.asm такая команда не наблюдается.

[ivagor]

Возможно ли, что ошибка происходит при обращении shellrk к sdbios, или это исключено? А то в sdbios xthl есть
Даже если xthl в данном конкретном случае не причем, в принципе её можно использовать для тестов требующих минимума времени м/у чтением и записью (понятно, что это касается только H и [SP+1]), если нужно поменять биты не как в inr/dcr m

[Vslav]

А битая РУ-шка осталась? Можно ее, если что, потестировать в каком-либо другом устройстве?

[TSL]

Расскажу вам историю на ночь.
Купили мы в конце 90-х симм на 8МБ, 8 чипов по 4 бита. Цель: разрезать и припаять к спеку и запустить на спеке контроллер памяти на 7МГц, чтоб получить 7МГц турбу без вэйтов. Все получилось наотлично аж в 2-х случаях - первый сделал чувак, которого была идея, второй - я. Внимательный я заметил, что по неизвестной науке причине на каждом чипе (на 1 спектрум их ушло по 2 штуки) используются только 4 бита данных, а 4 бита висят в воздухе. Когда я подключил незадействованные 4 бита, оказалось они вполне рабочие. Бонус: 4 мегобайта вместо 2. Работали они, работали. Потом появилась другая плата и я переставил их туда. Повторил подвиг таксистов, перепилил контроллер драмы и тут ВНЕЗАПНО оказалось, что те самые бонусные лапы данных битые наглушь. Вывод: выбраковка. Почему работало на первой схеме и вылезло на второй? Однозначно отличались параметры двух схем. Как? Как угодно, обе платы давно на свалке, и установить сие невозможно. Такая мораль.

[Prusak]

Сегодня попалась одна глючная РУ6 в "Байте": в ней портились некоторые адреса только при определённых условиях. В моём случае это проявлялось если заполнить микросхему нулями. В работающем компьютере это выглядело как появление знакомест с повышенной яркостью (бит D6=1) случайным образом.

При этом досупные мне тесты ОЗУ показывали исправность памяти. Проверялось алгоритмами - "бегущая 1", "бегущий 0", #AA, #55, заполнение случайной последовательностью. При этом как издёвка выглядело выпадание знакомест в повышенную яркость при выводе сообщения, что "ОЗУ исправно" :)

Я думаю, что если бы опробовать на этой микросхеме тест памяти на заполнение чисто нулями, то наверное бы он показал неисправность. Но увы, микросхему я уже заменил.

[MM]

Кроме всего прочего будут влиять тайминги доступа - это, вообще-то, достаточно серьезная проблема, особенно для советского дерьма.
Для критических областей применения обычно проводили тест на годные в самом устройстве, и даже при заведомо проходных таймингах ( по ТУ ) ИС , например, 565РУ5 часто сыпали ошибками - особенно при прогреве. Характер - битовые выпадения, до нескольких единиц бит (при +70 градусах цельсия на кристалле, +60 - корпус).
Как обезопасить критическую аппаратуру от выпадений - выход только один - не менее 3 идентичных банков ДОЗУ и цифровой компаратор на выходе - если 2 из 3 данных одинаковые - они и берутся, посылая прерывание от контроллера ДОЗУ. Если все 3 данных разные - желателен ребоот девайса, т.к. это типа полный песец выходит.
*
Не так давно встретился интересный глюк М-ЭВМ спецприменения, все ИС - "5", ж.
Принесли с хранения запасный контроллер 1990 г.в., ДОЗУ из 16 шт 565РУ5В 2 явно сыпали ошибками - нет проблем, заказали с хранения идентичные ИС ДОЗУ. ИС пришли - при диагностике ошибок нет ( т.е. само исправилось, ИС не меняли ). Шли
запасные ИС 2 недели - типа как не понадобилися...
Особенности девайса - контроллер на ж. ИС БМК, его, кстати, и сменили первым - не помогло. Остальные 14 ИС в тесте изначально показывали "годен".
В общем, Заказчик эти контроллеры признал "не подлежат восстановлению",
т.к. если они опять начнут вредничать, могут быть крупные неприятности.
( Кстати, в этом спецдевайсе с ж. ИС есть 2 теста - один приведен в ТО и выполняется установкой перемычки при подаче питания, а второй - на внешнем стенде, при обмене данными. Изначально ошибки были на обоих тестах, характер ошибок - битовые выпадения единичного характера... ).

[stealth_w]

Я эти РУ5 так до конца и не понял :) Вроде и ТУ почитал - и тесты поделал - все равно не понимаю. Судя по всему есть какая-то недокументированная особенность в предустановке адреса и RW относительно CAS. В итоге я просто сделал несколько диаграмм и рассортировал все микросхемы. В синклере пока не смотрел - а вот в XT у меня пошли только те что допускают установку ADR,RW,CAS одновременно. Я их условно назвал быстрые :) Сделаю стэнд с качкой питания - еще поковыряю :)

Обычно я использую след тэст - запись ПСП, пауза на регенерации , многократное считывание ПСП - и так пока не надоест. Тэст аппаратный - диаграмма с шагом 50 нан.

[vlad6502]

тэст - запись ПСП, пауза на регенерации , многократное считывание ПСП - и так пока не надоест.

что есть "ПСП", извините за дремучесть ?

[SoftFelix]

Псевдо Случайная Последовательность. Имхо. :)

[Barmaley_m]

Я тут еще недавно прочитал статью: "Exploiting the DRAM rowhammer bug to gain kernel privileges (http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html)"

Суть в том, что обращение к ячейке памяти приводит к регенерации всей строки, в которой расположена эта ячейка. При этом регенерация соседних строк не происходит (точнее, она происходит в обычном режиме с той периодичностью, с которой ее ведет схема регенерации или видеоконтроллер). Однако из-за близкого физического расположения конденсаторов соседних строк, частая регенерация одной строки может разрушить содержимое соседней строки до того, как оно тоже будет регенерировано схемой регенерации.

В статье написано, что эта проблема характерна только для современных ИС ДОЗУ, из-за увеличения их степени интеграции. Однако я думаю, что она может проявляться и у старых микросхем, если на их кристаллах имеются какие-то микродефекты.

Поэтому напрашивается следующий тест: "Row hammer test":
1) записываем в память исходные данные, "забывание" которых мы будем проверять впоследствии;
2) молотим одну и ту же ячейку многократными обращениями некоторое время
3) проверяем всю память на предмет "забывания" информации
И так в цикле.

"забывание" информации наиболее вероятно может произойти в строках, соседних с той, которую молотили на шаге 2. Однако конкретный столбец, где произойдет "забывание", предсказать невозможно, поэтому надо проверять содержимое соседних строк полностью.

Повысить эффективность можно, если синхронизировать тест с работой схемы регенерации ОЗУ. То есть начинать молотить строку сразу после того, как соседние с ней строки были регенерированы. Если есть возможность - на время тестирования снизить период регенерации, чтобы спровоцировать появление ошибок в менее устойчивых ячейках памяти.

В клонах Спектрума каждое обращение к памяти приводит к активации строки (импульс сигнала RAS), поэтому никакие дополнительные меры принимать не нужно. В более современной памяти типа FPM, EDO, SDR, возможно один раз "открыть" строку (при этом происходит ее регенерация и полное считывание в буфер строки), так что последующие обращения к этой же строке не приводят к ее считыванию и регенерации, а просто возвращают данные из буфера. Там row hammer test несколько усложняется.