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

[Patron]

Относительно порядка вычисления 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-фронт :



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

[Advertiser]

[Patron]

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

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

[Vslav]

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

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

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

[Patron]

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

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

[gid]

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

[Patron]

После смены местами 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().

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

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

[Patron]

Похоже, я немного поторопился с оправданием текущей 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++;
}

[gid]

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

[Patron]

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

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

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

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

[Patron]

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

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

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