Нужные ли резисторы на шине данных ARM7 Опции

[PCBExp]

Коллеги. Сейчас делаем редизайн старого проекта на ARM7 (Samsung S34510, частота 50МГц). Устройство маленькое, места вообще нет. По совету коллег из Германии удалили из шин адреса и данных резисторы 33Ома (для экономии места). Помоделировали плату. С шиной адреса проблем нет. На шине данных, когда источник - процессор, то проблем тоже нет. Когда источник - SDRAM очень большие over и undershot-ы (см. аттач, фиолетовый - сигнал на ногах процессора). Хотелось бы понять эти выбросы помешают работе устройства или нет?

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

Сообщение отредактировал PCBExp - Jan 13 2009, 06:17

Прикрепленные файлы

 D0_SDRAM_Master.pdf ( 238.06 килобайт ) Кол-во скачиваний: 283

 

[cioma]

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

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

[AlexandrY]

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

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

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

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

[cioma]

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

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

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

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