Да, точно так.Сообщение от AFZ
То, что есть на сегодня - LSI-11, ВМ1/2. Простая система на них - процессор/память/UART, влезут гарантировано.
F11 (АКА 1811, 11/23 на нем сделано) тоже, скорее всего, влезет.
Но с расширением (добавить КСМ/КГД или КЦГД) системы уже могут быть нюансы.
Я думаю что второй процессор в КЦГД эмулировать не надо, в случае с ВМ2 быстрое переключение задачи на основной процессор. Для этого нужен какой то конвейер.
Если конечно такое реализуемо (не силен в этих платах).
- - - Добавлено - - -
Спасибо, пока нет такой необходимости.
А платы какие, RX02?
ГМД-7012.
RX разбирать не хотелось бы.
Чтобы получить нормальную реплику нужны именно все процессоры, которые есть в оригинале. Это не проблема сделать несколько инстансов процессора, проблема куда им ходить - память SDRAM на большинстве отладочных плат физически одна, один канал, надо делать многопортовый контроллер SDRAM, разделение доступа, еще и видеоконтроллер туда же обращается, все это порежет быстродействие. Для КСМ/КГД все можно разместить во внутренней памяти FPGA (ВМ80 с программой, порезать символьный экранный буфер до 4К с обновлением прошивки, 16К КГД тоже поместятся), а вот КЦГД и УКНЦ уже потребуют доступа к внешней SDRAM.
hobot(14.06.2020)
Поскольку трудами уважаемого VSLAV у нас теперь есть FPGA-версия ВМ2, то я наконец собрался сделать себе FPGA-вариант платы МС1201.02, стоящей в нашем испытательном стенде, поскольку уже надоело ловить глюки оригинальной платы. И вот тут возникла небольшая проблема.
В оригинальном процессоре имеется выход SEL, используемый как для выбора теневого адресного пространства (HALT), так и для безадресного чтения регистра режима начального пуска. Как я понял, в wishbone-варианте процессора этого выхода нет, вместо него используется adr[16] для выбора адресного пространства и отдельный выход vm_una для чтения регистра запуска, при этом чтение происходит через вход wbi_dat, через который процессор принимает векторы прерываний. В референсной схеме от VSLAV эту функцию выполняет контроллер прерываний wbc_vic.
Так вот, что бы я ни подсовывал на вход rsel контроллера прерываний, процессор всегда брал стартовый вектор с адреса 0. А нужен мне адрес 140000, по которому лежит теневое ПЗУ 055. В итоге оказалось, что проблема вылезла вот из-за этого кода в контроллере прерываний:Здесь в списке условий if прописано "&wb_irq_o", а поскольку при безадресном чтении никаких запросов прерывания не формируется, то условие выполнено не будет и содержимое rsel никогда не попадет на шину. Здесь, я думаю, надо написать "& (wb_irq_o | wb_una_i)", а лучше вообще всю эту часть условия выкинуть.Код:if (wb_stb_i & ~wb_ack_o & wb_irq_o) if (wb_una_i) wb_dat_o <= rsel; else wb_dat_o <= trunc_w16(ivec >> (nvec*16));
В результате монитор 055 вполне нормально запустился и работает. Правда, тесты начиная с T3 сыпят ошибками "дефект незапланированное прерывание", но это уже отдельная история.
О, большое спасибо за найденную проблему и подробный репорт по ней, я на выходных займусь. Очень приятно, что кто-то стал использовать процессоры в своих проектах.
hobot(23.06.2020)
Опять возникла проблема с процессором ВМ2. Только теперь без помощи общества я сходу не разберусь.
Как я уже писал, я начал делать FPGA-версию платы МС1201.02, для замены окончательно сдохшего контроллера в нашем оборудовании. Не точную, конечно, версию, а функциональный аналог, на основе wishbone-варианта ВМ2. Описал схему, подключил в теневое адресное пространство ПЗУ 055. Схема заработала, и я начал развлекаться с пультовыми командами. И тут оказалось, что тесты, начиная с Т3 (тест процессора) нормально не идут:
И вот такой дефект - НЕЗАПЛАНИРОВАННОЕ ПРЕРЫВАНИЕ, вылезает и на всех последующих тестах. Пришлось брать в зубы IDA и разбираться в коде 055. В конце концов причина была найдена, и она оказалась настолько странной, что приходится обращаться к общественности.Код:@T0 *** test sistemnoj pamqti *** prowerka okon~ena *** test ozu *** pamqtx 020000 -157776 pamqtx 000600 -017776 prowerka okon~ena *** test prc *** defekt nezaplanirowannoe prerywanie 170406 @
Проблема оказалась в обработке прерывания по зависанию шины. Если после выдачи строба данных процессор не получит ответа в течении 128 тактов, он должен вызвать прерывание по вектору 4. И вот этот процесс происходит неправильно. Вот тестовая программа, моделирующая такую ситуацию. Это упрощенный вариант одного из тестов, выполняемых по Т3.
Здесь устанавливается обработчик прерывания 4, а затем происходит обращение к отсутствующему адресу 177776. Согласно документации, процессор должен при этом затолкать в стек текущий PS, затем адрес следующей команды, то есть 000032. Однако в реальности тест завершается так:Код:6 000000 000010 .WORD START ; вектор начального пуска 7 000002 000000 .WORD 0 8 9 000010 .= 10 10 START: 11 000010 012706 000410 MOV #410,SP ; рабочий стек 12 000014 012737 000036 000004 MOV #trap4, @#4 ; устанавливаем новый обработчик trap4 13 000022 005037 000006 CLR @#6 14 000026 005037 177776 CLR @#177776 ; обращемся к отсутствующему адресу 15 RADR: 16 000032 000167 000106' JMP ERR0 ; сюда приходим, если не произошло прерывание 17 ;---------------------------------------------------------------------- 18 trap4: 19 000036 022716 000032 CMP #RADR, (SP) ; проверяем сохраненный в стеке адрес 20 000042 001005 BNE ERR1 21 ; Тест успешно завершен 22 000044 012703 000246 MOV #MSGOK,R3 23 000050 004767 000120' CALL printstr 24 000054 000420 BR STOP 25 ; Адреса не совпали 26 ERR1: 27 000056 011603 MOV (SP), R3 ; это адрес из стека 28 000060 004767 000172' CALL PNUM 29 000064 012703 000032 MOV #RADR,R3 ; а вот такой он должен быть 30 000070 004767 000172' CALL PNUM
То есть в стек затолкалось не 000032, а 000034! В результате адрес возврата стал указывать аж на середину следующей команды. Возврат по такому вектору приведет к непредсказуемому результату.Код:000034 000032 COMPARE ERROR
Эту ситуацию легко повторить, используя тестовый стенд de0_top, идущий в комплекте с wishbone-вариантом процессора. Достаточно прогрузить в его память RAM16K вышеприведенную программу (я ее прикладываю к этому сообщению) и запустить ее - в консоль тут же будут выведены оба адреса, реальный и ожидаемый . На всякий случай я, используя этот же испытательный стенд, промоделировал работу программы в Modelsim. Вот осциллограмма выполнения интересующей нас части программы:
Поскольку этот форум портит картинки, то я включил этот же файл в нормальном разрешении в приложенный архив. Осциллограмма начинается с момента окончания длинной паузы при обращении к адресу 177776. На картинке можно увидеть такие этапы:
0. Процессору надоело ждать ответа, и он снимает строб данных wb_stb.
1. Зачем-то выставляется строб UNA и процессор читает безадресный регистр начального запуска. Зачем - я в упор не понимаю. Вот если бы это было специальное прерывание пультового режима - тогда понятно. А у нас обычное прерывание 4.
2. Процессор заталкивает в стек PS (в данном случае 4) по адресу 406.
3. Затем в стек заталкивается PC возврата по адресу 404. И его значение - 34, а не 32. Что и требовалось доказать.
4. Далее читается вектор 4 и по нему передается управление, как обычно. Это уже нам не интересно.
В результате мы имеем воспроизводимую странность в поведении процессора. Конечно, все можно было бы списать на мои кривые руки и глюки FPGA. Но я использовал для тестов образцовую схему от VSLAV, а ошибка воспроизводится и в симуляторе. Может быть, я плохо понимаю работу процессора, и он по какой-то причине как раз и должен формировать такой вот странный адрес? Но авторы теста T3 так не считают, да и на реальных платах Т3 проходит без ошибок. Получается, что процессор действительно ведет себя неправильно.
Но вот чтобы разобраться в проблеме дальше, надо понимать, как устроены кишки процессора. А там всякие конвейеры, микропрограммные автоматы и прочая жуть, в которой за пару вечеров не разобраться. Поэтому я и прошу помощи у людей, которые уже разобрались в кишках процессора и понимают, как там все работает. Можно просимулировать мою тестовую программу в modelsim и посмотреть, что там внутри процессора происходит и почему он формирует такой странный адрес.
Прикладываю архив, который содержит:
- исходник и листинг тестовой программы
- mif-файл для загрузки в память FPGA
- mem-файл для загрузки в симулятор
- приведенную ранее осциллограмму в полном разрешении.
Очень интересно, и большая работа по локализации проблемы проделана, спасибо, будем разбираться.
Как же оно проходит тест 791404, там есть проверка сохраненного адреса в стеке:
- - - Добавлено - - -Код:ctrap: mov #btrap, rtrap5 ; mov #buff, SP ; tstb -(R0) ; dtrap: inc R0 ; cmp R0, corh ; beq trapb ; mov #241, @#$fatal ; inc @R2 ; halt ; ; btrap: mfps status ; tst status ; beq 1$ ; mov #242, @#$fatal ; inc @R2 ; halt ; ; 1$: cmp buff-4, #dtrap ; beq ctrap ; ; auto1: mov #243, @#$fatal ; inc @R2 ; halt ; неверная запись PC или НПТ
Да, это странно, но - законно, согласно документации.
- - - Добавлено - - -
Асинхронная оригинальная модель выводит: "COMPARE SUCCESS".
Cинхронная модель выводит: "COMPARE SUCCESS".
Wishbone модель сохраняет в стеке 348
Получается это я привнес ошибку, или тайминг шины быстрее стал, надо разбираться.
- - - Добавлено - - -
И в синхронной и в вишбон моделях, PC1/PC2 ведут себя абсолютно одинаково, везде 348 на момент записи адреса возврата в стек, только синхронная записывает 328, а вишбон - 348. В ALU в этот момент нет операции вычитания, любопытно, откуда же всплывает 328?
- - - Добавлено - - -
PC как такового в ВМ2 нет, там только опережающие PC1 и PC2. А для прерываний и HALT режима есть CPC. Вон он оказывается разный.
Я вроде как разобрался, почему тест t404 проходит правильно. Дело в том, что там для проверки используется байтовый способ адресации:А в моем тесте используется словный - CLR @#177776. Если в моем тесте CLR заменить на CLRB - то тест сразу начинает проходить правильно, COMPARE SUCCESS.Код:mov #memlim+1, R0 ctrap: mov #btrap, rtrap5 ; новый обработчик TRAP4 mov #buff, SP tstb -(R0) ; ловим байтовое обращение по адресу memlim
В очередной раз убеждаюсь, что придумать тест, проверяющий все ситуации, невозможно. В этом t404 проверяются всякие самые дикие ситуации, а вот эту проблему он не видит. Правда, тест рассчитан на реальные процессоры, вряд ли в них возможна такая проблема.
Ой как там все сложно. Блин, аж завидно даже. Хотел бы я вот с такой легкостью рассуждать о схеме этого процессора. Похоже, придется все же сесть и разобраться в его потрохах, хотя бы для тренировки мозга. Тем более что и фирменная дока на него есть.PC как такового в ВМ2 нет, там только опережающие PC1 и PC2. А для прерываний и HALT режима есть CPC. Вон он оказывается разный.
У ВМ2 CLRB транзакция проходит как чтение-модификация-запись, а CLR просто как запись слова.
Выяснилось что в момент сохранения PSW по прерыванию тайм-аута шины формируется лишний писивр (pc_wr) и CPC получает продвинутое значение.
Источником лишнего писивра является лишний cpsw_stb.
Да я тоже не отказался бы
Причина найдена, быстрый фикс:
На выходных потестирую и внесу в репкуКод:vm2_wb.v: line 594 -if (reset | wb_wdone) +if (mc_res | wb_wdone)
- - - Добавлено - - -
forth32, прогоните пожалуйста на своей системе исправление и расскажите нам о результатах
Последний раз редактировалось Vslav; 01.07.2020 в 16:35.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием