Ответ 1
Завершение - это двусмысленное слово. Это может означать разные температуры, напряжения и различные устройства с различными допусками компонентов. Как вы думаете, сайт MemTest86, я думаю, я понимаю. Большинство проектов, которые я видел, основаны на C и не могут проверить все.
Вот один работает под Linux - http://www.madsgroup.org/~quintela/memtest/
Существуют алгоритмы, описанные как ходячие биты и т.д. Многое зависит от вашего типа RAM. Я думаю, у вас есть какой-то тип SDRAM. Существует много разных циклов с SDRAM. Есть однобитовые чтения/записи, банковские переводы, завершенные всплески и т.д.
Лично у нас была система, 5% из плат отображали проблемы при передаче SSH через Ethernet (DMA). SSH включает в себя шифрование, которое интенсивно связано с CPU/памятью, а механизм DMA часто выполняет разные циклы SDRAM, чем процессор (с кешем).
Вот некоторые требования,
- Память без SDRAM для хранения кода.
- Базовая структура (без кеша, прерываний, DMA и т.д.)
- Отключите DCache.
- Включите ICache для кода.
Другим ограничивающим требованием является время запуска. Полный тест SDRAM может занять годы, чтобы работать на одной плате. Я обнаружил, что тест псевдослучайных адресов/данных работает хорошо. Просто возьмите числа, которые являются относительными первичными по размеру SDRAM и используют это как прирост. Простейшим случаем является 1. Возможно, вы захотите, чтобы другие постоянно меняли rows, banks и размер устройства; bank size-1 например; однако простые числа будут работать лучше, поскольку у вас есть разные количества бит, меняющихся все время. Если вы отключите кеш, вы можете использовать указатели char, short, int и long long для проверки некоторых разных длин пакетов. Эти тесты будут медленными. Вам нужно будет использовать пары ldm/stm для имитации полного пакета SDRAM, это чаще встречается с кешем, поэтому вы должны имитировать их с помощью ldm/stm. Это также один из самых быстрых тестов.
typedef unsigned char b8; typedef unsigned short b16; typedef unsigned long b32; typedef unsigned long long b64; /* Use a macro to speed code. The compiler will use constants for * _incr and _wrap instead of registers which cause spilling. A * macro centralizes the memory test logic. */ #define MEMTEST(name,type,_incr,_wrap) ... /* Sequential tests. */ MEMTEST(do_mem_seq8, b8, 97, 1) MEMTEST(do_mem_seq16, b16, 50839, 1) MEMTEST(do_mem_seq32, b32, 3999971, 1) MEMTEST(do_mem_seq64, b64, 3999971, 1) /* Random tests. These test try to randomize both the data and the * address access. */ /* 97/0x61 prime for char and 9999991/0x989677 prime for 64MB. */ MEMTEST(do_mem_rnd8,b8,97,9999991) /* 50839/C697 large prime for 64k and 9999991/0x989677 prime for 64MB. */ MEMTEST(do_mem_rnd16,b16,50839,9999991) /* 3999971/3D08E3 prime and 9999991/0x989677 prime for 64MB. */ MEMTEST(do_mem_rnd32,b32,3999971,9999991) /* 3999971/3D08E3 prime and 9999991/0x989677 prime for 64MB. */ MEMTEST(do_mem_rnd64,b64,3999971,9999991)
incr - это инкремент данных, а wrap - это приращение адреса. Алгоритм для пакета будет таким же. Вот несколько встроенных gcc-ассемблеров,
register ulong t1 asm ("r0") = 0; \
register ulong t2 asm ("r4") = t1 + incr; \
register ulong t3 asm ("r6") = t2 + incr; \
register ulong t4 asm ("r8") = t3 + incr; \
/* Run an entire burst line. */ \
__asm__ (" stmia %[ptr], {%0,%1,%2,%3}\r\n" : : \
"r" (t1), "r" (t2), "r" (t3), "r" (t4), \
[ptr]"r" (start + (addr<<2)) : \
"memory" ); \
/* Read four 32 bits values. */ \
__asm__ (" ldmia %[ptr], {%0, %1, %2, %3}\r\n" : \
"=r" (t1), "=r" (t2), "=r" (t3), "=r" (t4) : \
[ptr]"r" (start + (addr<<2)) ); \
Эти тесты просты и должны вписываться в кеш-код, который максимизирует нагрузку на ОЗУ. Нашей основной проблемой была задержка DQS, которая имеет решающее значение для DDR-SDRAM и может быть зависимой от температуры и напряжения и будет меняться в зависимости от компоновки печатной платы и материалов.
Cachbench можно использовать, если вы оптимизируете регистры контроллера памяти с помощью чипов SDRAM. Он также может быть полезен для тестирования.
Смотрите также: Unix Stack Exchange (тот же вопрос). Я использовал эти тестовые комплекты на базе C под Linux, но в нашем случае они не выявили никаких проблем. memtest86 алгоритмы могут быть не такими стрессовыми (для сбоев PCB), как я описываю выше; хотя тест 7 или тест burnBX близок. Я думаю, memtest86 может найти проблемы с чипами DRAM, а не проблемы с дизайном платы.
Изменить: Другая проблема - переходные/перекрестные разговоры с чипами SDRAM. Если ваш драйвер устройства является высокоточным или высокочастотным устройством, интерфейс SDRAM может поднять межсоединение или получить двойные часы из-за изменений в поставке. Таким образом, тест RAM может не обнаруживать проблем, и ошибка SDRAM возникает только при использовании определенной части аппаратного обеспечения. Также будьте осторожны, чтобы устройство Android не использовало динамическое синхронизацию и не меняло частоту SDRAM. Сигналы могут пересекать резонанс по мере изменения часов.