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

Относительно порядка вычисления eval_p и eval_n.

В текущей V-модели считается, что передним фронтом ТЧ является P-фронт, а задним N-фронт, и поэтому сначала вычисляется eval_p, а затем eval_n.

Код:

void tboard::maincycle() { m_pCPU->eval_p(m_nClk, m_pMPI); //отработаем передний фронт ТЧ m_pMemory->eval(m_pMPI); m_pIRPS->eval(m_pMPI); #ifdef OUT_VM1PIN_DBG_LOG OutLog(); #endif m_pCPU->eval_n(m_nClk, m_pMPI); //отработаем задний фронт ТЧ m_pMemory->eval(m_pMPI); m_pIRPS->eval(m_pMPI); #ifdef OUT_VM1PIN_DBG_LOG OutLog(); #endif m_nClk++; }

Но если внимательно разобраться с осциллограммой - становится ясно, что на самом деле всё наоборот и передним фронтом ТЧ является переход CLK из высокого уровня в низкий - т.е. N-фронт :

http://pic.pdp-11.ru/images/sel1.png

Поэтому V-модель начинает давать нормальное распределение сигналов шины по номерам тактов только при смене местами вызовов eval_p и eval_n - только тогда SYNC и DIN устанавливаются на переднем и заднем фронте одного и того же тактового импульса.

В процессе тестирования V-модели выяснилось, что процессор 1801ВМ1 сам выставляет/снимает RPLY через полтакта после DIN и DOUT, если содержимое линий AD15-AD1 в момент выставления SYNC было 0177714 или 0177716.

Т.е. оказывается, что 1801ВМ1 не ждёт прихода RPLY при чтении/записи SEL-регистров не потому, что обращается к ним каким-то особенным способом, а потому, что сам себе при этом выставляет RPLY.

Цитата:

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

если содержимое линий AD15-AD1 в момент выставления SYNC было 0177714 или 0177716.

Странно, должен выставлять "сам себе" и для других регистров внутренней периферии (таймер/регистры ошибки). За исключением регистра 177702 (там пауза есть, ожидает окончания несуществующего стартового прерывания ведового процессора, поэтому регистр +02 "отпадает" после первой записи, и до команды EMT - там еще одна ошибка в процессоре), выходной RPLY очень просто формируется - ~((~nDIN | ~nDOUT) & (addr == 1777xx)). То есть снятие/выставление RPLY внутренней периферией мгновенное, только физическими задержками схемы определяется. Кстати, измеряя эту задержку - хороший способ оценить качество конкретной микрохемы.

Да, и выход RPLY у ВМ1 - открытый коллектор, чтобы не было конфликта с внешним RPLY - ставят резистор, в БК например 510 Ом.

Цитата:

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

должен выставлять "сам себе" и для других регистров внутренней периферии (таймер/регистры ошибки).

В том и дело - что регистры SEL1 и SEL2 внешние и их данные выставляются на шину не процессором, а материнской платой. Но RPLY при обращении к этим внешним адресам процессор 1801ВМ1 выставляет сам, поэтому если регистры SEL1 / SEL2 на шине не отвечают - вместо прерывания зависания происходит чтение нуля.

После смены местами eval_p и eval_n перестаёт проходить тест 79404. Подозреваю, что из-за некорректно реализованного источника векторного прерывания. Но при этом , потоковый дизассемблер тоже начинает выдавать какую-то ерунду, по которой я так и не понял, в каком месте случилась неприятность, то ли тест WAIT не прошёл, то ли предыдущий тест. Нужно реализовать отладочный пульт, куда бы вываливалось исполнение программы по HALT, но я пока совершенно другими делами занят.

Цитата:

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

После смены местами eval_p и eval_n перестаёт проходить тест 79404.

Более того - когда я добавил отладочную печать внутрь vm1_qbus.cpp для печати входных и выходных сигналов процессора в начале и конце eval_all_p() и eval_all_n(), то результат получился такой:

Код:

clk ad bsy wtbt sync din dout rply > 000060 000202 1 0 0 0 0 0 < 000060 000202 1 0 0 0 0 0 > 000060 000202 1 0 0 0 0 0 < 000060 000202 1 0 0 0 0 0 > 000061 000202 1 0 1 0 0 0 < 000061 000202 1 0 1 0 0 0 > 000061 000000 1 0 1 1 0 0 < 000061 000000 1 0 1 1 0 0 > 000062 000000 1 0 1 1 0 0 < 000062 000000 1 0 1 1 0 0 > 000062 000000 1 0 1 1 0 0 < 000062 000000 1 0 1 1 0 0

Выходит, что правильное распределение сигналов по номерам тактов получается как раз при исходном порядке eval_p() и eval_n().

Также, если между eval_n() и eval_p() не обрабатывать реакцию памяти на сигналы шины - то процессор зависает, тогда как функции eval_p() и eval_n() можно ( похоже ) вызывать сразу одну за другой, не делая вообще ни каких дополнительных обработок сигналов между ними. Поэтому для синхронного адаптера ( с только одной обработкой внешних сигналов на каждом такте ) - годится лишь исходный порядок eval_p() и eval_n().

Цитата:

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

Нужно реализовать отладочный пульт, куда бы вываливалось исполнение программы по HALT

V-модель уже запустилась в эмуляторе ДВК вообще без переделок исходного кода, поэтому после небольшой доработки адаптера МПИ - можно будет использовать эмулятор ДВК в качестве тестового стенда.

Похоже, я немного поторопился с оправданием текущей V-модели, так как не учёл, что после eval_all_p() и eval_all_n() выполняются ещё и assign_all().

Если поставить отладочную печать после assign_all() :

Код:

/* Выполнение модели по переднему фронту ТЧ */ void vm1_qbus::eval_p(int nClk, VM1_QBUS_INOUT *pINOUT) { m_pINOUTPins = pINOUT; m_nClk = nClk; InLog('p'); eval_all_p(); //выполняем все always для переднего фронта assign_all(); //вычисляем все assignы OutLog('p'); } /* Выполнение модели по заднему фронту ТЧ */ void vm1_qbus::eval_n(int nClk, VM1_QBUS_INOUT *pINOUT) { m_pINOUTPins = pINOUT; m_nClk = nClk; InLog(' '); eval_all_n(); //выполняем все always для заднего фронта assign_all(); //вычисляем все assignы OutLog(' '); }

То проблема с неправильным распределением сигналов по тактам встаёт во весь рост:

Код:

clk ad bsy wtbt sync din dout rply p> 000019 000000 0 0 0 0 0 0 p< 000019 000000 0 0 0 0 0 0 > 000019 000000 0 0 0 0 0 0 < 000019 177716 1 0 0 0 0 0 p> 000020 177716 1 0 0 0 0 0 p< 000020 177716 1 0 0 0 0 0 > 000020 177716 1 0 0 0 0 0 < 000020 177716 1 0 1 0 0 0 p> 000021 177716 1 0 1 0 0 0 p< 000021 000000 1 0 1 1 0 0 > 000021 000000 1 0 1 1 0 0 < 000021 000000 1 0 1 1 0 1

Если же поменять местами выполнение eval и assign :

Код:

/* Выполнение модели по переднему фронту ТЧ */ void vm1_qbus::eval_p(int nClk, VM1_QBUS_INOUT *pINOUT) { m_pINOUTPins = pINOUT; m_nClk = nClk; InLog('p'); assign_all(); //вычисляем все assignы eval_all_p(); //выполняем все always для переднего фронта OutLog('p'); } /* Выполнение модели по заднему фронту ТЧ */ void vm1_qbus::eval_n(int nClk, VM1_QBUS_INOUT *pINOUT) { m_pINOUTPins = pINOUT; m_nClk = nClk; InLog(' '); assign_all(); //вычисляем все assignы eval_all_n(); //выполняем все always для заднего фронта OutLog(' '); }

То распределение входных и выходных сигналов по фронтам становится идеальным:

Код:

clk ad bsy wtbt sync din dout rply p> 000019 000000 0 0 0 0 0 0 p< 000019 177716 1 0 0 0 0 0 > 000019 177716 1 0 0 0 0 0 < 000019 177716 1 0 0 0 0 0 p> 000020 177716 1 0 0 0 0 0 p< 000020 177716 1 0 1 0 0 0 > 000020 177716 1 0 1 0 0 0 < 000020 000000 1 0 1 1 0 0 p> 000021 000000 1 0 1 1 0 0 p< 000021 000000 1 0 1 1 0 1 > 000021 000000 1 0 1 1 0 1 < 000021 000000 1 0 1 1 0 1

Но с синхронным адаптером процессор зависает в ходе выполнения первой же команды.

Кстати, при вычислении assign перед eval сигнал SEL1 должен корректно устанавливаться даже в исходной версии V-модели, что дополнительно указывает на верность такого подхода.

Чтобы воспроизвести проблему зависания модифицированной V-модели при работе с синхронным адаптером МПИ - достаточно убрать обработку сигналов шины между eval_p и eval_n :

Код:

void tboard::maincycle() { m_pCPU->eval_p(m_nClk, m_pMPI); //отработаем передний фронт ТЧ // m_pMemory->eval(m_pMPI); // m_pIRPS->eval(m_pMPI); #ifdef OUT_VM1PIN_DBG_LOG OutLog(); #endif m_pCPU->eval_n(m_nClk, m_pMPI); //отработаем задний фронт ТЧ m_pMemory->eval(m_pMPI); m_pIRPS->eval(m_pMPI); #ifdef OUT_VM1PIN_DBG_LOG OutLog(); #endif m_nClk++; }

Вложений: 1

Внутри m_pMemory и m_pIRPS обработка сигналов МПИ задана крайне простым конечным автоматом, который переключает свои состояния при любом фронте ТЧ, поэтому если закомментировать половину вызовов, эти модули могут начать работать некорректно, т.е. в 2 раза медленнее, я вместо них планировал также использовать V-модели, а пока - это просто заглушки, чтобы хоть как-то обеспечить работоспособность модели процессора. А вообще - у Си реализации модели очень большая проблема с третьими состояниями сигналов на шине. Я кое-как реализовал их подобие, после чего модель стала проходить тест 791401, но там тоже есть некоторые допущения, когда третье состояние, не совсем третье, а 0.
Я сейчас осваиваю верилог, чтобы лучше понимать, что я вообще делаю, и как оно должно работать, чтобы потом вернуться к проекту.
Вот вариант с некоторыми оптимизациями, я постарался уменьшить количество ненужных присваиваний, чтобы не гонять переменные туда-сюда в памяти зазря.
Вложение 53803

Цитата:

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

эти модули могут начать работать в 2 раза медленнее

От качества эмуляции памяти глюк не зависит, в эмуляторе ДВК с модифицированной V-моделью та же история - после первого же цикла шины процессор останавливается и вообще перестаёт реагировать на тактовую частоту, бесконечно удерживая сигналы BSY и SYNC в конце цикла чтения.

Цитата:

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

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

Как выяснилось, V-модель процессора 1801ВМ1 примерно в 200 раз медленнее её абстрактного потактового аналога, поэтому единственное реальное требование к ней - полная корректность, позволяющая безошибочно "обучить" абстрактную МПИ-модель до полной потактовой совместимости с реальным процессором 1801ВМ1.

Посмотрел вторую версию VM1CPP и считаю, что это движение в неправильном направлении.

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

Во второй версии в V-модель встроен интерфейс конкретного эмулятора МПИ, что требует изменений исходного кода для подключения такой V-модели к другим эмуляторам МПИ.