Цифровая археология: 1801 и все-все-все

Вид для печати

Показывать 40 сообщений этой темы на одной странице

07.10.2015, 13:08
Vslav

Цитата:

Сообщение от Patron

Но всё же может быть интересно уточнить тайминги выставления сигнала RPLY процессором 1801ВМ1 при обращении по шине МПИ к его регистрам - это ведь тоже особенность процессора.

Да, видимо надо будет уточнить. Вообще документацию писать очень занудно, деталей очень много, приходится существенную часть несущественных :) подробностей отсекать, и нет общей цели подменить этой докой, например, тот же ГОСТ. Хотя сейчас я думаю что картинки из ГОСТ-а и описания QBUS было бы неплохо рядом вставить.

Цитата:

Сообщение от Patron

разработчиков ) обязательное требование выравнивания сигнала RPLY на входе процессора по фронту такта CLC при помощи внешней обвязки.

Я детектор этот анализировал долго, в-общем, не совсем понятно что там конкретно происходит, есть сильное подозрение на метастабильность триггера, который защелкивает RPLY по тактовому фронту. Также есть вероятность что глюк в процессоре от августа 1991-го, который мы сфотографировали, уже устранен, поэтому зря искали :). А в целом схема будет надежно работать если RPLY будет стабильным как на фронте так и на срезе тактовой. Поэтому синхронизировать можно любым фронтом, я встречал оба варианта в практических схемах на ВМ1. Внешнее защелкивание RPLY по срезу тактовой даст несколько большее быстродействие.
07.10.2015, 13:36
Titus

Цитата:

Сообщение от Vslav

Также есть вероятность что глюк в процессоре от августа 1991-го, который мы сфотографировали, уже устранен, поэтому зря искали :)

А что за глюк такой?
07.10.2015, 13:52
Vslav

Цитата:

Сообщение от Titus

А что за глюк такой?

Достаточно широкоизвестный, если RPLY поступает на процессор не синхронизированный с тактовой частотой (вероятно, изменяющийся в некоторый момент перед наступлением тактового события, синхронизация устраняет такое изменение - оно начинает происходить в предсказуемый момент), то происходит аппаратное зависание интерфейсного блока ВМ1. Об этом еще разработчики писали, им нужно было запустить плату с процессором 1801ВМ1 к какой-то показухе, а оно подвисало периодически, до утра ковырялись, устранили, а потом уже не следующий день нашли проблему в самом процессоре. Кстати, входы прерываний тоже требуют синхронизациии, а то возможны проблемы.

В-общем, добавил в документ еще диаграммки из ГОСТа, нагляднее стало, понятнее почему оно в процессоре сделано именно таким образом. А то я сокрушался что SYNC так поздно снимается, в PCI-то FRAME снимается достаточно рано :)
07.10.2015, 14:09
Titus

Значит были процы без этого глюка? Как их отличить?
07.10.2015, 14:16
Vslav

Цитата:

Сообщение от Titus

Значит были процы без этого глюка? Как их отличить?

Никто не знает были или нет, я просто предположил что глюк пофиксили, раз явно его не видно. Посмотрел по топологии куда идет вход RPLY и попытался сообразить к чему приведет его изменение в "неподходящий" момент. На логическом уровне ни до чего такого фатального не додумался, возможно дело в физических характеристиках транзисторов, скорости у них небольшие, время метастабильности триггера в 100+ нс вполне может иметь заметную вероятность.
07.10.2015, 15:36
MM

Как проверить ВМ1 на БК0010 на отсуствие глюка по RPLY - надо выв. 39 ВМ1 отрезать от его цепей и присобачить на линию RPLY от БИС платы - если в течении часа на Т4 ( тест непрерывный из МСТД ) не повиснет - значит, процессор хороший.
*
А что за глюк в ВМ1 - если сигнал RPLY приходит через менее чем 200 нс от сигнала DIN, то процессор виснет. Встречал такое на некотрых экз. процессора - но не во всех, единичные экз. отлично работали.
( Процессоры были Ангстремовские, а не самодельные, как некотрые подумали ).
16.10.2015, 13:47
Patron

Цитата:

Сообщение от gid

Наконец-то получилась рабочая модель процессора ВМ1 сконвертированная из верилога в си.

Попытка подключить Verilog-CPP модель 1801ВМ1 в эмулятор ДВК выявила различия в поведении с абстрактной моделью при чтении регистра SEL1 ( в обоих случаях в SEL1 находится значение 000000 ).

Абстрактная модель:

Код:

------------------------------------------------- C AD B S D D W R B I I D D S I H E A D I S S L S Y I O T P S R A M M A N A V C C R L L C Y N N U B L 7 Q K R G C I L N L L 3 1 2 ------------------------------------------------- 1 177716 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 177716 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 177716 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 177716 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 000000 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 000000 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Модель Verilog-CPP ( далее V-модель ) :

Код:

clk ad bsy wtbt sync din dout rply init sel1 000019 177716 1 0 0 0 0 0 0 0 000020 177716 1 0 0 0 0 0 0 0 000020 177716 1 0 1 0 0 0 0 0 000021 177716 1 0 1 1 0 0 0 0 000021 000000 1 0 1 1 0 1 0 0 000022 000000 1 0 1 1 0 1 0 0 000022 000200 1 0 1 1 0 1 0 0 000023 000200 1 0 1 1 0 1 0 0 000023 000200 1 0 1 1 0 1 0 0 000024 000200 1 0 1 0 0 1 0 0 000024 000200 1 0 1 0 0 0 0 0 000025 000000 1 0 1 0 0 0 0 0 000025 000000 1 0 1 0 0 0 0 0 000026 000000 1 0 1 0 0 0 0 0 000026 000000 0 0 0 0 0 0 0 0 000027 000000 0 0 0 0 0 0 0 0 000027 000000 0 0 0 0 0 0 0 0 000028 000000 0 0 0 0 0 0 0 0 000028 000000 0 0 0 0 0 0 0 0

Отсюда вопросы:

1. Может ли ( и должен ли ) реальный процессор 1801ВМ1 считывать значение по адресу 177716 без ожидания и без анализа сигнала RPLY ?

2. Почему V-модель не выставляет SEL1 ( или не выводит в лог выставление SEL1 ) при чтении адреса 177716 ?
16.10.2015, 20:04
Patron

Разобрался почему V-модель не выставляет SEL1. Из-за оптимизации кода для однопроходного вычисления возникла ошибка - использование значения wire.sel177x до его вычисления. Для исправления ошибки нужно перенести вычиcление wire.sel177x в единственное место в коде, где это значение используется:

Код:

if( !m_pINOUTPins->pin_sync_in ) { wire.sel177x = ((m_pINOUTPins->pin_ad_in & 0177700) == 0177700) && (((m_pINOUTPins->pin_ad_in >> 4) & 3) == (m_pINOUTPins->pin_pa & 3)); reg.sel_xx = wire.sel177x; reg.sel_00 = wire.sel177x && (((m_pINOUTPins->pin_ad_in & 0xf) >> 1) == 0); reg.sel_02 = wire.sel177x && (((m_pINOUTPins->pin_ad_in & 0xf) >> 1) == 1); reg.sel_04 = wire.sel177x && (((m_pINOUTPins->pin_ad_in & 0xf) >> 1) == 2); reg.sel_06 = wire.sel177x && (((m_pINOUTPins->pin_ad_in & 0xf) >> 1) == 3); reg.sel_10 = wire.sel177x && (((m_pINOUTPins->pin_ad_in & 0xf) >> 1) == 4); reg.sel_12 = wire.sel177x && (((m_pINOUTPins->pin_ad_in & 0xf) >> 1) == 5); reg.sel_14 = wire.sel177x && (((m_pINOUTPins->pin_ad_in & 0xf) >> 1) == 6); reg.sel_16 = wire.sel177x && (((m_pINOUTPins->pin_ad_in & 0xf) >> 1) == 7); }
16.10.2015, 22:06
gid

Спасибо. Однако я подозреваю, что там не одна такая ошибка.
Там теоретически всё должно было работать, механизм и порядок вычисления assignов и alwaysов был подсмотрен в коде, генерируемом verilatorом.
Идея в том, что wire.sel177x должен вычисляться в assign_all в конце вычисления eval_n, а код, где он используется, находится в eval_all_p.
Но в моём алгоритме есть логический изъян. Между этими действиями производится вывод текущих значений ног проца в МПИ, а затем чтение оттуда, и иногда бывает, что значения меняются, при этом надо бы вернуться назад и пересчитать заново все assign и always, что опять приведёт к изменению значений на ногах проца, в общем я не понял, как избежать либо вечного зацикливания, либо варианта, когда нужное состояние проскакивает мимо.
Я всё равно вернусь к дальнейшей отладке, когда у меня будет больше моделей между которыми можно будет организовать взаимодействие.

---------- Post added at 22:06 ---------- Previous post was at 21:59 ----------

Кстати, насчёт RPLY не знаю, оно там генерируется и выдаётся на шину для других устройств, в случае если данный процессор - пассивное устройство на шине. Но вроде бы когда он сам к своим регистрам обращается, то на своё же RPLY никак не реагирует.
16.10.2015, 22:26
Vslav

Цитата:

Сообщение от gid

Кстати, насчёт RPLY не знаю, оно там генерируется и выдаётся на шину для других устройств, в случае если данный процессор - пассивное устройство на шине. Но вроде бы когда он сам к своим регистрам обращается, то на своё же RPLY никак не реагирует.

Реагирует. Внутренние периферийные регистры надо рассматривать как полную аналогию внешнему устройству, подключенному к шине, только внутри микросхемы. Процессор - это два независимых (с точки зрения шины) блока -периферийный и процессорный. Внутренняя периферия берет сигналы прямо с выводов DIN/DOUT/SYNC, точно так же защелкивает адрес как внешняя, и формирует RPLY (очень быстро, и выход - открытый коллектор). Единственное отличие - корректно рулится направление выводов A/D. То есть при чтении внутренней периферии они работают как выходы в целом, и процессор считывает данные именно с выводов. При записи периферии - для периферии A/D работают входами, а в целом A/D управляет процессор - если пишет то же самое внутреннее ядро то A/D будуn выходами. Если шина захвачена другим агентом - то A/D будут входами. Ну и для 1777x4 и 1777x6 на напревление A/D - своя коррекция. Я как раз табличку пишу на тему.

Показывать 40 сообщений этой темы на одной странице