Вид для печати
Да, точно так.Цитата:
Сообщение от AFZ
То, что есть на сегодня - LSI-11, ВМ1/2. Простая система на них - процессор/память/UART, влезут гарантировано.Цитата:
Сообщение от AFZ
F11 (АКА 1811, 11/23 на нем сделано) тоже, скорее всего, влезет.
Но с расширением (добавить КСМ/КГД или КЦГД) системы уже могут быть нюансы.
Я думаю что второй процессор в КЦГД эмулировать не надо, в случае с ВМ2 быстрое переключение задачи на основной процессор. Для этого нужен какой то конвейер.Цитата:
Сообщение от Vslav
Если конечно такое реализуемо (не силен в этих платах).
- - - Добавлено - - -
Спасибо, пока нет такой необходимости.Цитата:
Сообщение от dk_spb
А платы какие, RX02?
ГМД-7012.Цитата:
Сообщение от MiX
RX разбирать не хотелось бы.
Чтобы получить нормальную реплику нужны именно все процессоры, которые есть в оригинале. Это не проблема сделать несколько инстансов процессора, проблема куда им ходить - память SDRAM на большинстве отладочных плат физически одна, один канал, надо делать многопортовый контроллер SDRAM, разделение доступа, еще и видеоконтроллер туда же обращается, все это порежет быстродействие. Для КСМ/КГД все можно разместить во внутренней памяти FPGA (ВМ80 с программой, порезать символьный экранный буфер до 4К с обновлением прошивки, 16К КГД тоже поместятся), а вот КЦГД и УКНЦ уже потребуют доступа к внешней SDRAM.Цитата:
Сообщение от MiX
Поскольку трудами уважаемого 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 сыпят ошибками "дефект незапланированное прерывание", но это уже отдельная история.
О, большое спасибо за найденную проблему и подробный репорт по ней, я на выходных займусь. Очень приятно, что кто-то стал использовать процессоры в своих проектах.Цитата:
Сообщение от forth32
Опять возникла проблема с процессором ВМ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. Вот осциллограмма выполнения интересующей нас части программы:
Вложение 73004
Поскольку этот форум портит картинки, то я включил этот же файл в нормальном разрешении в приложенный архив. Осциллограмма начинается с момента окончания длинной паузы при обращении к адресу 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-файл для загрузки в симулятор
- приведенную ранее осциллограмму в полном разрешении.
Очень интересно, и большая работа по локализации проблемы проделана, спасибо, будем разбираться.Цитата:
Сообщение от forth32
Как же оно проходит тест 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 или НПТ
Да, это странно, но - законно, согласно документации.Цитата:
Сообщение от forth32
- - - Добавлено - - -
Асинхронная оригинальная модель выводит: "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 просто как запись слова.Цитата:
Сообщение от forth32
Выяснилось что в момент сохранения PSW по прерыванию тайм-аута шины формируется лишний писивр (pc_wr) и CPC получает продвинутое значение.
Источником лишнего писивра является лишний cpsw_stb.
Да я тоже не отказался бы :)Цитата:
Сообщение от forth32
Причина найдена, быстрый фикс:
На выходных потестирую и внесу в репкуКод:vm2_wb.v: line 594
-if (reset | wb_wdone)
+if (mc_res | wb_wdone)
- - - Добавлено - - -
forth32, прогоните пожалуйста на своей системе исправление и расскажите нам о результатах :)