Глянул у LPC2478 адресные и линии данных рассчитаны на 5 вольт. Может ли всплеск от фронта в 3,3 вольта превысить 5 вольт?

Какое же тут разнообразие? Это скучное постоянство. Вы попробуйте лучше забить всю память псевдослучайной последовательностью, а потом считать и сверить. И так сутки хотя бы. На таком тесте замечательно падают системы, которые сутками могут нули/единицы/паттерны гонять.

а если чтото вылезет через десять пятнадцать лет?

мне кажется, что паттерн бегущего нуля или единицы не так уж плох, поскольку позволяет создать максимальный кросстолк от соседних линий на на эту самую бегущюю фигню, и тем самым проверить грамотность разводки (ширины, зазаоры, расстояния до полигонов замли во внутренних слоях... С чем и столкнулся коллега http://electronix.ru/forum/index.php?showtopic=34852

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

Кто ж говорит, что идиоты? Псевдослучайная последовательность обычно входит в нормальный набор тестов. А ошибки на "идиотски разведенной плате" на ней выявляются быстрее и надежнее, ИМХО.

Не то чтобы они полные идиоты, но старинные тесты явно потеряли актуальность.
Как бы понятно что SRAM, SDRAM и DDRAM надо по разному тестировать, а еще учитывать кэш, буферизацию, длину пакетов и порядок чередования байт в пакете.

Недавно открыл очень интересный тест.
Есть DDRAM которая замечательно прошла все тесты, и запись бегущими нулями и единицами, и запись случайными числами, и сверху вниз и снизу вверх и пачками и т.д.
Но когда попытался записывать сразу пачки регистров командой например: STMFD R0!, {R4-R12}
с определенным патерном заполнения регистров, то обнаружил искажение в старших адресах памяти на расстоянии 12-и байтов от адреса на который указывал R0

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

можно итог подводить: резисторы в шине данных "не повредят". Но гораздо важнее ширины проводников, грамотные зазоры между ними, правильное расстояние до слоя земли и разводка чтоб не было загогулин лишних и петель. Хотел написать строго ручная разводка, но подумал - а вдруг есть хорошие автоматы?

До итога здесь как до луны.
Можно обсуждать и обсуждать.
Например мне кажется, что при расстояниях от uC до памяти меньше 2-3 см зазоры и ширины имеют не то значение которое им приписывают симуляторы типа Hyperlynx.
Такие проводники надо рассматривать как сосредоточенные индуктивности и учитывать сосредоточенные индуктивности вносимые via. Причем via на блокировочные конденсаторы. И индуктивности самих конденсаторов.
Понятно, что симуляторы таких расчетов не могут выполнить поскольку надо считать интегралы 3-го порядка и больше для 3-х мерных структур.
И именно сосредоточенные индуктивности создают овершутинги на крутых фронтах на близких расстояниях.
Отсюда собственно вывод, что если чипы не имеют возможности регулировки силы своих драйверов, то резисторы - единственный путь уменьшения овершутингов. И не то что бы они не повредят, а просто обязательны.
А вот петли и загогулины - зло неизбежное, поэтому играть на них бессмысленно.

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

Короче, стратегии дизайна для дальней и ближней памяти должны быть разные.

По поводу программных тестов.
В данном случае тесты должны быть для платы, а не для чипов памяти (которые a priori считаем безглючными). Отсюда и надо плясать, например для crosstalk - переключать 2 (а при плотной разводке и 4) соседних линии, для ground bounce - переключать все биты одновременно из 0 в 1 и наоборот итд.

По поводу расчетов в симуляторах. Естественно для моделирования в 3D необходимо что-либо посерьезнее HL (например, Sigrity или Ansoft). Но в первую очередь результаты моделирования зависят от моделей (IBIS, Spice), так что не стоит удивляться что HL и реальность могут расходиться - все зависит (С). При верных моделях и правильном проекте расхождение обычно не превышает 5-10%.

Не факт что память априори должна считаться безглючной и кондиционной.
Во всяком случае именно она самый опасный источник непредсказуемого звона и в ней происходят сбои ну и в uС, а не на проводниках платы.
А еще есть резонансы провоцируемые паттернами, которые врядли симулирует Ansoft
Модели на дискретные компоненты также можно считать недоступными. А IBIS модели отвечают только за входы-выходы ничего не зная о внутренних коммутациях в IC отражающихся на выводах питания и сигналов.

А не зная физический интерфейс памяти трудно подобрать то самое критическое переключение.
Я для того и привел свой пример, чтобы показать, что работая на верхнем уровне абстракции памяти простые паттерны не помогают.

Со времен памяти серии КР537 и процессора 580ВМ80А пришел к выводу, что если тест памяти длится меньше 10 минут, то он толком ничего не проверяет. Рекорд был когда сбой теста памяти происходил через 4-5 часов после запуска теста и это на 32 Кб ОЗУ.
Так что есть над чем работать, лучше не делать поспешных выводов.

Я согласен что IBIS не дает всей необходимой информации для моделирования power integrity. Для signal integrity в большинстве приложений хватает адекватной IBIS модели (с этим тоже бывают проблемы ), для высокоскоростных интерфейсов - как правило HSPICE. Чтож до тестов, то я имел в виду реальные программные тесты на реальном железе, а не в симуляторе (где они ранее также должны быть проведены).

Под безглючностью памяти разумеется, что производитель просимулировал и протестировал данный дизайн чипа и корпуса, и качество в серии - повторяемо. Я, как разработчик платы, не могу улучшить чип памяти, но я могу улучшить плату. Потому я и говорю про "тестирование разводки" . Если тест не проходит, то в подавляющем числе случаев виновата схемотехника и/или разводка, а не сама память (мы ведь говорим про нормалную память типа Micron или Samsung, так?). Конечно было бы классно и собственно чип памяти пртестировать, но, как заметил предыдущий оратор, ктож Вам расскажет его внутренне устройство, а без этого покрытие стандартных тестов будет невелико, что статистически можно несколько улучшить используя случайные последовательности при длительном тестировании.

Мог бы согласиться лет десять назад.
А нынче дела хуже.
Errat-ы на процы читаете?
А на SDRAM видели?
Там пацаны хитрее, они все спихнут на нестыковку интерфейсов.
Но от этого не легче.
Тестировать память на сегодняшний день надо прежде всего для обкатки сопряжения контроллера памяти uC с чипами памяти
и для тюнинга производительности.

Согласен - нужно все учитывать

Что-то топикстартер молчит, поделился бы результатами, если уже платы сделали.

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