Реверс-инжиниринг УКНЦ (1515ХМ1&2, 1801ВП1, 1801ВМ2)

[Titus]

В общем, интересные моменты в блоке таймаута.

Например, выполняется команда MOV R1,R0, за которой следует несуществующая ячейка памяти.
После выполнения инструкции на микрокоманде 0x01 (выборка следующей инструкции) происходит ошибка таймаута памяти (т.к. запрошенное кэширование инструкции в предыдущей команде 0x01 не получило ответа).
Блок таймаута смотрит и говорит - ага, ошибка чтения чтения была в цикле IO_RCD (а этот цикл генерируется только в командах 0x01, 0x10 и 0x16 для кэширования следующей инструкции). После чего блок таймаута дает фальшивый RPLY (TO_RPLY), который завершает цикл чтения, затем дает сигнал ABORT (сбросить микропрограммный автомат и стартовать с микрокоманды 0x01). При этом устанавливается флаг IX1=1, что говорит микропрограмме, что чтение в кэш накрылось медным тазом, и надо отмотать PC на два байта назад, и начать с команды 0x21. После чего выполняется команда 0x21 (запрос кэширования инструкции), и затем опять 0x01.
Но повторный цикл чтения несуществующей ячейки уже выполняется не в цикле IO_RCD, а в цикле IO_CMD, т.к. запрошен из команды 0x21. Поэтому когда наступает таймаут, блок таймаута не генерирует фальшивый RPLY, a сразу дает ABORT и TOVF (запрос прерывания по ошибке шины).

И тут возникают некоторые нюансы.
1. Ошибочный цикл чтения запрошенный командой 0x01 не порождает прерывание по ошибке шины, а делает повторную попытку прочитать инструкцию, но уже микрокомандой 0x21.
2. Если цикл чтения был изначально запрошен командой 0x21 (например, после любой команды, сбрасывающей кэш, т.к. использует его содержимое или меняет PC), то прерывание по ошибке шины произойдет сразу.

Если во время ошибочного цикла чтения пришел запрос на какое-то прерывание, то:
1. В случае команды 0x01 это прерывание нормально обработается сразу после окончания ошибочного цикла.
2. В случае команды 0x21 сперва будет вызвано прерывание по ошибке шины, и только потом может быть обработано запрошенное прерывание.

И еще несколько нюансов.
1. Если во время команды 0x01 была ошибка шины и при этом был запрос прерывания, то этот запрос обработается нормально, но PC будет с опережением на 2, т.к. в начале следующей повторной команды 0x01 не выполняется коррекция PC=PC-2, а сразу уходит на обработку прерывания.
2. На сколько я понимаю, с обработчиком прерывания по ошибке шины происходит та же фигня - PC на 2 больше, чем адрес ошибки.

[Advertiser]

[Vslav]

Ибо, это два важнейших сигнала из-за которых все и затевалось)

Ну если так - перекачай , я обновил диаграммы.

[Titus]

Ну если так - перекачай , я обновил диаграммы.

Мои теоретические графики совпали)

[Vslav]

Мои теоретические графики совпали)

Не может быть! Это ты уже отмечать начал?

[hobot]

Ну если так - перекачай , я обновил диаграммы.

Мои теоретические графики совпали)

[Titus]

Не может быть! Это ты уже отмечать начал?

Я не пью от слова совсем)

[Alex_K]

Надо сделать тест типа ADD -(PC),R5, тогда мы хотя бы косвенно сможем понять, сколько раз эта команда выполнилась по итоговой сумме.

Сделал. Сама программа:

1000 005000 CLR R0
1002 005001 CLR R1
1004 005002 CLR R2
1006 005003 CLR R3
1010 005005 CLR R5
1012 010505 MOV R5,R5
1014 064705 ADD -(PC),R5
1016 005200 INC R0
1020 005201 INC R1
1022 005202 INC R2
1024 005003 INC R3
1026 000000 HALT

На первом рисунке УКНЦ ещё не прогрелся, потому и результаты плавают: то R1 увеличится не на два, то оба регистра R0 и R1 увеличатся только на один. Потом всё устаканилось (на втором рисунке) - складываются сама команда ADD -(PC),R5 и следующая за ней команда INC R0. На первом рисунке есть случай, что прибавилась только команда INC R0.

[Titus]

На первом рисунке УКНЦ ещё не прогрелся, потому и результаты плавают

А чего это они плавают, у нас же цепочка задержки по SYNC стоит только у ПП, а у ЦП не стоит?

- - - Добавлено - - -

По тестам все верно выходит, ADD -(PC),R5 выполняется два раза, как я и описывал выше.

- - - Добавлено - - -

Может быть и тот второй тест с NOP'ами поэтому я не мог разложить на микрокод, т.к. там плавали времянки как в первом скриншоте тут?

[Alex_K]

А чего это они плавают, у нас же цепочка задержки по SYNC стоит только у ПП, а у ЦП не стоит?

Хоть стоят и кварцевые генераторы, но при нагреве частота чуть уплывает, становится медленнее. Да и задержка чтения памяти в ЦП определяется видеоадаптером, а они с ЦП тактируются по разному. Так что задержка по SYNC тут особо и не при чём, тут сказывается задержка между DIN и RPLY.

[Titus]

Хоть стоят и кварцевые генераторы, но при нагреве частота чуть уплывает, становится медленнее. Да и задержка чтения памяти в ЦП определяется видеоадаптером, а они с ЦП тактируются по разному. Так что задержка по SYNC тут особо и не при чём, тут сказывается задержка между DIN и RPLY.

Тут чего-то не так.
Уплывание частоты на кварцевом резонаторе столь ничтожное, что сказываться не может.
Тактируются по-разному, но оба кварцами, тоже уплывать нечему.
Единственный вариант, это ПП плавая сам, утягивает за собой все остальные времянки, т.к. когда он пишет в видеопамять, отбирается временной слот памяти у ЦП.
Хорошо бы тесты проводить при ПП крутящемся в холостом цикле.