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

Цитата:

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

Чтобы исправить V-модель на С++ изменения в vm1_qbus.v искать по слову rollback, там ниже новые присваивания psw[0] и psw[3:1]

Если опубликовать необходимые правки для исходника VM1CPP.003a.zip ( вероятно - в файле VM1CPP\vm1cpu\vm1.cpp ) - было бы весьма кстати.

...

И что-то там ещё с ВЕ-таймером не хорошо.

Похоже, будто значение прескалера на входе не изменяется :

VM1VE1.SAV

Код:

.RU VM1VE1 1801VM1 VE-Timer Test #1 VE-Timer ..Not OK Counter: 0 Counter: 0 Counter: 0 Counter: 0 Counter: 0 Counter: 0 Counter: 0 Counter: 0 Counter: 0 Counter: 0 Counter: 0 Counter: 0 VE-Timer ..000 Program completed. .

Добавил SignalTap (альтеровский логический анализатор, встраиваемый в ПЛИС-проект) для модулей на реальных процессорах ВМ1А/Г.
Листинг программы:

Код:

273 001576 000167 000006 entry: jmp 1$ ; 274 001602 111111 .word 111111 275 001604 122222 .word 122222 276 001606 133333 .word 133333 277 278 001610 000167 177762 1$: jmp entry 279 001614 144444 .word 144444 280 001616 155555 .word 155555 281 001620 166666 .word 166666

Результаты:
На ВМ1А, нет дополнительных циклов для инструкции jmp addr: http://s020.radikal.ru/i712/1511/4a/d447aed26bf1t.jpg
На ВМ1Г, есть "зомби" циклы - код инструкции jmp перечитывается дважды: http://s020.radikal.ru/i708/1511/52/d93317a570b0t.jpg

(Картинки длинные и узкие, после двоеточия, на белом фоне, поэтому в теле поста видно плоховато. Маленькие - .png до 100 килобайт, можно смело тыцать)

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

Цитата:

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

Если опубликовать необходимые правки в файле VM1CPP\vm1cpu\vm1.cpp )

Поправил, насколько я разбираюсь в модели. Не компилировал, у меня такой новой студии нету (2005 хватает).

Цитата:

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

И что-то там ещё с ВЕ-таймером не хорошо.

Мне .SAV запускать негде пока, у меня сразу первые 8К ОЗУ/ПЗУ, начальное значение загружается из бинарника при прошивке ПЛИС. Если можно - дайте исходник и поясните в каком месте что не нравится.

Update: обновил стартовый пост темы, добавил актуальные ссылки

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

Ага, там оказывается исходник в архиве.
Пропатчил немного, запустил на реальном процессоре ВМ1Г:

Код:

1801VM1 VE-Timer Test #1 VE-Timer ..OK 177710/000020 177710/000042 177710/000064 177710/000105 177710/000127 177710/000150 177710/000172 177710/000214 177710/000235 177710/000257 177710/000301 177710/000323 VE-Timer ..000

На Wsync:

Код:

1801VM1 VE-Timer Test #1 VE-Timer ..OK 177710/000000 177710/000000 177710/000000 177710/000000 177710/000000 177710/000000 177710/000000 177710/000000 177710/000000 177710/000000 177710/000000 177710/000000 VE-Timer ..000 Program completed.

Косячок-с где-то :)

Цитата:

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

Поправил

CPP-модель работает, ошибки MUL нет.

Цитата:

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

дайте исходник и поясните в каком месте что не нравится

В том виде, в каком я использую модель - ВЕ-таймер почему-то не получает тактирование. Попробую кое-что сам посмотреть, но интересно, что делает pin_ena и как ВЕ-таймер переключается на внешнее тактирование.

Цитата:

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

На ВМ1Г, есть "зомби" циклы - код инструкции jmp перечитывается дважды

Зомби также появляются на всех процессорах ВМ1:

1) При любом использовании PC с методом адресации 0. Если PC используется дважды ( например CMP PC,PC ) - зомби выходит только один.

2) При всех внешних прерываниях вне команды WAIT, при T-trap после установки бита T командой RTT.

3) После команды MTPS Rx. После MTPS PC - зомби выходит только один.

Во всех случаях читается слово по адресу PC. Если команда изменяет PC - в описанных случаях ( в отличие от команд JMP и JSR в ВМ1г ) читается слово по старому значению PC.

Цитата:

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

CPP-модель работает, ошибки MUL нет.

Отлично.

Цитата:

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

В том виде, в каком я использую модель - ВЕ-таймер почему-то не получает тактирование.

Нет, там хитрее оказалось. Регистр счетчика перегружается из регистра предела не просто если счетчик нулевой, а если он перед этим был ненулевой и при счете достиг нуля. То есть - по фронту сигнала tve_zero, а не просто по уровню tve_zero. Это я пропустил детектор фронта tve_zero когда переписывал таймер со схемы, сама транзисторная схема правильная.

Что получалось - в регистр предела программа записала нулевое значение, счетчик также нулевой, tve_zero высокий, поэтому при каждом такте счетчик перегружался нулевым значением из лимита и счета как такового не было (перегрузка имеет приоритет перед декрементом). Если записать ненулевое значение в лимит, то считает нормально.

Внес изменения в таймер, коррекция C++ модели
Надо будет добавить регистровое поле tve_zprev в vm1_qbus_shared.h
На реальной ПЛИС тест заработал нормально.

Цитата:

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

3) После команды MTPS Rx. После MTPS PC - зомби выходит только один.

Да, это уже проверялось на живом ВМ1А, этот зомби точно есть.

Update: файлы таймера для ревизии 1.4b на сервере обновил

Цитата:

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

На реальной ПЛИС тест заработал нормально.

На модели тоже заработал, но есть одна тонкость - по команде RESET вместо

Код:

reg.tve_count = 0; reg.tve_limit = 0;

реальный процессор делает :

Код:

reg.tve_count = snap_reg.tve_limit;

Цитата:

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

На модели тоже заработал, но есть одна тонкость - по команде RESET вместо

Код:

reg.tve_count = 0; reg.tve_limit = 0;

Да, это было добавлено для комфортного моделирования, избавлюсь от обнуления счетчика и предела по tve_reset, добавлю обнуление по dclo, тогда будет инициализация только по аппаратному сбросу всего процессора.

Цитата:

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

реальный процессор делает :

Код:

reg.tve_count = snap_reg.tve_limit;

Нет, из схемы этого не видно, проверил на ВМ1Г - он тоже значение счетчика по RESET не изменяет. По RESET сбрасывается только CSR, счетчик останавливается и сохраняет свое текущее значение.

Цитата:

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

добавлю обнуление по dclo, тогда будет инициализация только по аппаратному сбросу всего процессора

На том реальном ВМ1, который тестировался с моим участием - после включения питания происходило:

Код:

if( wire.pin_dclo ) { reg.tve_limit = 0104014; // random initial value after POWER_ON reg.tve_count = 0177777; // random initial value after POWER_ON }

Поэтому, при первом запуске теста: VM1C1.SAV - результат на реальном ВМ1 выглядел так:

Код:

1801VM1 Timings Test #1a CPU RunTime: 00000:02718 177706/104014 177710/177777 177712/177400 Test 1 ------ 0 0 65535 65535 65535 65535 65535 Test 2 ------ SOB : 27 27 27 27 26 27 27 27 26 27 27 26 Br : 21 21 21 20 20 20 20 21 21 21 20 20 BCS : 20 20 20 20 21 20 20 20 20 20 21 21 BCC : 20 20 20 20 20 20 20 20 20 20 21 20 Nop : 14 13 14 14 14 13 13 14 14 14 14 13 SeC : 14 13 14 14 14 14 13 14 14 13 13 14 Jmp (R0)+ : 27 27 27 26 27 27 27 27 27 27 27 27 Call (R0)+ : 40 40 41 40 41 41 40 40 41 40 41 41 JSR R3,(R0)+ : 40 40 40 40 40 40 40 40 40 41 40 40 Return : 33 34 33 34 33 33 34 33 33 34 33 34 Program completed.

Цитата:

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

По RESET сбрасывается только CSR, счетчик останавливается и сохраняет свое текущее значение.

Значит, в этой части моя абстрактная модель ВЕ-таймера изначально была ошибочна.

Цитата:

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

На том реальном ВМ1, который тестировался с моим участием - после включения питания происходило:

включение питания и команда RESET это разные вещи. При включении питания в регистре счетчика и предела - просто мусор, как триггеры установяться так и будет. По каманде RESET содержимое регистров не изменяется, проверил тестиком. На ПЛИС при включении питания и при сбросе по DCLO (начиная с версии 1.4C) происходит обнуление счетчика, предела и прескайлера.

Цитата:

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

Поэтому, при первом запуске теста

Я не нашел в тексте команду RESET, к тому же любая запись в 177712 приводит к копированию предела в счетчик, мусорное значение, полученное при включении питания, перезаписывается значением из регистра предела.
А ноль в счетчике подзадержался как раз до такта счета (до 128 тактов процессора, зависит от того что было в невидимом 7-битном прескайлере), потому что именно не было фронта tve_zero и не было мгновенной 4-тактовой перегрузки из регистра предела (впрочем там тоже 0). Поэтому тест успел прочитать нулевое значение дважды.

Обновил таймер до ревизии 1.4c

Цитата:

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

любая запись в 177712 приводит к копированию предела в счетчик, мусорное значение, полученное при включении питания, перезаписывается значением из регистра предела

Имелось в виду, что начальные значения счётчика и предела у реальных процессоров: 1)не нулевые; 2)не одинаковые; 3)практически неизменные при каждом включении питания.

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

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

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

Или в старший байт помещать 0210, а в младший - версию прошивки.

Цитата:

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

нулей у реального процессора там не будет.

Ну я бы не стал так утверждать, пока нет никаких специальных исследований по большой выборке - любое значение неопределенно-равновероятно, и ноль в том числе. Про приучение программистов непонятно, если таймер используется без перегрузки, то значение предела и счетчика неважны - предел не используется, счетчик последовательно считает все значения от 0 до 177777. Если с перегрузкой, то нормальный программист пропишет в регистр предела нужное значение. Полагаться каким-либо образом на случайное значение после включения питания - это только для каких-то очень академических тестов. В-общем, предлагаемый ноль в качестве "значения по питанию" ничем не хуже любого другого. Впрочем, нет проблем прописать это любое другое значение.

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

Цитата:

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

Или в старший байт помещать 0210, а в младший - версию прошивки.

Да, идея неплохая. Будем приучать к ней программистов? :)