Программа "Тест Устройств"

[rst]

Итак, программа "Тест Устройств", как и многие программы Счётмаша собрана на базе "Драйверов устройств", отличия в версиях такие:
[LIST][*]Тест ОЗУ -- в тестах для Вектора отличий нет

В моём "Векторе-06Ц" (купленном вроде в 1990г или в 1991г) был брак в одном из чипов КР565РУ6, который не обнаруживался этим тестом. В результате - брак был пропущен при проверке в магазине, и я получил "Вектор", на котором часть программ не работали (брак был в чипе в области видео-ОЗУ, поэтому большинство программ работали, но с иногда появляющимися артефактами на экране). Что это именно брак, а не криво записанные на кассеты программы - я понял не сразу, а только когда стал более-менее соображать в электронике и программировании. Потом и исправил его - заменил бракованную КР565РУ6. После чего заработали ранее не работавшие программы.

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

[Advertiser]

[Improver]

Брак заключался как я понимаю - в сбое регенерации содержимого некоторых ячеек ОЗУ
<...>
И непонятно почему тест его не учитывал.

Вообще, в тесте памяти это учитывается, но немного другим способом, там тестирование выполняется так: запись -- ожидание -- чтение. По идее, за время ожидания проходит несколько раз регенерация памяти, и при этом брак можно выявить, но, видимо, не всякий...

[rst]

Вообще, в тесте памяти это учитывается, но немного другим способом, там тестирование выполняется так: запись -- ожидание -- чтение. По идее, за время ожидания проходит несколько раз регенерация памяти, и при этом брак можно выявить, но, видимо, не всякий...

Так в моём случае не работала не периодическая регенерация, а регенерация после чтения. Насколько я знаю - содержимое ячейки динамического ОЗУ разрушается операцией чтения (заряд конденсатора тратится при операции чтения). Поэтому после любой операции чтения, заряд конденсатора должен восстанавливаться циклом записи, следующим сразу после цикла чтения. Это выполняется внутренней схемой в чипе дин.памяти. Вот это и не работало.
Да, я знаю что в Векторе видеоконтроллер тоже читает ОЗУ постоянно (да и сбойные биты находились как раз в области видео-ОЗУ). Возможно цикл регенерации после чтения сбивался при следующих друг за другом подряд двух операциях чтения - CPU и видеоконтроллером. Или ещё из-за какой-то комбинации причин. Тут можно только гадать. Но факт был в том, что после записи в эти биты, их содержимое не портилось сколь угодно долго, пока их не прочитает именно CPU. А как только читал CPU - сразу портилось (на экране появлялась россыпь точек в местах сбойных бит). И случалось это только в тех программах, которые и читали ОЗУ. Которые только писали в видеоОЗУ - сбойных точек не возникало.
Например - если в этой области нарисовать закрашенный прямоугольник, то он таким и оставался; сколько угодно долго. Но если выполнить закраску этого же участка при помощи заливки области, то сразу возникали точки (так как алгоритм заливки должен читать видеоОЗУ, когда ищет пути заливки).
Причём - первая операция чтения ячейки процессором возвращала правильное (неразрушенное значение). А уже последующие чтения - возвращали разрушенное значение.
Естественно - если в эти адреса расположить какой-то программный код, то он тоже портился после первого выполнения. Думаю поэтому на моём экземпляре не работали некоторые программы. Которые заработали сразу после замены сбойной КР565РУ6.

PS: Да и сам по себе алгоритм теста: "запись-ожидание-чтение", имхо - бессмысленный. Потому как ожидание тогда нужно делать очень длительным (на несколько десятков секунд минимум). Я как-то (уже на современных чипах SDRAM) в одном своём проекте (где были такие чипы) делал тест: выключал регенерацию SDRAM (как внешнюю так и внутреннюю) и делал паузу, потом заново включал регенерацию и проверял содержимое ОЗУ. Так вот - портиться ОЗУ начинала только после нескольких секунд выдержки без регенерации (или даже нескольких десятков секунд?... уже точно не помню, но при желании можно найти тот проект и заново измерить). А некоторые биты держались даже несколько десятков секунд. А тот тест ОЗУ (в "Тесте устройств") явно не ждёт достаточно долго и, даже если бы схема периодической регенерации вообще бы не работала, то он скорей всего тоже не находил бы сбоев.

[ivagor]

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

Если ждать долго, а вернее если сначала все записывать и потом все проверять, то это расширяет диапазон обнаруживаемых ошибок.

- - - Добавлено - - -

в моём случае не работала не периодическая регенерация, а регенерация после чтения.

Вектор регенерирует "свои" РУ6 через полноценные циклы чтения данных для видео. А регенерация only RAS для кваза, подключенного к ВУ.

[rst]

Вектор регенерирует "свои" РУ6 через полноценные циклы чтения данных для видео. А регенерация only RAS для кваза, подключенного к ВУ.

Вы хотя бы читайте то, на что отвечаете. Ещё раз:

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

wiki:

The storage cells on a memory chip are laid out in a rectangular array of rows and columns. The read process in DRAM is destructive and removes the charge on the memory cells in an entire row, so there is a column of specialized latches on the chip called sense amplifiers, one for each column of memory cells, to temporarily hold the data. During a normal read operation, the sense amplifiers after reading and latching the data, rewrite the data in the accessed row.

Это происходит внутри чипа и что там делает снаружи Вектор - не при чём.

Сбой происходил видимо при 2-х операциях чтения следующих подряд (CPU+видеоконтроллер). Так что - ко 2-й операции чтения заряд не успевал быть регенерирован.

[ivagor]

Информация может испортиться в финальной части цикла чтения, т.е. здесь

the sense amplifiers after reading and latching the data, rewrite the data in the accessed row.

Если процессор прочитал правильно, получается теоретически испортить процесс (не дать нормально завершится зарядке конденсатора) может следующее чтение видеоконтроллера, если оно начинается слишком рано. Слишком рано не для РУ6 в целом, а для конкретной дефектной ячейки.
Если вышенаписанное верно, то признаю, одинарное чтение будет правильным.
Но тогда возможен и другой, очень специфический вариант: если вставим чтение процессора сразу после чтения этой дефектной ячейки видеоконтроллером (можно рассчитать по времени относительно прерывания), то уже первое чтение даст неправильный результат.

[Improver]

Если ждать долго, а вернее если сначала все записывать и потом все проверять, то это расширяет диапазон обнаруживаемых ошибок.

Сбой происходил видимо при 2-х операциях чтения следующих подряд (CPU+видеоконтроллер). Так что - ко 2-й операции чтения заряд не успевал быть регенерирован.

В таком случае, возможно, стоит обновить тест памяти в "Тесте устройств"... Либо пользоваться несколькими разными тестами.

[ivagor]

Вы хотя бы читайте то, на что отвечаете.

Рекомендую поступать аналогично. Где в процитированном посте я писал, что чтение конденсатора ячейки dram (в РУ6, насколько знаю, 1T1C) не является деструктивным и в конце цикла чтения исходное значение конденсатора не восстанавливается?
Скорее мне можно вменить в вину, что я развернул этот фрагмент

Да, я знаю что в Векторе видеоконтроллер тоже читает ОЗУ постоянно

Возвращаясь к сути. Если учесть эту информацию

Причём - первая операция чтения ячейки процессором возвращала правильное (неразрушенное значение). А уже последующие чтения - возвращали разрушенное значение.

то получается
1) Или все же первая операция не всегда возвращала правильное значение
2) Или дело не в двух чтениях (видеоконтроллер+процессор ) подряд

Да и сам по себе алгоритм теста: "запись-ожидание-чтение", имхо - бессмысленный. Потому как ожидание тогда нужно делать очень длительным (на несколько десятков секунд минимум). Я как-то (уже на современных чипах SDRAM) в одном своём проекте (где были такие чипы) делал тест: выключал регенерацию SDRAM (как внешнюю так и внутреннюю) и делал паузу, потом заново включал регенерацию и проверял содержимое ОЗУ. Так вот - портиться ОЗУ начинала только после нескольких секунд выдержки без регенерации (или даже нескольких десятков секунд?... уже точно не помню, но при желании можно найти тот проект и заново измерить). А некоторые биты держались даже несколько десятков секунд.

Современные SDRAM держат сигнал минимум секунд 10 (если не дольше), особенно если не жарко (а лучше холодно). Сам тоже с этим сталкивался, записывал в SDRAM плисовой девборды данные, потом ресет, потом заливка конфига в плис, старт - и все данные на месте. Советские dram (и их зарубежные прототипы) на такое не способны. Но в тестах для вектора это (ожидание за рамками забывания при отсутствии регенерации) использовать не получится, скорее в других компьютерах с 580ВМ80, у которых можно повлиять на регенерацию.

[rst]

Возвращаясь к сути. Если учесть эту информацию

то получается
1) Или все же первая операция не всегда возвращала правильное значение
2) Или дело не в двух чтениях (видеоконтроллер+процессор ) подряд

Почему?