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

[Patron]

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

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

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

Ещё один вопрос. Когда процессор осуществляет цикл DATO, что при этом происходит на линиях AD - сначала процессор выставляет адрес и этот адрес виден на шине вплоть до выставления данных записи, которые не снимаются вплоть до выставления адреса следующего за записью цикла или как-то ещё..

Судя по доступным осциллограммам циклов чтения, где ВМ1 держит адрес на шине "до упора" - от него вполне можно ожидать такого же поведения и при выставлении данных записи.

Есть какие-нибудь осциллограммы циклов записи в исполнении реального ВМ1 ?

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

[Advertiser]

[Vslav]

Ещё один вопрос. Когда процессор осуществляет цикл DATO, что при этом происходит на линиях AD - сначала процессор выставляет адрес и этот адрес виден на шине вплоть до выставления данных записи, которые не снимаются вплоть до выставления адреса следующего за записью цикла или как-то ещё.

Картинка с циклами записи и чтения-модификации записи (.png 70КБ, после двоеточия между скобок): ()
Листинг кода:

 
    268	001576	012706 	000710 		entry:		mov	#$stack, SP		;
    269	001602	005267 	177102 				inc	$ticks			;
    270	001606	012767 	001122 	177304 			mov	#$rxbuf, $rxend		;
    271	001614	012767 	001122 	177274 			mov	#$rxbuf, $rxbeg		;
    272	001622	012767 	000716 	177064 			mov	#$txbuf, $txend		;
    273	001630	012767 	000716 	177054 			mov	#$txbuf, $txbeg		;
    274											;
    275	001636	012700 	014001 				mov	#14001, R0		;
    276	001642	004767 	177564 				jsr	PC, outhex		;
    277											;
    278	001646	012737 	000100 	177560 			mov	#100, @#RXCSR		;
    279	001654	012737 	000000 	177564 			mov     #000, @#TXCSR		;
    280	001662	005000 					clr	R0			;
    281	001664	106400 					mtps	R0			;

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

Один отсчет на картинке составляет 10 нс (частота дискретизации анализатора 100МГц, поэтому единицы наносекунд ловить не имеет смысла), частота процессора 5 МГц.
На шине собственно процессора установлены резисторы 2K2, подтягивающие на +3.3V (процессор вообще на вход получает высокое логическое +3.3V а не 5V, на всем модуле, на скорость это почти не влияет). Анализатор подключен к пинам ПЛИС изнутри, то есть, грубо говоря, к кабелю, который соединяет платы DE0 и модуля. Данные AD проходят на этот кабель от процессора через шинные формирователи типа АП6 (74LVC245), задержка там небольшая, 5нс примерно. Направление шинного формирователя определяется сигналом st_ena (добавил на новой картинке) с задержкой 10 нс. Когда это сигнал низкий - значение на AD формируется платой DE0, высокий - трансляция с шины процессора. Если выводы AD процессора в высокоимпедансном, то резисторы формируют высокий и анализатор видит 000000 (инвертирует значение у себя, для удобства). Остальные входные сигналы проходят от процессора на анализатор через MAX3064-7 с задержкой порядка 5-10нс. Выходные (например rply + меры по исключению конфликта) формируются DE0 и этой задержки нет.

PS Судя по картинке, при чтении процессор удерживает адрес еще 20-30нс после активации DIN, вполне соответствует постоянной времени линии с резистором 2К2 и 10-15пФ емкостью.

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

Вот я раньше приводил фотографию - пины ПЛС на плате DE0 выходят в итоге на кабель, анализатор захватывает значения с кабеля. Видны также шинные формирователи, буферная MAX3064 и куча резисторов возле пустого слота второго процессора - шина там общая.



Осциллограммы с SignalTap стало получать достаточно просто, в пару кликов в Квартусе, надо будет еще быстренько модуль с ВМ2 запустить, тоже посмотреть чего там происходит.

Update: на кабеле тоже установлены резисторы на +3.3V, но уже 22К, так что ничего свободно не болтается. И да, это же картинка получена не с симулятора. Симулятор мог бы вычислить из модели и показать Z-состояние. А суровый челябинский анализатор может физически измерить и показать только логические уровни 0 или 1.

[hobot]

Вот я раньше приводил фотографию - пины ПЛС на плате DE0 выходят в итоге на кабель, анализатор захватывает значения с кабеля. Видны также шинные формирователи, буферная MAX3064 и куча резисторов возле пустого слота второго процессора - шина там общая.

Очень хочется с настоящим ретро-подлинным ВМ2 увидеть снимок и анализ конечно, вопрос камушек ВМ2 какой предполагается пластик или керамика? Насколько живучесть старых процессоров позволит их использовать, не будет ли с этим лишних проблем, причём я все цело за "родные сердечки на платах" поэтому и вопрос такой задаю (извиняюсь если немного не научно прозвучало).

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

ВМ1 и ВМ2 по площади разные и не совместимы, то есть топология платы под ВМ2 будет другой и однопроцессорной? (скорее констатация чем вопрос).

[Patron]

Судя по картинке, при чтении процессор удерживает адрес еще 20-30нс после активации DIN

Если округлить до целых тактов - картина такая:

1. Адрес снимается процессором на том же такте, на котором устанавливаются SYNC и DIN - в конце такта SYNC и DIN активны, на AD нули.

2. Данные записи выставляются на том же такте, что и DOUT.

3. Данные записи снимаются на следующем такте после снятия DOUT.

4. Сигнал WTBT в фазе адреса снимается на том же такте, на котором устанавливается SYNC.

5. SYNC снимается на следующем такте после снятия RPLY.

6. В цикле DATO между тактом установки SYNC и тактом установки DOUT проходит ещё один такт.

7. В цикле DATIO между тактом снятия RPLY и тактом установки DOUT проходит ещё один такт.


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

Осциллограммы с SignalTap стало получать достаточно просто, в пару кликов в Квартусе.

Тогда есть смысл посмотреть ещё и на поведение сигнала WTBT при байтовой записи.

[Vslav]

Очень хочется с настоящим ретро-подлинным ВМ2 увидеть снимок и анализ конечно, вопрос камушек ВМ2 какой предполагается пластик или керамика?

Пока есть только снимок

Насколько живучесть старых процессоров позволит их использовать, не будет ли с этим лишних проблем

1801ВМ1Г 89 года выпуска корректно отмолотил 12 часов на заводском тесте 401 на 7.2МГц, без всяких замечаний, 1801ВМ2 не должен быть хуже.

причём я все цело за "родные сердечки на платах" поэтому и вопрос такой задаю (извиняюсь если немного не научно прозвучало).

Еще приятно что получается сделать ПЛИС-реплику и переходник к реальному модулю в рамках одного интерфейса. То есть, в БК на ПЛИС достаточно заменить одну строчку и она будет работать на реальном процессоре вместо копии, и наоборот.

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

Тогда есть смысл посмотреть ещё и на поведение сигнала WTBT при байтовой записи.

Байтовая запись и байтовая чтение-модификация-запись: ()
Подтверждение прерывания по приему от 065: ()

[Patron]

Байтовая запись и байтовая чтение-модификация-запись

Получается, как и в модели - сигнал WTBT при записи байта устанавливается на предыдущем такте перед установкой DOUT, а снимается на следующем такте после снятия DOUT.

[gid]

Очередная ревизия VM1CPP с учётом всех правок, сделанных ранее Patronом, и изменений новой ревизии модели 1.4с
VM1CPPr004.rar
Кроме того, были сделаны некоторые попытки дальнейшей оптимизации быстродействия для матриц, и изменён булев тип с BOOL на bool, чтобы компилятор более строго относился к операциям с булевыми переменными.
--
Уточнены алгоритмы eval_p и eval_n для vm1, архив во вложении обновлён.

[Patron]

были сделаны некоторые попытки дальнейшей оптимизации

Быстродействие возросло в 3.5 раза - это круто.

с учётом всех правок

Одна поправка осталась не учтённой - описание enum CPU_TYPE должно находиться в публичной части класса - с этой правкой модель без проблем компилируется и работает в составе адаптера МПИ :

class C1801VM1 
{
	friend class CDebugger;
public:
	enum CPU_TYPE
	{
		CPU_VM1A,
		CPU_VM1G
	};

private:
	DWORD m_nDeviceID;

Главный глюк V-модели по-прежнему активен - если сигнал RPLY снимается между eval_p и eval_n - модель перестаёт реагировать на тактовую частоту :

#################
POWER - ON
#################

-------------------------------------------------
 C        B S D D W R B I I D D S I H E A D I S S
 L   AD   S Y I O T P S R A M M A N A V C C R L L
 C        Y N N U B L 7 Q K R G C I L N L L 3 1 2
-------------------------------------------------
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
-------------------------------------------------
 C        B S D D W R B I I D D S I H E A D I S S
 L   AD   S Y I O T P S R A M M A N A V C C R L L
 C        Y N N U B L 7 Q K R G C I L N L L 3 1 2
-------------------------------------------------
 0 177716 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 160005 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 160005 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


   160000 [000340]      BR    160016

-------------------------------------------------
 C        B S D D W R B I I D D S I H E A D I S S
 L   AD   S Y I O T P S R A M M A N A V C C R L L
 C        Y N N U B L 7 Q K R G C I L N L L 3 1 2
-------------------------------------------------
 0 160000 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000406 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000406 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000406 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 ------------ и так до бесконечности ------------
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Именно поэтому в коде tboard.cpp находится специальный костыль для выравнивания изменений RPLY :

void tboard::maincycle()
{
	bool b_rply_n  = m_pMPI->rply_n;
	m_pMPI->rply_n = bPrev_rply_n;

	m_pCPU->eval_n(m_nClk, m_pMPI); //отработаем передний фронт ТЧ


	m_pMPI->rply_n = ( m_pCPU->m_IOPins.pin_rply_n ? b_rply_n : false );


	m_pCPU->eval_p(m_nClk, m_pMPI); //отработаем задний фронт ТЧ

	bPrev_rply_n = m_pMPI->rply_n;

	m_pMemory->eval(m_pMPI);
	m_pIRPS->eval(m_pMPI);

	m_nClk++;
}

Если убрать костыль и не выравнивать изменения RPLY - модель зависнет :

void tboard::maincycle()
{
	m_pCPU->eval_n(m_nClk, m_pMPI); //отработаем передний фронт ТЧ

	m_pCPU->eval_p(m_nClk, m_pMPI); //отработаем задний фронт ТЧ

	m_pMemory->eval(m_pMPI);
	m_pIRPS->eval(m_pMPI);

	m_nClk++;
}

Не пора ли разобраться с причиной этого глюка - ни в одной из родных моделей на Verilog такого не происходит ( см. ЗДЕСЬ ).

[gid]

описание enum CPU_TYPE должно находиться в публичной части класса

Забыл, сам-то я этот функционал не использую, он на будущее задан.

Не пора ли разобраться с причиной этого глюка

Подозреваю, что причиной глюка является механизм симуляции Z-состояний на МПИ, который я кое-как еле-еле слепил, он скорее всего работает не совсем корректно и только в некоторых частных случаях. Как правильно реализовать их, я так и не догадался, но без них модель вообще не работает. Поэтому, как разобраться с глюком, я не знаю.
Нужно отказаться от Z-состояний и шины МПИ и перейти на использование wishbone, но здесь я вообще не представляю, как сохранить точную потактовую симуляцию связки ВМ1+ВП1-037 на МПИ, поэтому пока даже не смотрю в эту сторону. Вот когда Vslav напишет модель, эмулирующую БК, тогда, после её изучения, может что-то можно будет сделать.

[Patron]

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

Сильно сомневаюсь.

Скрытый текст

...

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

Поясню конкретнее, что имеется в виду.


Вариант 1 :

1. Первая половина такта. На входе модели RPLY в состоянии N - всё работает.

2. Вторая половина такта. На входе модели RPLY в состоянии Z - всё работает.

3. Первая половина такта. На входе модели RPLY в состоянии Z - всё работает.

4. Вторая половина такта. На входе модели RPLY в состоянии Z - всё работает.


Вариант 2 :

1. Первая половина такта. На входе модели RPLY в состоянии N - всё работает.

2. Вторая половина такта. На входе модели RPLY в состоянии N - всё работает.

3. Первая половина такта. На входе модели RPLY в состоянии Z - модель зависла.

4. Вторая половина такта. На входе модели RPLY в состоянии Z - модель продолжает висеть.



Зависшая модель продолжает реагировать на изменение DCLO :

-------------------------------------------------
 C        B S D D W R B I I D D S I H E A D I S S
 L   AD   S Y I O T P S R A M M A N A V C C R L L
 C        Y N N U B L 7 Q K R G C I L N L L 3 1 2
-------------------------------------------------
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0
 0 000000 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0

[свернуть]

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

Возник вопрос по работе ВЕ-таймера.

В предыдущих версиях CPP-модели reg.tve_div = 0 выполняется при каждой установке сигнала INIT, а в 4-й версии CPP-модели reg.tve_div = 0 выполняется только при установке сигнала DCLO.

Это правильно ?