В случае МС1201.03/04 чрезмерна емкостная и индуктивная нагрузка - что весьма критично при таких обстоятельствах.Сообщение от Vslav
Емкость 1 входа 565РУ5 - в районе 10 пф, что в массиве 44 БИС ДОЗУ ( в общей сложности ) выходит под 500 пф, из них порядка 100 пф - интерференция от соседних неопределенной фазы сигналов, в итоге для ~ 10 мгц сигналов выходит "кашка" .
Блог : http://collectingrd.kxk.ru/ . В ЛС прошу не писать, все сообщения MMTEMA@MAIL.RU
Хм, входную емкость адресных входов микросхем памяти стараются поменьше сделать, у 565РУ3 или аналогов 4164 на входе не более 5пф. Неужели РУ5 намного хуже по параметрам? Всего микросхем 44 штуки, но они разбиты на 2 банка, поэтому максимальная нагрузка на адресный выход - 22 входа. Погонная емкость типовой двухсторонней платы на FR-4 (эпсилон от 3.5 до 4), для ширины проводника 0.25мм и зазоре 0.25мм - от 0.5 до 0.8 пф/см, ну пусть проводник длиной 50 см, получим 40 пф. В-общем, если очень-очень не повезет - наберем по шине адреса 150-200пФ.
Реальные картинки с моей платы, линия адреса A0, вход самой дальней микросхемы (на краю платы):
Нарастающий фронт:
Ниспадающий фронт:
Тут, кстати, фронт очень резкий (от 48мА качают), линия несогласована, есть выраженный undershoot. Можно снять заряд плавнее, почти без потери быстродействия, 531 серия тут не очень хорошо подходит.
Снизу на картинках осциллограф измерил время фронтов - изменение сигнала от уровня 10 до уровня 90 процентов. Я начинаю думать что тут и 74HCT373 со своими симметричными 6мА на выходе может справиться.
И регистры неравноценную роль на плате играют, D15, D16 и D37 можно заменить вообще не раздумывая, очень высокая вероятность, что нормально заработают D28 и D29. К тому же уменьшится время конфликтов по выходу - старший адрес разрешается раньше чем запрещается младший, на время задержки на D20.3. И только насчет замены D30 и D31 надо подумать и поэкспериментировать.
- - - Добавлено - - -
Цикл записи DATO процессор ВМ3 не предваряет сигналом TA. "Тут играть, тут не играть, тут рыбу заворачивали" (c). О как.
- - - Добавлено - - -
Цикл записи слова в банк 0 DRAM, в момент записи возникает запрос на рефреш, цикл рефреша следует за циклом записи.
Легенда (на этой и последующих картинках):
Частота дискретизации 200МГц, точность всех временнЫх интервалов 5 нс.
CLK - тактовая на процессоре (на 119 она будет задержана и инвертирована)
REFCLK - тактовая запросов на рефреш (ножка 2 119-ой), по фронту фиксируется запрос на цикл рефреша
nTA - выход процессора, любопытно, что строб генерируется только для циклов DATI и DATIO
nRAS0, nRAS1, nCAS, nWE, nWEC - выходы 119-ой
nDRAS0, nDRAS1, nDCAS, nDWE, A0, A1 - входы микросхем DRAM 565РУ5
nEAR - разрешение регистров адреса рефреша (D26/D27)
nEAL - разрешение регистров выдачи младшего байта адреса (D28/D29)
nEAH - разрешение регистров выдачи старшего байта адреса (D30/D31)
С отреверсенной моделью все совпадает.
Процессор выставляет nWTBT, адрес, неактивный nTA и активирует nSYNC. ВП1-119 при этом никаких циклов внутри не запускает. Потом активируется nDOUT, при этом 119-ая внутри взводит триггер запроса на цикл доступа к DRAM, запрос будет обслужен по ниспадающему фронту CLK. К первому срезу CLK процессы внутри 119-ой завершится не успевают, и мы теряем целый такт на ожидании запуска. Особенность ли это данного конкретного экземпларя 119-ой или это характерно для всех мкиросхем - скзать сложно. На следующем срезе CLK запускается наконец цикл доступа, видим активированный nRAS0, далее управляются регистры мультиплексора адреса, активируется nCAS, затем выставляется nREPLY, и цикл записи завершается. Затем после паузы начинается цикл рефреша. 119-ая всегда генерирует рефреш по циклу CAS-before-RAS. Отдельная внешняя схема отслеживает это момент и для 1201.03 с мискросхемами РУ5 просто блокирует прохождение CAS на сами микросхемы DRAM. На диаграмме видно что схема отработала не совсем удачно, на выходном CAS есть всплеск длительностью 10-15 нс.
Фаза выдачи адреса подробнее:
Для микросхем 565РУ5Г требуются такие параметры:
- удержание адреса после среза RAS - мин 40 нс
- CAS после RAS не ранее 55 нс
- установка адреса перед срезом CAS - мин 0 нс
- удержание адреса посла среза CAS - мин 45 нс
- длительность неактивного RAS - мин 200 нс
- длительность RAS - мин 150 нс
- длительность СAS - мин 120 нс
Нарушений особо вроде нет, все с запасом, единственное что - маловато удерживается адрес после активации RAS (после переразрешения регистров проходит еще 25-30нс до установки адреса на входах РУ5), но это легко подкручивается цепочкой R1/C104. Времени между RAS-CAS на микросхемах DRAM более 200нс, вполне достаточно и для применения более слабых регистров 1533ИР22, вполне можно выкрутиться, и есть еще резерв для задержки CAS.
Последний раз редактировалось Vslav; 21.04.2016 в 01:18.
Интересно видеть диаграммы с такими сигналами :
1. ТА
2. SYNC
3. DIN
4. DOUT
5. SSYNC
6. A0 DRAM
7. A1 DRAM
8. A2 DRAM
9. A3 DRAM
10. A5 DRAM
11. A6 DRAM
12. A7 DRAM
13. RAS
14. CAS
15. AD0
16. AD1
17. AD2
18. AD3
19. AD4
20. AD5
21. AD6
22. AD7
23. RPLY
24. СLC CPU
25. Сигнал записи в регистры фиксации данных из ДОЗУ
При съёме диаграмм можно выполнять такую программу с 1000 адреса :
001000 : 012701 000000 000775
Предложенная последовательность кода и сигналов М-ЭВМ позволит предположить корректность/некорректность работы с БИС ДОЗУ в части правильной последовательности выставления адресов и синхросигналов для 565РУх .
( Хотя, судя по всему, попался какой-то прято таки правильный образец МС1201.03, где все диаграммы как в ТО, а не как на большинстве плат... ).
Блог : http://collectingrd.kxk.ru/ . В ЛС прошу не писать, все сообщения MMTEMA@MAIL.RU
Сделаю обязательно, но чуть позже (вероятно, на следующей неделе, пока плату убрал со стола).
Глядя на диаграммы разрешения регистров мультиплексора адреса, видно раcхождение в 15нс, это много для 531-ой серии. Наверняка там еще и кратковременный конфликт по выходам возникает, со сквозным током, особо хорошо для адресов типа 177400 и 000377 - максимальное количество выходных линий конфликтует при переключении. А с учетом немерянной дури выходных драйверов 531ИР22, помеха должна весьма приличная возникать, ну и в нагрев оно свой вклад вносит, вероятно. Планирую еще D20 на более быструю 1533ЛА3 заменить.
С удивлением обнаружил, что ВМ2тоже имеет средства для построения многопроцессорных комплексов. Вроде-бы везде писали, что это было только у ВМ1, а тут и ВМ2, причем как 1801, так и 1806...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Эти средства разного порядка. У ВМ1 встроен арбитраж доступа к шине, а у ВМ2 просто есть запрос разрешения доступа к области памяти. В первом случае это определяет кто пользуется шиной, и понятно как работает, а вот какие задачи предполагали решать окном ВМ2 непонятно абсолютно. При условии, что операция DATIO атомарна, все межпроцессорные примитивы синхронизации реализуются без всяких дополнительных аппаратных возможностей.
Вот это меня удивляло больше всего. Ведь шина в те времена, практически, и была самым узким местом. И, навесив не нее 4 процессора, можно получить ситуацию, когда они, в основном, будут ждать шину, а не работать. Впрочем, на сугубо специальных задачах польза может быть и будет. Например, когда каждая вторая-третья команда в основном цикле программы - умножение. (Не зря военные требовали команду умножения, без нее многопроцессорность вообще теряла смысл). Это сейчас можно поставить этим ВМ1 10-ns Static RAM, после чего они сействительно смогут работать параллельно. Но сейчас и процессоры намного быстрее, и все эти задачи решаются через многоуровневое кэширование и прочие средства, широко известные по писюкам.
А это больше похоже на средства кластеризации. И, в отличие ВМ1, опять же, на сугубо специализированных задачах, может дать существенный выигрыш, вплоть до сложения быстродействий отдельных микрокомпьютеров. Допустим, если задача разделяется на несколько слоёв. Первый комп обсчитывает первый слой, результаты передает через окно второму, второй считает свой слой, первый в это время считает новую порцию данных, и т.д. И, похоже, такие задачи у военных были, иначе зачем бы делали два окна процессору 1806ВМ2 ? Поскольку более 4-8 процессоров, работая через одно окно, скорее всего, будут тормозить друг друга, а с двумя окнами цепочка этих "слоёв" не ограничена - первое окно принимает данные от предыдущего слоя, второе передает следующему и цепляй эти слои последовательно, хоть сотню.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Утренняя, свежесобранная за ночь панорама металла 1801ВМ3:
полное разрешение (640МБ)
четверть разрешение (60МБ)
Надо сказать, что используемый для сборки панорам инструментарий подошел к технологическому пределу. Проектные нормы ВМ3 меньше чем ВМ2, к тому же на него нет заводской документации, поэтому детализации объектива x10/0.30 показалось недостаточно для нормального реверса и было принято решение снимать объективом x20/0.50. Кристалл у ВМ3 достаточно большой (9*7мм навскидку), плюс объектив с бОльшим увеличением (и, соответственно, меньшим полем), это привело к появлению 400 снимков, на 9 мегапикселей каждый, общим объемом 10ГБ.
На проекте панорамы из 400 снимков начал очень сильно тормозить Hugin, по любому действию, особенно долго ставились контрольные точки, секунды по 3 каждая (а их минимум надо было поставить руками 2700 штук). BarsMonster попытался расставить снимки и контрольные точки автоматически, но после двух дней загрузки компа матчер "зашел на второй круг", а сколько кругов понадобится мы не знали, поэтому этот энергозатратный процесс прекратили
В итоге я разбил панораму на два подпроекта по 200 снимков и расставил точки там, по 200 снимков Hugin как-то проекты переварил. Затем собрал две половинки панорамы и попытался их сшить, увы, это оказалось невозможно в различных панорманых инструментах, очень долго и со значительными искажениями по шву (пробовал ICE, PanoFactory, Hugin). Поэтому две половинки были слиты в один общий проект на 400 снимков и предпринята попытка сборки панорамы из него. Предварительная оптимизация и выравнивание снимков думала два дня и мне ждать надоело. Поэтому, увы, пришлось про панораму на 3 гигапикселя 60К*50К забыть, и снизить разрешение исходных снимков в 2 раза. Тут уже предварительная оптимизация часов за 8 смогла снимки расставить. Далее обнаружился очередной барьер - используемый блендер multiblend имеет приниципиальное ограничение в 255 файлов. У него там в переменных под поле номера изображения отведено 8 бит, остальные 24 бита от dword тоже используются, поэтому "в лоб" оно не расширяется. Пришлось долго играться с другими блендерами, были проблемы с совмещением снимков (пятнистые границы), в итоге пришлось вернуться к старому и очень медленному enblend-у. Тут снова (как и у multiblend) вылезло ограничение на размер выходного файла в 2ГБ. Это не файловая система, это ограничение где-то внутри используемых графических библиотек. В итоге разрешение панорамы пришлось еще урезать до 24*21К. В-общем, сплошные компромиссы. И то собиралось 14 часов, вот к утру появился результат
Последний раз редактировалось Vslav; 29.04.2016 в 07:25.
Так он с самого начала у вас работает ? Про ручную простановку меток всё понятно - как правильно сшиваются панорамы ОЗУ/ПЗУ.
Александр, Consul'овед второго уровня.
Я раньше не пробовал проекты панорам с таким большим количеством снимков. С 200 все работает и собирается нормально, с 400 - тормозит сам Hugin и не работает сборщик.
Сборка раньше осуществлялась утилитой multiblend минут за 10 для 100 снимков. 400 снимков в эту утилиту "не влезли", пришлось использовать медленный enblend. Multiblend open-source и небольшой, надо с ним разобраться и перекомпилировать.
Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)
Ваши права
Ответить с цитированием
