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

[Vslav]

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

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

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

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

[Titus]

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

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

[Vslav]

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

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

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

[Titus]

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

[Vslav]

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

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

[MM]

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

[Patron]

Наконец-то получилась рабочая модель процессора ВМ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 ?

[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);
}

[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 никак не реагирует.

[Vslav]

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

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