Просмотр полной версии : Цифровая археология: 1801 и все-все-все
Страницы :
1
2
3
[
4]
5
6
7
8
9
10
11
Относительно порядка вычисления 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.
если содержимое линий AD15-AD1 в момент выставления SYNC было 0177714 или 0177716.
Странно, должен выставлять "сам себе" и для других регистров внутренней периферии (таймер/регистры ошибки). За исключением регистра 177702 (там пауза есть, ожидает окончания несуществующего стартового прерывания ведового процессора, поэтому регистр +02 "отпадает" после первой записи, и до команды EMT - там еще одна ошибка в процессоре), выходной RPLY очень просто формируется - ~((~nDIN | ~nDOUT) & (addr == 1777xx)). То есть снятие/выставление RPLY внутренней периферией мгновенное, только физическими задержками схемы определяется. Кстати, измеряя эту задержку - хороший способ оценить качество конкретной микрохемы.
Да, и выход RPLY у ВМ1 - открытый коллектор, чтобы не было конфликта с внешним RPLY - ставят резистор, в БК например 510 Ом.
должен выставлять "сам себе" и для других регистров внутренней периферии (таймер/регистры ошибки).В том и дело - что регистры SEL1 и SEL2 внешние и их данные выставляются на шину не процессором, а материнской платой. Но RPLY при обращении к этим внешним адресам процессор 1801ВМ1 выставляет сам, поэтому если регистры SEL1 / SEL2 на шине не отвечают - вместо прерывания зависания происходит чтение нуля.
После смены местами eval_p и eval_n перестаёт проходить тест 79404. Подозреваю, что из-за некорректно реализованного источника векторного прерывания. Но при этом , потоковый дизассемблер тоже начинает выдавать какую-то ерунду, по которой я так и не понял, в каком месте случилась неприятность, то ли тест WAIT не прошёл, то ли предыдущий тест. Нужно реализовать отладочный пульт, куда бы вываливалось исполнение программы по HALT, но я пока совершенно другими делами занят.
После смены местами 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().
Нужно реализовать отладочный пульт, куда бы вываливалось исполнение программы по HALTV-модель уже запустилась в эмуляторе ДВК вообще без переделок исходного кода, поэтому после небольшой доработки адаптера МПИ - можно будет использовать эмулятор ДВК в качестве тестового стенда.
Похоже, я немного поторопился с оправданием текущей 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++;
}
Внутри m_pMemory и m_pIRPS обработка сигналов МПИ задана крайне простым конечным автоматом, который переключает свои состояния при любом фронте ТЧ, поэтому если закомментировать половину вызовов, эти модули могут начать работать некорректно, т.е. в 2 раза медленнее, я вместо них планировал также использовать V-модели, а пока - это просто заглушки, чтобы хоть как-то обеспечить работоспособность модели процессора. А вообще - у Си реализации модели очень большая проблема с третьими состояниями сигналов на шине. Я кое-как реализовал их подобие, после чего модель стала проходить тест 791401, но там тоже есть некоторые допущения, когда третье состояние, не совсем третье, а 0.
Я сейчас осваиваю верилог, чтобы лучше понимать, что я вообще делаю, и как оно должно работать, чтобы потом вернуться к проекту.
Вот вариант с некоторыми оптимизациями, я постарался уменьшить количество ненужных присваиваний, чтобы не гонять переменные туда-сюда в памяти зазря.
53803
эти модули могут начать работать в 2 раза медленнееОт качества эмуляции памяти глюк не зависит, в эмуляторе ДВК с модифицированной V-моделью та же история - после первого же цикла шины процессор останавливается и вообще перестаёт реагировать на тактовую частоту, бесконечно удерживая сигналы BSY и SYNC в конце цикла чтения.
я постарался уменьшить количество ненужных присваиваний, чтобы не гонять переменные туда-сюда в памяти зазря.Как выяснилось, V-модель процессора 1801ВМ1 примерно в 200 раз медленнее её абстрактного потактового аналога, поэтому единственное реальное требование к ней - полная корректность, позволяющая безошибочно "обучить" абстрактную МПИ-модель до полной потактовой совместимости с реальным процессором 1801ВМ1.
Посмотрел вторую версию VM1CPP (http://zx-pk.ru/attachment.php?attachmentid=53803) и считаю, что это движение в неправильном направлении.
В первой версии V-модель подключается к эмулятору МПИ через адаптер, что позволяет использовать её с любой абстрактной реализацией МПИ без изменения исходного кода.
Во второй версии в V-модель встроен интерфейс конкретного эмулятора МПИ, что требует изменений исходного кода для подключения такой V-модели к другим эмуляторам МПИ.
Хоть и в неправильном направлении движение, зато на мой взгляд единственное возможное. Правила выполнения конструкций верилога всё равно требуют развернуть все вложенные подфункции в одну большущую функцию.
53808 вот вариант, который не зависит от начальной фазы ТЧ и по крайней мере работает. Чтение и запись сигналов МПИ перенесено внутрь функции assign_all(), теперь она выполняется гарантированно за 2-3 цикла. Такой финт невозможен в первоначальном варианте.
Во второй версии в V-модель встроен интерфейс конкретного эмулятора МПИ, что требует изменений исходного кода для подключения такой V-модели к другим эмуляторам МПИ.
На данном этапе придётся с этим смириться, чуть позже, когда настанет время делать не поделие на коленке, а более серьёзный код, я найду силы разобраться в вашем адаптере МПИ.
На данном этапе придётся с этим смиритьсяПретензии к совместимости новой модели оказались преждевременными - её тоже удалось запустить в эмуляторе ДВК без изменений исходного кода.
Быстродействие модели действительно возросло - теперь она всего лишь в 100 раз медленнее абстрактного потактового аналога.
Как выяснилось - V-модель процессора 1801ВМ1 перестаёт реагировать на тактовую частоту, если снятие сигнала RPLY ( событие m_pMPI->rply_n = TRUE ) происходит между eval_p и eval_n.
Установка сигнала RPLY ( событие m_pMPI->rply_n = FALSE ) между eval_p и eval_n к зависанию процессора не приводит.
VM1CPPr003.rar (http://zx-pk.ru/attachment.php?attachmentid=53808) вот вариант, который не зависит от начальной фазы ТЧ и по крайней мере работает.У этого варианта есть проблемы с прохождением теста 791404. При разных запусках одного и того же файла VM1CPP.exe - тест то проходит, то нет.
Чаще не проходит :
Запуск Успех
------ -----
01 нет
02 да
03 да
04 нет
05 нет
06 нет
07 да
08 нет
09 нет
10 нет
11 да
12 нет
13 нет
14 нет
15 да
16 нет
Похоже, проблема в асинхронности QBUS_IRPS::OutputThreadFunc(), что приводит к установке m_bTTY_TXVirq в разные моменты времени при различных запусках программы.
Patron, По моему RPLY это ответный сигнал на сигналы DIN,DOUT. На Вашей осциллограмме видно что RPLY в первый раз совпадает с сигналом DIN, а во второй раз с задержкой на 1 такт. Разве сигналы могут синхронно выставляться?
Похоже, что это общая проблема всех версий. Сейчас скомпилировал первую версию модели и успешный прогон теста 791404 прошёл только после примерно десятка безуспешных запусков VM1CPP.exe.
---------- Post added at 21:05 ---------- Previous post was at 21:03 ----------
На осциллограмме видно, что RPLY в первый раз совпадает с сигналом DIN, а во второй раз с задержкой на 1 такт. Разве сигналы могут синхронно выставляться?Первый RPLY ( при чтении адреса 177716 ) выставляет сам процессор синхронно с сигналом DIN.
Улучшенная версия V-модели: VM1CPP.003a.zip (http://emulator.pdp-11.org.ru/misc/VM1CPP.003a.zip) стабильно проходит все тесты и обрабатывает события памяти только один раз в конце такта.
При запуске VM1CPP.exe в память загружается код из файла test.bin и запускается с нулевого адреса.
http://s017.radikal.ru/i418/1510/18/bcdb0cd12855t.jpg (http://s017.radikal.ru/i418/1510/18/bcdb0cd12855.png)
Еще семь тысяч ведер воды транзисторов и золотой ключик 1801ВМ2 у нас в кармане :). Зелененькое - еще не врисованные в схему ведра транзисторы, беленькое - врисованные. Еще бы Titus победил матрицы 1515ХМ1 и уже можно предметно помечтать о реплике УКНЦ.
ВМ2, хоть и похож на ВМ1, но изрядно "продвинут" - отдельный блок обработки ветвления (не предсказания), регистр-накопитель для деления-умножения (быстрее чем в ВМ1, но все равно микропрограммно), более глубокая и ранняя предвыборка (ВМ1 запускал ее микропрограммно, ВМ2 - аппаратно, добавлено слежение за модификацией инструкций). Еще бы ВМ2 частоту пополам не делил - вообще красота была бы, а так - он 4-х фазный, придется изрядно помучаться, чтобы разогнать до "честных" внутренних 100МГц и сравнить его с ВМ1. Или уже переделывать схему до двух фаз, в 1806ВМ2 вроде это нормально получилось.
Реверсится версия маски 1801ВМ2, которую я называю "Торчок-4" - надпись "ТЧ4" на кристалле имеется, от заводской схемы пока отличий принципиальных нет - добавлен еще один генератор смещения подложки, кое-где вставлены буфера, возможно изменена микропрограмма, но мы этого не узнаем - в исходной схеме матрицы не прорисованы.
Еще бы Titus победил матрицы 1515ХМ1 и уже можно предметно помечтать о реплике УКНЦ.
Обычно у меня зимой время на подобную выкройку, когда скучно и грустно, темно на дворе и снеговики за окном. Кто же летом сидит за подобными вещами? Летом солнце, пляж, огород круглый год)
---------- Post added at 19:41 ---------- Previous post was at 19:38 ----------
Еще бы ВМ2 частоту пополам не делил - вообще красота была бы, а так - он 4-х фазный, придется изрядно помучаться, чтобы разогнать до "честных" внутренних 100МГц и сравнить его с ВМ1. Или уже переделывать схему до двух фаз, в 1806ВМ2 вроде это нормально получилось.
Главное, ничего не изменять относительно оригинала до конца реверса. А уже потом перекраивать для своих мифических применений на частоте 100МГц.
Обычно у меня зимой время на подобную выкройку, когда скучно и грустно, темно на дворе и снеговики за окном. Кто же летом сидит за подобными вещами? Летом солнце, пляж, огород круглый год)
Угу, осень пришла, ВМ2 сдвинулся :)
"Всплыл" старый анекдот, стоят трое:
Первый - Я люблю лето!
Второй - А я люблю зиму!
Третий - Идиоты! Нужно любить деньги, тогда можно себе устроить ЛЮБОЕ время года
Главное, ничего не изменять относительно оригинала до конца реверса. А уже потом перекраивать для своих мифических применений на частоте 100МГц.
Угу, начнем с асинхронной модели. Схему добью, потом пусть пока отлежится, надо доразбирать микропрограмму ВМ1 и документацию закончить.
CPP-модель процессора 1801ВМ1 перестаёт реагировать на тактовую частоту, если хотя бы один раз деактивировать сигнал RPLY между eval_p и eval_n, а как реагируют в такой ситуации родная модель на Verilog и оригинальный процессор ?
как реагируют в такой ситуации родная модель на Verilog и оригинальный процессор ?
"Родную" модель Async (которая на латчах, асинхронная) я проверил:
- активация RPLY по фронту и по срезу CLK
- активация RPLY при высоком уровне CLK
- активация RPLY при низком уровне CLK
- деактивация RPLY по фронту и по срезу CLK
- деактивация RPLY при высоком уровне CLK
http://s020.radikal.ru/i709/1510/ed/abc69d51cd2ct.jpg (http://s020.radikal.ru/i709/1510/ed/abc69d51cd2c.png)
- деактивация RPLY при низком уровне CLK
http://s014.radikal.ru/i329/1510/cd/26ce7cb4666ct.jpg (http://s014.radikal.ru/i329/1510/cd/26ce7cb4666c.png)
Во всех случаях заводской тест 401 успешно проходится.
Для моделей Qsync/Wsync проверка RPLY не имеет смысла (хотя Qsync тоже немного погонял, все нормально работает) - в Qsync RPLY фиксируется по перепадам CLK (ответ и освобождение шины), в Wsync просто банально нет самого RPLY.
Реальные схемы на ВМ1 обычно используют синхронизацию RPLY по какому-либо из фронтов (стоит триггер), потому что в ВМ1 есть ошибка. На модели эту ошибку воспроизвести не удалось, предполагаю что она имеет физическую природу - или метастабильность или разброс параметров конкретных транзисторов.
---------- Post added at 22:12 ---------- Previous post was at 21:47 ----------
Немножко размышлений про возможную причину неработоспособности реального ВМ1 при несинхронизированном RPLY.
Фрагмент схемы:
http://s019.radikal.ru/i615/1510/ab/3875fd922dd8t.jpg (http://s019.radikal.ru/i615/1510/ab/3875fd922dd8.png)
RPLY_IN - это входной сигнал RPLY c внешнего вывода микросхемы. ~CLK - тактовый сигнал (с вывода микросхемы через буфер). Представим что на RPLY_IN и ~CLK на транзисторах T15949 и T15977 изменения сигналов происходят одновременно. В итоге на затворе T15981 может запомнится некоторое промежуточное значение (RPLY_IN переходит из одного значения в другое) - НЕ соответствующее строго какому-либо логическому уровню. На выходе Т15981 тоже может быть некоторое значение. Несмотря на то, что это значение "некоторое", дальнейшая схема все равно трактует его определенным образом (потому что есть усиление) - причем каждый транзистор может "трактовать" по-разному, в зависимости от порогового напряжения. Но даже, допустим, мы ближе к логическому нулю, и все работает одинаково. На затворе Т15981 происходит утечка (в неизвестную сторону - повышения или понижения заряда - зависит от конкретного экземпляра), и с ненормированного уровня она может произойти достаточно быстро, а не за гарантированые производителем 5мкс (полупериод от паспортных нижних 100 кГц), в итоге значение на выходе T15981 может изменится при низком ~CLK, на что схема логически не рассчитана - это состояние запоминания. Более того, из-за перекрестных помех там даже может возникнуть генерация, а не просто изменение значения.
На затворе Т15981 происходит утечка (в неизвестную сторону - повышения или понижения заряда - зависит от конкретного экземпляра), и с ненормированного уровня она может произойти достаточно быстро, а не за гарантированые производителем 5мкс (полупериод от паспортных нижних 100 кГц)
С чем связана такая быстрая утечка на затворах транзисторов того времени? Современные схемы вполне себе статические.
С чем связана такая быстрая утечка на затворах транзисторов того времени? Современные схемы вполне себе статические.
Да, современные схемы банально имеют другую схемотехнику, уже в ВМ2 нет таких "триггеров" на затворах. В еще более современных - вся логика cинхронная, там вообще латчей может не быть - только флип-флопы. Ну и везде быстрый КМОП, тау метастабильности уменьшается на порядки, в новых ПЛИСах Альтера даже не особо педалирует эту тему.
А утечка - можно предположить что связана с химической чистотой используемых материалов (примеси), культурой производства (чистотой реакторов) и дефектами решетки - технологии выращивания бездефектной подложки это сегодня вообще жутко тайное ноу-хау. Не, в основе старый добрый метод Чохральского, но там много тонкостей.
Во всех версиях CPP-модели имеется ошибка. Публичный вызов публичного метода void SetCpuType( CPU_TYPE nCPUType ) невозможен из-за того, что тип CPU_TYPE является приватным.
Из-за этого ( например ) вызов: core.SetCpuType( nC_MicrocodeStepping ? C1801VM1::CPU_TYPE::CPU_VM1G : C1801VM1::CPU_TYPE::CPU_VM1A );
- компилируется с ошибкой.
...
Испытания CPP-модели процессора 1801ВМ1Г дали любопытный результат - при установленном бите T команда WAIT не реагирует на сигнал ACLO.
У обычного 1801ВМ1 такой особенности нет.
...
Испытания CPP-модели процессора 1801ВМ1Г дали любопытный результат - при установленном бите T команда WAIT не реагирует на сигнал ACLO.
Такова матрица шифратора прерываний у ВМ1Г, установленный psw[4] (бит Т) вообще запрещает прерывание по ACLO, независимо от состояния ожидания. Поскольку прерывание по Т-биту более приоритетно чем по ACLO, то особенность вылазит только по команде WAIT. Я проверил фотографию и кристалл в микроскоп - в матрице есть только единственный транзистор на линии ACLO, то есть это не внесенная ошибка модели, но надо будет проверить на реальном процессоре. Для ВМ1А в матрице шифратора есть отдельная строчка, отвечающая за прерывание по ACLO в состоянии ожидания при установленном T:
assign p[13] = plir & ~psw[10] & psw[4] & ~qbto & aclo & ~uerr & wcpu;
Поэтому у ВМ1А такой особенности поведения быть не должно.
Вообще странно, в матрице шифратора остались неиспользуемые линии произведений, прерывание от таймера вполне можно было добавить без изменений поведения других прерываний - ресурсов достаточно.
Вообще странно, в матрице шифратора остались неиспользуемые линии произведений, прерывание от таймера вполне можно было добавить без изменений поведения других прерываний - ресурсов достаточно.
Напомнило про ВЕ1 (если это в тему конечно).
http://s017.radikal.ru/i401/1511/97/f293544bc4bb.jpg (http://radikal.ru/big/407d171d3cf34acca606ed2d41ad0fee)
...
CPP-модель процессора 1801ВМ1Г показывает, что реализация в ВМ1 команды MUL имеет интересную особенность - признак нулевого значения устанавливается без учёта 15-го бита результата ( и для 16-разрядного, и для 32-разрядного результата ). Например, если умножить 128 на 256, то результат получится ненулевой, но бит Z в PSW установится.
Для проверки можно выполнить такой код:
Mov #128., R0
Mul #256., R0
MFPS (R0)
В результате по нулевому адресу запишется значение PSW с установленным битом Z.
Материалы ревизии А по процессору КМ1801ВМ2, маска версии "Торчок-4", различные форматы:
Транзисторная схема pdf (7 МБ) (http://u.zeptobars.ru/yuot/1801/VM2/CAD/vm2_ra.pdf)
Транзисторная схема sch (18 МБ) (http://u.zeptobars.ru/yuot/1801/VM2/CAD/vm2_ra.sch)
Топология lay6 (12 МБ) (http://u.zeptobars.ru/yuot/1801/VM2/CAD/vm2_ra.lay6)
Топология pcb (9 МБ) (http://u.zeptobars.ru/yuot/1801/VM2/CAD/vm2_ra.pcb)
Топология tif (14 МБ) (http://u.zeptobars.ru/yuot/1801/VM2/CAD/vm2_ra.tif)
В картинке tif сделано две страницы - начальный вариант векторизации и конечный, можно увидеть сколько ошибок было по ходу рисования схемы исправлено (сотни полторы-две).
Всего 18431 полезный транзистор, есть еще неподключенный к питанию тестовый блок примерно на сотню тразисторов, там реализован мощный драйвер, несколько защелок и площадки для подключения зондов.
Отличия от заводской схемы в ТО очень незначительные, кое-где добавлены-убраны буфера, изменены входы матрицы прерываний, также в наличии имеется неубранный мусор в виде никуда не ведущих дорожек. Вообще скан схемы не очень качественный, попадались места где невозможно было достоверно прочитать название сигналов или определить наличие/отсутствие соединения на месте пересечения линий. В электронном виде навигация, конечно, намного быстрее, хотя в по-вентильном виде схема менее читабельная. Также получено содержимое всех матриц (это примерно треть всех транзисторов), которых нет в схеме - предварительного и основного декодеров, шифратора приортетов прерываний и блока образования условий ветвления.
Шикарно) Перевести бы еще схему в логические элементы)
А что это за некачественный скан схемы? Если мой, то я сканил по максимуму - 600dpi. Там все очень четко.
А что это за некачественный скан схемы? Если мой, то я сканил по максимуму - 600dpi. Там все очень четко.
Скан большей частью качественный, и вообще - схема относительно быстро нарисовалась благодаря ТО. Но есть некоторые места - например, низ первого и второго листов - там сложно разобратся в переплетении даже на экране (кое-какие странички я распечатывал). Или лист 11 справа, там еще входы имеют точки кое-где над цифрами. Иногда плохо читается отдельное имя цепи или сразу непонятно где стоит точка соединения. Но, как я уже сказал - помощь схема оказала значительную, а ТО - еще большую. Еще бы на ВМ3 такие документы достать :)
Еще бы на ВМ3 такие документы достать :)
Думаю, что не достать.
Схему на ВМ2 дали мне на скан его авторы. Тогда как авторы ВМ3 и ВМ4 к тому времени уже умерли.
Думаю, что не достать.
Схему на ВМ2 дали мне на скан его авторы. Тогда как авторы ВМ3 и ВМ4 к тому времени уже умерли.
Возможно стоит архивы предприятия "побомбить", там могла заваляться документация.
Подумываю вскрыть и сфотографировать ВМ3, есть пара микросхем с датой выпуска 9202 (спасибо bigral) и пара 9002 и 9101. Где-то встречал упоминание что до какой-то даты выпуска микросхемы содержали ошибки, не помнит ли кто подробностей? В упомянутых датах уже исправлено?
Здесь (http://www.phantom.sannata.ru/forum/index.php?t=14066&a=stdforum_view&o=&st=0) упомянута дата 07.1989г.
Возможно стоит архивы предприятия "побомбить", там могла заваляться документация.
На Ангстреме уже нет никаких людей связанных с этой серией, и, на сколько я помню, все доки авторы забрали с собой, когда разбежались по другим фирмам.
Во всяком случае, все, кто обращались на Ангстрем за доками, получали от ворот поворот.
...
Обновилась текущая сборка адаптера шины МПИ для эмулятора ДВК-1: DVK1+MPI_22.11.2015 (http://zx-pk.ru/showthread.php?t=25252&p=842968&viewfull=1#post842968)
Теперь можно запускать тесты на V-модели процессора 1801ВМ1.
На Ангстреме уже нет никаких людей связанных с этой серией, и, на сколько я помню, все доки авторы забрали с собой, когда разбежались по другим фирмам.
Во всяком случае, все, кто обращались на Ангстрем за доками, получали от ворот поворот.
Да, людей Пока нет, по крайней мере на 50.000 руб.
Да, авторы забрали доки. Знаю одного такого чела. Он весьма умен и знает, сколько стоит реверс...
Дело осложняется тем, что этот чип по-прежнему в сторою ВС РФ, а следовательно, попадает под УК "Разглашение...".
Насчет "Поворот... " - там люди думают прежде всего о снижении объема работ, а о не привычном для нормальной фирмы - повышении...
(Это специфика предприятия, находящегося на гособеспечении.)
*
Вот, например, ( почти ) готов проект модуля "1801ВМ1Г-100 мгц.". Сам узел, как я понял, производиться не будет. И зачем тогда стоило таких трудов его проектировать ? Или как кроссворд - результат не представляет интереса ?
Примерно то же самое и с ВМ3-100 мгц - со временем реверс, ИМХО, будет сделан. А дальше - только дока на машинных носителях, без железки ?
А если с железкой - что будет включено в гарнир ? И с какими параметрами ?
Или как кроссворд - результат не представляет интереса ?
В хобби соотношение процесса и результата бывает странным :)
Впрочем, в случае реверса ВМ1 результат есть - получено законченное и предварительно протестированное HDL-описание процессора, что само по себе подразумевает повторное использование затраченного труда. Причем необязательно в виде железки - gid успешно переработал HDL-описание в рабочую программу на C++, а Patron модифицировал эмулятор в плане точности, уже приятно - работа по реверсу не "пропала".
А если с железкой - что будет включено в гарнир ? И с какими параметрами ?
Железка тоже будет, ближайшие планы - точная реплика БК-0011М на FPGA, с точным воcпроизведением задержек -037 и видеовывода на 48.5Гц - как один из режимов работы. Аппаратная платформа - свою делать смысла пока не вижу, достаточно подходящих - Reverse-U16, Booster, еще думаю попробовать сделать порт на Speccy-2010, есть шансы что проект поместится.
точная реплика БК-0011М на FPGA
вот больше интересует что там с ВМ2 в планах? И с УК-НЦ связано что нибудь, хотя бы отчасти?
БК11М - всё же не тот агрегат, который хотелось бы "новоделом" иметь. Слишком он не RT-11-й ))))
И есть ли шанс на новоделах, старые сохранить разъёмы для классических контроллеров ?
Об УК-НЦ - у нас же недавно появился на форуме вариант поправленной версии исходники v3.00 ПЗУ УКНЦ
http://zx-pk.ru/showthread.php?t=6257&p=774785&viewfull=1#post774785
Зачем размениваться на БК11М ? Может быть ДВК на ВМ2 самое то, только вот граф. платы эмулировать надо,
причём обе, как у Титуса в эмуляторе. (вот как бы собрать ЕмуСтудию в железе? Что бы экранчик был правильный и
не терялось ни одной программы из набора БК10-УКнц-ДВК+КГД-ДВК+КЦГД (если АНДОС затеряется - премию автору!) - вот такая железка это было бы шикарно. С возможностью плавного регулирования скорости работы, правильным удобным подключением современных устройств (монитор!
клавиатура!) и классических контроллеров от УК-НЦ (они самые компактные в исполнении, в отличие от коробок, проводов и макарон БКашных). В общем то все вопросы эти я уже поднимал и задавал 4 года назад и все они риторические, но мне по прежнему думается,
такой ДВК пользовался бы спросом, особенно (!) если имел бы аппаратную возможность установки старших систем и соотв. поддержку
сети через интернет? )))
Главное что бы стоило это всё разумные деньги и было оформлено под ключ.
Конструкторы "спаяй меня я дружественный" не допустимы! Нужен продукт в подарочной коробке, плаг ин плэй,
а ПО - вот оно пожалуйста - 0 рублей 00 копеек ))) 6гб почти игр и программ ))) В общей сложности )))
Не так уж и мало для PDPишки где минимальная система меньше 800кб весит.
вот больше интересует что там с ВМ2 в планах? И с УК-НЦ связано что нибудь, хотя бы отчасти?
В совсем ближайших планах ВМ1 закончить - документацию дописать, собрать многопроцессорную конфигурацию на плате 2xВМ1 и какой-то рабочий проект на FPGA. Оно все модульно делается, по типу SoC, многие модули можно будет с небольшими переделками или вообще без них использовать повторно. Например, сейчас пишется универсальный контроллер SDRAM с отдельным опциональным видеопортом (всегда хотел разобраться и изобрести этот велосипед :)), по готовности можно будет собрать МС1201.01 буквально за один вечер, собственно оно уже почти есть, только памяти пока маловато - 32К на внутренних блоках ПЛИС . Еще пример - модуль ВП1-128 тоже много для чего пригодиться сможет - для MY и для того же УКНЦ.
Если помечтать что дальше - ВМ2 будет смоделирован с достаточно большой вероятностью. Насчет УКНЦ - надо БМК разобрать, ВП1-055 готова, ВП1-120 в стадии схемы, ХМ1 - две сфотографировано, для одной из них Titus рисует потихоньку схему, оставшиеся две ХМ1/ХМ2 не совсем удачно открыты, думаю или открывать еще или фотографировать то что есть. Поэтому я думаю что МС1201.02 быстрее появится, там все готово будет.
Если уж совсем далеко заглядывать, то наверное буду ковырять 1811ВМ1/ВТ1, это попроще чем 1801ВМ3 и имеет практически те же самые возможности. И это полностью "кошерный" PDP-11/23.
И есть ли шанс на новоделах, старые сохранить разъёмы для классических контроллеров ?
Дык, это от нас же зависит, если захотим - то можно сделать и реплику в корпус УКНЦ, в том числе поставив разъемы под старые контроллеры. Но какие там контроллеры? НГМД? Лучше его иметь "на борту" и 34-контактный разъем под дисковод. Сетевой и HDD? То же самое. Пока мне больше всего из имеющихся готовых плат нравится Бустер, там есть разъемы под флопы, под CF и расширения (под МПИ который), "правильный" аналоговый/цифровой видеовыход на хрюнтеле. Когда разрабатывали, я просил туда добавить еще последовательные порты, но не срослось, увы. А какая это будет модель - это же от прошивки ПЛИС зависит, можно и БК и разные ДВК и УКНЦ, лишь бы ресурсов хватило.
это же от прошивки ПЛИС зависит
выбор нужной в стартовом меню! они же по объёму (по сегодняшним меркам) крошечные.
нужна аппаратная возможность установки BSD-подобных систем иначе не серьёзно, но и терять библиотеку игр от БКашки(10-й) и RT-11 (5.7С) софт и компиляторы нельзя!!! ))) Это надо в ТЗ иметь как пункт-условие - нужны все четыре "несовместимые" видео - БКашечное, УК-НЦшное, КГД и КЦГД ))) А там уже на макс. частотах,
надо что то "глайдо-подобное" прикручивать, для глайд-демо (https://ru.wikipedia.org/wiki/Glide) и граф.оболочки для пользователей "хорошо забытое не есть совсем уж не годное! ;-) Как такую ЭВМ обозвал бы разработчик? При условии отношения к PDP-семейству сверх-современному?
В совсем ближайших планах ВМ1 закончить - документацию дописать.При тестировании V-модели ВМ1 выяснилось, что у всех версий этого процессора есть свой мега-глюк, активирующийся командами байтовой пересылки PC в другие регистры ( например - MOVB PC,R0 ). При этом, если следующая команда тоже глюкогенная - процессор зацикливается на непрерывной выборке и выполнении этой команды, если следующая команда регистровая - она выполняется дважды, а если не регистровая - она выполняется один раз, но в специальном "режиме мега-глюка".
Владельцы реальных процессоров 1801ВМ1 ( как и исследователи V-модели ) могут развлечься выполнением следующих тестовых фрагментов:
MovB PC, R0
MovB PC, R1
Halt
Clr R0
MovB PC, R1
Inc R0
Clr R0
MovB PC, R1
Mov #5200, R1
Tst R0
. = 0
MovB PC, R1
Jmp @#1$
1$:
Halt
. = 136
Wait
выбор нужной в стартовом меню! они же по объёму (по сегодняшним меркам) крошечные.
Это относительно несложно сделать в платах с процессором, типа Speccy-2010 или новый Aeon. Правда последний еще не выпущен.
Впрочем, для начала надо хотя бы одну конфигурацию заиметь :)
нужны все четыре "несовместимые" видео - БКашечное, УК-НЦшное, КГД и КЦГД ))) А там уже на макс. частотах,
Если четыре независимых конфигурации четырех упомянутых машин - то почему бы и нет.
- - - Добавлено - - -
При тестировании V-модели ВМ1 выяснилось, что у всех версий этого процессора есть свой мега-глюк
Быстренько прогнал на Async и Qsync первый пример, оно зациклилось, то есть глюк присуствует, осталось выяснить это глюк исходной модели или реального процессора.
MovB PC, R0 MovB PC, R1 Halt
В одном из эмуляторов БК11М благополучно вылетает в пульт )
В другом Trap-пится )
Быстренько прогнал на Async и Qsync первый пример, оно зациклилось, то есть глюк присутствует, осталось выяснить это глюк исходной модели или реального процессора.
Видимо таки это глюк реального процессора. Там http://bk0010.org/forum/?id=3799#25082 anonymous проверил на реальной БК10, результаты получаются как указано Patronом.
Хорошо, что мне никогда не приходило в голову использовать movb PC,Rn такое и не определишь сразу, почему прога не так, как задумано работает. А с T-битом, при пошаговой отладке глюк проявляется? У меня есть подозрение, что не должен.
У меня в ближайшее время нет возможности самому экспериментировать не только на реальном железе, но и на программных моделях.
Видимо таки это глюк реального процессора. Там http://bk0010.org/forum/?id=3799#25082 anonymous проверил на реальной БК10, результаты получаются как указано Patronом.
Хорошо, что мне никогда не приходило в голову использовать movb PC,Rn И неудивительно, что не приходило, ибо такая команда, хоть и входит в список легальных, на фиг никому не нужна. Практического смысла в младшем байте счетчика команд, да еще и расширенном знаковым разрядом, и в микроскоп не разглядишь.
Надо будет попробовать, как заведу свою 1201.01, но пока нет времени.
...
CPP-модель процессора 1801ВМ1Г показывает, что реализация в ВМ1 команды MUL имеет интересную особенность - признак нулевого значения устанавливается без учёта 15-го бита результата ( и для 16-разрядного, и для 32-разрядного результата ). Например, если умножить 128 на 256, то результат получится ненулевой, но бит Z в PSW установится.
Проверил умножение #128. на #256.:
- на реальном процессоре ВМ1Г флаг Z не устанавливается
- на модели Wsync флаг Z устанавливается
Вывод - где-то есть неточность, надо разбирать в подробностях микропрограмму умножения.
...
Возможно, есть смысл проверить на реальном процессоре все зомби-циклы, вызываемые микропрограммой. Самое любопытное - новые уникальные зомби-циклы процессора 1801ВМ1г, появившиеся в командах JMP и JSR.
Например - так выглядят циклы шины при выполнении команды JMP 1000 на процессоре 1801ВМ1а :
000110 [000002] JMP 001000 ; 001000 -> PC
-------------------------------------------------
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 000110 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 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 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 000167 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 000167 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 000167 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 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 000112 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 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 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 000664 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 000664 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 000664 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 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
001000 [000002] MOV #4096., SP ; 001002:010000 -> R6 :000000
-------------------------------------------------
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 001000 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 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 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 012706 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 012706 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 012706 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 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 001002 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 000000 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
А так - на процессоре 1801ВМ1г :
000110 [000002] JMP 001000 ; 001000 -> PC
-------------------------------------------------
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 000110 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 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 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 000167 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 000167 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 000167 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 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 000112 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 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 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 000664 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 000664 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 000664 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
-------------------------------------------------
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 001000 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 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 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 012706 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 012706 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 012706 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 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
001000 [000002] MOV #4096., SP ; 001002:010000 -> R6 :000000
-------------------------------------------------
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 001000 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 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 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 012706 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 012706 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 012706 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 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 001002 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 000000 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Версия 1.4b (http://u.zeptobars.ru/yuot/1801/VM1/vm1_rev14b.rar)
- в модели Async добавлена поддержка версии микрокода 1801ВМ1Г
- улучшены тесты, сделан цикл, вывод на сегментный индикатор
- модифицирована логика запоминания флагов NZVC, для команды MUL флаги вычислялись неверно,
микрокод формировал в финале выполнения инструкции строб au_pstbx записи флагов с выхода ALU.
В оригинальном процессоре флаги перезаписывались в следующем такте верным значением
Добавил в Async версию с умножением (там не было ВМ1Г), оказалось что эта модель работает верно, то есть - это не ошибка собственно реверса. Модели Qsync/Wsync фиксировали флаги по результатам ALU немножно по другому стробу, более раннему. Этот строб имеет меньший приоритет чем строб записи флагов напрямую с выхода шины АЛУ (типа как в команде mtps). Микрокод команды умножения вырабатывает этот строб (хотя он не нужен), и флаги записываются с шины а не по результату. В оригинальном процессоре и в модели Async значение флагов записывается в следующем такте по другому стробу и все нормально, в моделях Wsync/Qsync по более раннему стробу и перезаписи не происходило. Откорректировал код, погонял тесты 401/404 на ВМ1А/ВМ1Г, вроде ничего не поломалось, флаги после умножения работают верно. На прерывание таймера сделал тумблер, а то мешают выполнению тестов.
PS: Чтобы исправить V-модель на С++ изменения в vm1_qbus.v искать по слову rollback, там ниже новые присваивания psw[0] и psw[3:1]
Чтобы исправить V-модель на С++ изменения в vm1_qbus.v искать по слову rollback, там ниже новые присваивания psw[0] и psw[3:1]Если опубликовать необходимые правки для исходника VM1CPP.003a.zip (http://emulator.pdp-11.org.ru/misc/VM1CPP.003a.zip) ( вероятно - в файле VM1CPP\vm1cpu\vm1.cpp ) - было бы весьма кстати.
...
И что-то там ещё с ВЕ-таймером не хорошо.
Похоже, будто значение прескалера на входе не изменяется :
VM1VE1.SAV (http://zx-pk.ru/attachment.php?attachmentid=24811)
.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 (http://s020.radikal.ru/i712/1511/4a/d447aed26bf1.png)
На ВМ1Г, есть "зомби" циклы - код инструкции jmp перечитывается дважды: http://s020.radikal.ru/i708/1511/52/d93317a570b0t.jpg (http://s020.radikal.ru/i708/1511/52/d93317a570b0.png)
(Картинки длинные и узкие, после двоеточия, на белом фоне, поэтому в теле поста видно плоховато. Маленькие - .png до 100 килобайт, можно смело тыцать)
- - - Добавлено - - -
Если опубликовать необходимые правки в файле VM1CPP\vm1cpu\vm1.cpp )
Поправил (http://u.zeptobars.ru/yuot/MISC/vm1.cpp), насколько я разбираюсь в модели. Не компилировал, у меня такой новой студии нету (2005 хватает).
И что-то там ещё с ВЕ-таймером не хорошо.
Мне .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.
Косячок-с где-то :)
ПоправилCPP-модель работает, ошибки MUL нет.
дайте исходник и поясните в каком месте что не нравитсяВ том виде, в каком я использую модель - ВЕ-таймер почему-то не получает тактирование. Попробую кое-что сам посмотреть, но интересно, что делает pin_ena и как ВЕ-таймер переключается на внешнее тактирование.
На ВМ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.
CPP-модель работает, ошибки MUL нет.
Отлично.
В том виде, в каком я использую модель - ВЕ-таймер почему-то не получает тактирование.
Нет, там хитрее оказалось. Регистр счетчика перегружается из регистра предела не просто если счетчик нулевой, а если он перед этим был ненулевой и при счете достиг нуля. То есть - по фронту сигнала tve_zero, а не просто по уровню tve_zero. Это я пропустил детектор фронта tve_zero когда переписывал таймер со схемы, сама транзисторная схема правильная.
Что получалось - в регистр предела программа записала нулевое значение, счетчик также нулевой, tve_zero высокий, поэтому при каждом такте счетчик перегружался нулевым значением из лимита и счета как такового не было (перегрузка имеет приоритет перед декрементом). Если записать ненулевое значение в лимит, то считает нормально.
Внес изменения в таймер, коррекция C++ модели (http://u.zeptobars.ru/yuot/MISC/vm1(tve).cpp)
Надо будет добавить регистровое поле tve_zprev в vm1_qbus_shared.h
На реальной ПЛИС тест заработал нормально.
3) После команды MTPS Rx. После MTPS PC - зомби выходит только один.
Да, это уже проверялось на живом ВМ1А, этот зомби точно есть.
Update: файлы таймера для ревизии 1.4b на сервере обновил
На реальной ПЛИС тест заработал нормально.На модели тоже заработал, но есть одна тонкость - по команде RESET вместо
reg.tve_count = 0;
reg.tve_limit = 0;
реальный процессор делает :
reg.tve_count = snap_reg.tve_limit;
На модели тоже заработал, но есть одна тонкость - по команде RESET вместо
reg.tve_count = 0;
reg.tve_limit = 0;
Да, это было добавлено для комфортного моделирования, избавлюсь от обнуления счетчика и предела по tve_reset, добавлю обнуление по dclo, тогда будет инициализация только по аппаратному сбросу всего процессора.
реальный процессор делает :
reg.tve_count = snap_reg.tve_limit;
Нет, из схемы этого не видно, проверил на ВМ1Г - он тоже значение счетчика по RESET не изменяет. По RESET сбрасывается только CSR, счетчик останавливается и сохраняет свое текущее значение.
добавлю обнуление по 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 (http://zx-pk.ru/attachment.php?attachmentid=24901&d=1297350120) - результат на реальном ВМ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.
По RESET сбрасывается только CSR, счетчик останавливается и сохраняет свое текущее значение.Значит, в этой части моя абстрактная модель ВЕ-таймера изначально была ошибочна.
На том реальном ВМ1, который тестировался с моим участием - после включения питания происходило:
включение питания и команда RESET это разные вещи. При включении питания в регистре счетчика и предела - просто мусор, как триггеры установяться так и будет. По каманде RESET содержимое регистров не изменяется, проверил тестиком. На ПЛИС при включении питания и при сбросе по DCLO (начиная с версии 1.4C) происходит обнуление счетчика, предела и прескайлера.
Поэтому, при первом запуске теста
Я не нашел в тексте команду RESET, к тому же любая запись в 177712 приводит к копированию предела в счетчик, мусорное значение, полученное при включении питания, перезаписывается значением из регистра предела.
А ноль в счетчике подзадержался как раз до такта счета (до 128 тактов процессора, зависит от того что было в невидимом 7-битном прескайлере), потому что именно не было фронта tve_zero и не было мгновенной 4-тактовой перегрузки из регистра предела (впрочем там тоже 0). Поэтому тест успел прочитать нулевое значение дважды.
Обновил таймер до ревизии 1.4c (http://u.zeptobars.ru/yuot/1801/VM1/vm1_rev14c.rar)
любая запись в 177712 приводит к копированию предела в счетчик, мусорное значение, полученное при включении питания, перезаписывается значением из регистра пределаИмелось в виду, что начальные значения счётчика и предела у реальных процессоров: 1)не нулевые; 2)не одинаковые; 3)практически неизменные при каждом включении питания.
Поэтому (на мой взгляд) лучше не приучать программистов к тому, что при включении питания в указанных регистрах ВМ1 будут нули - нулей у реального процессора там не будет.
- - - Добавлено - - -
Можно даже при включении питания помещать в регистр 177706 версию прошивки, умноженную на (-1) - похоже, что при включении питания начальные значения в этих регистрах реальных ВМ1 тяготеют к 0177777 и отличаются лишь в отдельных битах из-за физических особенностей конкретного кристалла.
Или в старший байт помещать 0210, а в младший - версию прошивки.
нулей у реального процессора там не будет.
Ну я бы не стал так утверждать, пока нет никаких специальных исследований по большой выборке - любое значение неопределенно-равновероятно, и ноль в том числе. Про приучение программистов непонятно, если таймер используется без перегрузки, то значение предела и счетчика неважны - предел не используется, счетчик последовательно считает все значения от 0 до 177777. Если с перегрузкой, то нормальный программист пропишет в регистр предела нужное значение. Полагаться каким-либо образом на случайное значение после включения питания - это только для каких-то очень академических тестов. В-общем, предлагаемый ноль в качестве "значения по питанию" ничем не хуже любого другого. Впрочем, нет проблем прописать это любое другое значение.
- - - Добавлено - - -
Или в старший байт помещать 0210, а в младший - версию прошивки.
Да, идея неплохая. Будем приучать к ней программистов? :)
Да, идея неплохая. Будем приучать к ней программистов?Если не нулевая версия прошивки в младшем байте будет иметь объективную возможность отличаться у разных экземпляров - это в общем случае конечно же будет более адекватно реальности, чем неизменное нулевое начальное значение.
- - - Добавлено - - -
Ещё один вопрос. Когда процессор осуществляет цикл DATO, что при этом происходит на линиях AD - сначала процессор выставляет адрес и этот адрес виден на шине вплоть до выставления данных записи, которые не снимаются вплоть до выставления адреса следующего за записью цикла или как-то ещё..
Судя по доступным осциллограммам циклов чтения, где ВМ1 держит адрес на шине "до упора" - от него вполне можно ожидать такого же поведения и при выставлении данных записи.
Есть какие-нибудь осциллограммы циклов записи в исполнении реального ВМ1 ?
Может такое быть, что когда осциллограммы снимаются на стенде с "голого" процессора, то отсутствие нагрузки на линиях AD позволяет им "запоминать" последнее значение, тогда как на реальной шине осциллограмма будет другой ?
Ещё один вопрос. Когда процессор осуществляет цикл DATO, что при этом происходит на линиях AD - сначала процессор выставляет адрес и этот адрес виден на шине вплоть до выставления данных записи, которые не снимаются вплоть до выставления адреса следующего за записью цикла или как-то ещё.
Картинка с циклами записи и чтения-модификации записи (.png 70КБ, после двоеточия между скобок): (http://s019.radikal.ru/i625/1511/01/13251f5ed795t.jpg (http://s019.radikal.ru/i625/1511/01/13251f5ed795.png))
Листинг кода:
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 и куча резисторов возле пустого слота второго процессора - шина там общая.
http://s019.radikal.ru/i607/1308/c3/fac718ad88a3t.jpg (http://radikal.ru/fp/d7e9a2047111480098b9356e45420f82)
Осциллограммы с SignalTap стало получать достаточно просто, в пару кликов в Квартусе, надо будет еще быстренько модуль с ВМ2 запустить, тоже посмотреть чего там происходит.
Update: на кабеле тоже установлены резисторы на +3.3V, но уже 22К, так что ничего свободно не болтается. И да, это же картинка получена не с симулятора. Симулятор мог бы вычислить из модели и показать Z-состояние. А суровый челябинский анализатор может физически измерить и показать только логические уровни 0 или 1.
Вот я раньше приводил фотографию - пины ПЛС на плате DE0 выходят в итоге на кабель, анализатор захватывает значения с кабеля. Видны также шинные формирователи, буферная MAX3064 и куча резисторов возле пустого слота второго процессора - шина там общая.
Очень хочется с настоящим ретро-подлинным ВМ2 увидеть снимок и анализ конечно, вопрос камушек ВМ2 какой предполагается пластик или керамика? Насколько живучесть старых процессоров позволит их использовать, не будет ли с этим лишних проблем, причём я все цело за "родные сердечки на платах" поэтому и вопрос такой задаю (извиняюсь если немного не научно прозвучало).
- - - Добавлено - - -
ВМ1 и ВМ2 по площади разные и не совместимы, то есть топология платы под ВМ2 будет другой и однопроцессорной? (скорее констатация чем вопрос).
Судя по картинке, при чтении процессор удерживает адрес еще 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 при байтовой записи.
Очень хочется с настоящим ретро-подлинным ВМ2 увидеть снимок и анализ конечно, вопрос камушек ВМ2 какой предполагается пластик или керамика?
Пока есть только снимок :)
http://s017.radikal.ru/i413/1511/a8/15e317b2aaa2t.jpg (http://s017.radikal.ru/i413/1511/a8/15e317b2aaa2.jpg)
Насколько живучесть старых процессоров позволит их использовать, не будет ли с этим лишних проблем
1801ВМ1Г 89 года выпуска корректно отмолотил 12 часов на заводском тесте 401 на 7.2МГц, без всяких замечаний, 1801ВМ2 не должен быть хуже.
причём я все цело за "родные сердечки на платах" поэтому и вопрос такой задаю (извиняюсь если немного не научно прозвучало).
Еще приятно что получается сделать ПЛИС-реплику и переходник к реальному модулю в рамках одного интерфейса. То есть, в БК на ПЛИС достаточно заменить одну строчку и она будет работать на реальном процессоре вместо копии, и наоборот.
- - - Добавлено - - -
Тогда есть смысл посмотреть ещё и на поведение сигнала WTBT при байтовой записи.
Байтовая запись и байтовая чтение-модификация-запись: (http://s019.radikal.ru/i624/1511/df/842486211a8bt.jpg (http://s019.radikal.ru/i624/1511/df/842486211a8b.png))
Подтверждение прерывания по приему от 065: (http://s017.radikal.ru/i429/1511/cc/7b2af6a18065t.jpg (http://s017.radikal.ru/i429/1511/cc/7b2af6a18065.png))
Байтовая запись и байтовая чтение-модификация-записьПолучается, как и в модели - сигнал WTBT при записи байта устанавливается на предыдущем такте перед установкой DOUT, а снимается на следующем такте после снятия DOUT.
Очередная ревизия VM1CPP с учётом всех правок, сделанных ранее Patronом, и изменений новой ревизии модели 1.4с
55056
Кроме того, были сделаны некоторые попытки дальнейшей оптимизации быстродействия для матриц, и изменён булев тип с BOOL на bool, чтобы компилятор более строго относился к операциям с булевыми переменными.
--
Уточнены алгоритмы eval_p и eval_n для vm1, архив во вложении обновлён.
были сделаны некоторые попытки дальнейшей оптимизацииБыстродействие возросло в 3.5 раза - это круто.
с учётом всех правокОдна поправка осталась не учтённой - описание enum CPU_TYPE должно находиться в публичной части класса - с этой правкой модель без проблем компилируется и работает в составе адаптера МПИ (http://zx-pk.ru/showthread.php?t=25252) :
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 такого не происходит ( см. ЗДЕСЬ (http://zx-pk.ru/showthread.php?t=23978&p=838017&viewfull=1#post838017) ).
описание enum CPU_TYPE должно находиться в публичной части класса
Забыл, сам-то я этот функционал не использую, он на будущее задан.
Не пора ли разобраться с причиной этого глюка
Подозреваю, что причиной глюка является механизм симуляции Z-состояний на МПИ, который я кое-как еле-еле слепил, он скорее всего работает не совсем корректно и только в некоторых частных случаях. Как правильно реализовать их, я так и не догадался, но без них модель вообще не работает. Поэтому, как разобраться с глюком, я не знаю.
Нужно отказаться от Z-состояний и шины МПИ и перейти на использование wishbone, но здесь я вообще не представляю, как сохранить точную потактовую симуляцию связки ВМ1+ВП1-037 на МПИ, поэтому пока даже не смотрю в эту сторону. Вот когда Vslav напишет модель, эмулирующую БК, тогда, после её изучения, может что-то можно будет сделать.
Подозреваю, что причиной глюка является механизм симуляции 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.
Это правильно ?
Возник вопрос по работе ВЕ-таймера.
В предыдущих версиях CPP-модели reg.tve_div = 0 выполняется при каждой установке сигнала INIT, а в 4-й версии CPP-модели reg.tve_div = 0 выполняется только при установке сигнала DCLO.
Это правильно ?
Да, предделители ВЕ-таймера не сбрасываемые, как при включении установилась какая-то случайная фаза, так от нее и начинается непрерывный счет. Сброс в модели добавлен для предсказуемого моделирования, по аналогии с регистром счетчика. Еще есть предделитель таймера шины, 3-битный, его фаза тоже не сбрасываемая. То есть тайм-аут может наступать в интервале от 56 до 63 тактов процессора, мне это не понравилось и я сделал всегда точные 60.
Да, предделители ВЕ-таймера не сбрасываемые.Предделитель - это reg.tve_pre
reg.tve_div - это ( вроде ) что-то другое :
BYTE tve_pre; //reg[6:0] // clock prescaler counter
BYTE tve_div; //reg[5:0] // timer clock divisor
Что предделитель не сбрасывается по INIT - это понятно, но правильно ли, когда по INIT не сбрасывается и делитель ?
- - - Добавлено - - -
И ещё вопрос на ту же тему.
В новой CPP-модели по INIT по-прежнему сбрасываются reg.tve_tclk4, reg.tve_tclk и reg.tve_edge - это правильно ?
reg.tve_div - это ( вроде ) что-то другое :
Это две последовательные части одного большого общего предделителя. На топологии они тоже разнесены и имеют разную схемотехнику - первый каскад деления на 128 построен на затворных емкостях, а последующий 1/64 уже на честных триггерах. Поэтому оно так было перенесено в Верилог, но логический смысл у него - именно один большой общий предделитель. По INIT фаза ни у первого ни у второго каскада не сбрасывается. Названия каскадов "предделитель" и "делитель" условны.
В новой CPP-модели по INIT по-прежнему сбрасываются reg.tve_tclk4 и reg.tve_tclk - это правильно ?
В смысле аутентичности не совсем правильно, но неприницпиально - по INIT сбрасывается регистр управления, счет прекращается, а фаза зависит о предделителя и сохраняется. Поэтому это просто моя перестраховка.
это просто моя перестраховка.Т.е. в реальном 1801ВМ1 reg.tve_tclk4, reg.tve_tclk и reg.tve_edge не сбрасываются по INIT, а reg.tve_intrq в реале сбрасывается по INIT ?
...
И ещё вопрос - регистры R0 .. R6 у 1801ВМ1 в реале обнуляются при включении питания ?
Т.е. в реальном 1801ВМ1 reg.tve_tclk4, reg.tve_tclk и reg.tve_edge не сбрасываются по INIT
В реальном процессоре tve_tclk4 и tve_clk просто тупо отдельные разряды предделителя, tve_clk коммутируется мультиплексором с нужного. То есть - они не сбрасываются (потому что это предделитель). В модели они представляют отдельные триггеры, активный уровень длительностью только один такт (а не меандр), и формируются из фазы предделителя (запаздывают на такт, но фазу предделителя никто нигде программно не видит и "дорогая не узнает, какой у парня был конец"), поэтому их сброс по INIT не важен - к моменту счета или другого события они восстановятся из фазы предделителя, которая при INIT выживает.
Детектор tve_edge в реальном процессоре сделан на затворном триггере, тактируется tclk4 и дает одиночный импульс по обнаружении фронта на входе SP. Поскольку по INIT сбрасывается разрешение детектора в TVE_CSR, то останов tve_tclk4 и сброс tve_edge никак не влияют на работу таймера. Ну пропустим фронт на SP и что? Таймер все равно остановлен и его работа заблокирована.
а reg.tve_intrq в реале сбрасывается по INIT ?
Хм, это залет. Нет, не сбрасывается, очищается только по сбросу процессора. И проверялся же список сбрасываемых объектов по INIT, но для версии ВМ1А. Для ВМ1Г "бросил апельсин мимодумно в воду" :) В модуле таймера до ревизии 1.4с был только вход сброса по INIT, вот оно неверно и прицепилось.
И ещё вопрос - регистры R0 .. R6 у 1801ВМ1 в реале обнуляются при включении питания ?
Нет, там случайные значения. Вот в РОНы, наверное, более правильно версию ядра вставить, потому что ВЕ-таймер не во всех процессорах есть (ВМ2/3), а с регистрами будет универсальный подход.
Нет, там случайные значения.Надо бы выполнить на реальном 1801ВМ1 что-то вроде:
MOV R0, (PC)+
NOP
MOV R1, (PC)+
NOP
MOV R2, (PC)+
NOP
MOV R3, (PC)+
NOP
MOV R4, (PC)+
NOP
MOV R5, (PC)+
NOP
MOV R6, (PC)+
NOP
HALT
И опубликовать результаты. Тогда станет понятно, какие биты превалируют в начальных значениях регистров - нулевые или единичные.
Вот в РОНы, наверное, более правильно версию ядра вставить, потому что ВЕ-таймер не во всех процессорах есть (ВМ2/3), а с регистрами будет универсальный подход.Но обнулять 177706 и 177710 при включении питания тоже не стоит - лучше продублировать значения, получаемые при включении питания в этих регистрах у тестируемого процессора ( эти значения на удивление стабильны от включения к включению ).
Надо бы выполнить на реальном 1801ВМ1 что-то вроде:
Этот опыт проведу чуть позже, пока процессор при загрузке ПЛИС живет какое-то время своей жизнью (исполняет мусор с пустой шины), регистры разрушаются, надо разобраться.
Но обнулять 177706 и 177710 при включении питания тоже не стоит
Сейчас было сделано по DCLO, это не совсем включение питания. Переделано на более честный вариант, при помощи блока initial теперь прескайлер и регистры счетчика и предела инициализируются один раз именно при включении питания ПЛИС. Оператор initial предназначен только для симуляции, для синтеза его использование очень не рекомендуется, и не всегда поддерживается синтезаторами, но для Altera/Xilinx - подходит. В принципе, определенное начальное значение нужно только для симуляции, в физической системе начальное значение этих триггеров не играет никакой роли, поэтому можно не переживать, если оно вдруг перестанет синтезироваться,
скажем, для какой-нибудь ASIC.
В реальной ПЛИС в качестве начального значения лучше использовать нули. Попробовал ненулевые значения (задал для пробы tve_count = 16'o157240; tve_limit = 16'o177321;) и сразу получил использование ресурсов 1741 ячейку против 1705 и небольшое снижение граничной частоты (но в 100МГц пока вписалось). Полез разбираться, там интересно - триггеры альтеры имеют только входы асинхронного сброса, и у них нет входов установки. Эти входы сброса и используются для назначения начальных состояний при включении питания. Если нужно установить в единицу, то функция инвертируется, и триггер работает в инверсии. Все бы ничего, но tve_count - это счетчик, относительно длинный, ячейки там работают в специальном арифметическом режиме, при вкраплении инверсии отдельных триггеров (те которые мы установили в 1 при включении питания), оно синтезируется как произвольная логика, а не как стандартный счетчик (под которые в архитектуре ПЛИС есть специальные заточки), что приводит к ухудшению параметров.
- лучше продублировать значения, получаемые при включении питания в этих регистрах у тестируемого процессора ( эти значения на удивление стабильны от включения к включению ).
Это прекрасно, но нельзя гарантировать стабильность при другой температуре или, скажем, при другой крутизне фронта напряжения питания. Ну и от партии выпуска наверняка зависисят как-то. Поэтому, в общем случае, эти значения undefined и ноль не является криминалом. Если использование ненулевого значения приводит к ухудшению синтезируемого результата, то лучше от этого воздержаться, имхо. В модель симуляции Async или эмулятор добавить ненулевые инициализации не проблема, в синтезируемые - лучше ненуна.
Итого, подправил таймер (выложу после тестирования):
- начальные значения прописываются в счетчик/предел один раз при включении питания ПЛИС (немного некошерный блок initial, но синтезируемость его непринципиальна, хотя на альтерке/ксайлинксе успешно синтезируется), и переживают сброс по DCLO или INIT как в реальном процессоре
- фаза предделителя тоже теперь не портится сбросом процессора по DCLO или INIT, как в реальном процессоре
В модель симуляции Async или эмулятор добавить ненулевые инициализации не проблема, в синтезируемые - лучше ненунаНо что касается R0 .. R6 - там при включении питания всегда надо эмулировать аутентичные значения. А то получается, что большая часть из написанных мною ПЗУ-тестов 1801ВМ1 могут не работать на реальном процессоре, потому что они прямо рассчитаны на обнуление процессором R0 .. R6 при включении питания.
Если бы в модели 1801ВМ1 не была изначально заложена столь критичная неадекватность - под сотню тестов не оказались бы под подозрением.
- - - Добавлено - - -
процессор при загрузке ПЛИС живет какое-то время своей жизнью (исполняет мусор с пустой шины)Т.е. процессор что-то делает до снятия DCLO ?
Но что касается R0 .. R6 - там при включении питания всегда надо эмулировать аутентичные значения. А то получается, что большая часть из написанных мною ПЗУ-тестов 1801ВМ1 могут не работать на реальном процессоре, потому что они прямо рассчитаны на обнуление процессором R0 .. R6 при включении питания.
Реальный процессор ничего не обнуляет, ни при включении питания, ни по сбросу. Его регистры - такие же обычные триггеры, без входов сброса/установки. При подаче питания принимают случайные значения, при сбросе сохраняют то что в них было. Начальная микропрограмма записывает 340 в PSW и записывает в PC <старший байт из @#177716>:8'o000 (подлежит уточнению как это сделано). Остальные регистры не обнуляются и никак не изменяются.
V-модель задает нулевые значения регистров при включении питания, сброс регистры переживают, как и в реальном процессоре. Сделать ненулевые начальные в регистрах - несложно и не будет стоить ресурсов (для ВМ1, по крайней мере - оно там в блоке памяти находится, память прогружается при включении питания из конфигурации ПЛИС).
Содержимое регистров по включению питания реального ВМ1Г:
R0: 077577
R1: 176777
R2: 001010
R3: 004042
R4: 011113
R5: 053756
R6: 041202
Реальный ВМ1А:
R0: 133000
R1: 100514
R2: 100410
R3: 040000
R4: 100057
R5: 060000
R6: 000011
Повторяемость хорошая, если нажать сброс там уже будут другие значения, и не всегда одни и те же - зависит от момента в каком месте программы настиг сброс по DCLO.
Т.е. процессор что-то делает до снятия DCLO ?
Думаю дело не в процессоре, по DCLO автомат микропрограммы остановлен точно. У меня разрушалось ОЗУ с программой при перепрошивке ПЛИС, полагаю это проблема где-то в проекте, пока вставил блокировку записи до сброса и старта процессора. На всякий случай тесты выше проведены удерживая кнопку сброса при включении питания, то есть процессор гарантировано ничего не исполнял до отпускания кнопки и регистры сохранились.
При подаче питания принимают случайные значения, при сбросе сохраняют то что в них было.Чтобы адекватно эмулировать различия в поведении процессора при подаче питания и при снятии DCLO - есть смысл добавить в CPP-модель публичный метод C1801VM1::Power_ON(), где можно было бы выполнять начальные установки значений регистров, в зависимости от текущего типа процессора.
- - - Добавлено - - -
И в программную модель шины МПИ надо бы добавить линию DC5V, чтобы знать, когда в подключенных к шине эмуляторах осуществлять "включение питания".
А для чего вообще нужно привязываться к неким константам в регистрах? Ведь нет вообще никакой гарантии, что они не уникальны для разных партий кристаллов. Я вообще предпочитаю предполагать, что изначальные значения регистров рандомные и ими необходимо пренебречь. Я бы вообще структуры reg и wire использовал бы с не инициализированными переменными, для эмуляции случайных состояний триггеров, но из-за использования операции XOR с булевыми переменными, это невозможно.
Patron, делайте с исходниками что хотите и модифицируйте их как сочтёте необходимым. У меня как-то застопорился всякий прогресс в этом деле. Чтобы как-то двигаться дальше, мне необходимо минимум три модели, взаимодействующие между собой через МПИ, две есть: ВМ1 и ВП1-037 (на си пока не переведённая, т.к. простая и это не сложно сделать), а вот с третьей, которой я выбрал ВП1-065 до сих пор ничего не получается.
А для чего вообще нужно привязываться к неким константам в регистрах?Эти значения уникальны для каждого экземпляра, но неизменны от включения к включению, поэтому (как ни странно) - копия актуальных значений тестируемого экземпляра является наиболее точной эмуляцией.
с третьей, которой я выбрал ВП1-065 до сих пор ничего не получается.Предлагаю попробовать скомпилировать адаптер МПИ (http://zx-pk.ru/showthread.php?t=25252) - исходники CPP-модели там лежат в оригинальном виде в их родном каталоге \MODULES\MPI_module\vm1cpu\.
Эмуляция последовательного порта в адаптере МПИ максимально точная - там можно даже (как в реальном порту) создавать фейковые посылки при помощи программного управления состоянием BREAK.
Решая проблему глюка RPLY, выяснил, что глюк проявляется, если RPLY меняет своё состояние в пределах одного (или 1,5) такта после изменения состояния DIN (по крайней мере DIN, может и с DOUT так же было).
После этого, заменил весь код, где используются reg [3:0] rply_ack кодом из модели Async и глюк пропал. Правда при этом SYNC стал сниматься на 1 такт позже, да и DIN держится на 1 такт дольше , зато теперь работа модели не зависит от фазы ТЧ и опроса периферии через такт или полтакта.
Вообще, заменённый код местами неожиданно отличается от кода в Qsync. Может быть при оптимизациях где-нибудь вкралась ошибка?
Вот что получилось 55166 код, приводивший удлинение на такт закомментирован, и оставлен тот, что из Qsync, более быстрый.
глюк проявляется, если RPLY меняет своё состояние в пределах одного (или 1,5) такта после изменения состояния DINВо всех версиях CPP-модели момент установки RPLY роли не играет - глюк зависит только от момента снятия RPLY. Даже при нулевой задержке снятия RPLY - выравнивание защищает от глюка.
- - - Добавлено - - -
Вообще, заменённый код местами неожиданно отличается от кода в Qsync. Может быть при оптимизациях где-нибудь вкралась ошибка?ЗДЕСЬ (http://zx-pk.ru/showthread.php?t=23978&p=838026&viewfull=1#post838026) утверждается, что в Verilog-версии модели Qsync момент снятия RPLY роли не играет.
Для моделей Qsync/Wsync проверка RPLY не имеет смысла (хотя Qsync тоже немного погонял, все нормально работает)Как выяснилось - проблема именно в CPP-версии модели Qsync. Если деактивировать сигнал RPLY между eval_p и eval_n - модель не снимает SYNC вплоть до установки DCLO.
В Verilog-версии модели Qsync точно нет такой проблемы ?
В Verilog-версии модели Qsync точно нет такой проблемы ?
Ну... Если ModelSim не шутит, то в модели QSync такой проблемы нету :)
Еще раз снял диаграмму:
http://s005.radikal.ru/i209/1512/68/32c0fbdb0fbdt.jpg (http://s005.radikal.ru/i209/1512/68/32c0fbdb0fbd.png)
Красным отмечено снятие RPLY при положительном значении CLC, через 2 нс после фронта.
RPLY снимает (и управляет всеми другими внешними сигналами) специальный модуль, называется testbench (файл tbench.v), пишется для тестовых целей и является внешним по отношению к модели. То есть для модели это выглядит как внешнее воздействие, внутри она никак не меняется при тестировании. Заводской тест 401 проходит при любых комбинациях снятия RPLY.
Там была другая проблема, при обращении к 1777хх были очень короткие импульсы DOUT - оно выходило по первому же RPLY, обнаруженному по фронту CLC. Это несовпадало с реальным процессором и я перекинул на второй RPLY на фронте CLC. Схему перепроверял на нескольких процессорах, она верная, поэтому списал на физическую задержку, то есть RPLY при обращении к внутренним регистрам не успевал на первый фронт CLC. Там есть коммент на тему:
assign dout_start = dout_req_rc & qbus_flag_rc & ~rply_ack[2]; // originally ~rply_ack[1]
Все остальные циклы - DATI/DATO/DATIO/IAK сначала сверялись на модели Async с реальным процессором. Было достигнуто потактовое совпадение. Потом прошел тест 401, при этом симулятор показывает сколько времени модели затрачено на прохождение теста, ну скажем 544520 нс.
Потом писалась модель Qsync, писалась она путем модификации Async, при этом на ней многократно в ходе разработки прогонялся тест 401 и сверялось в том числе затраченное время, оно должно полностью совпадать с моделью Async (544520нс). Ну и диаграммы тоже сравнивались, их длительности и моменты запуска полностью совпадали.
Потом уже делалась WSync модификацией QSync, там уже времянка немного разошлась, шина же другая, но встроен специальный механизм для медленного режима, при его работе моменты запуска транзакций будут полностью совпадать как это делал бы процессор на родной частоте (до 5МГц). Эта задумка написана, но еще не проверялась - она должна работать в связке с дульным компенсатором эмулятором-замедлителем ВП1-037, которого пока нету.
- - - Добавлено - - -
Давно не брал я в руки шашек смотрел в микроскоп :)
Пока игрался с модулем и перетыкал микропроцессоры, определился самый слаборазгоняемый экземпляр 1801ВМ3, к тому же у него ножки немножко в процессе покоцались, пришлось его на мясо пустить открыть.
http://s018.radikal.ru/i516/1512/0a/e4c73e289e53t.jpg (http://s018.radikal.ru/i516/1512/0a/e4c73e289e53.jpg)
Кристалл незначительно больше по площади чем 1801ВМ1 (на 20-25 процентов), но транзисторов по прикидкам должно быть тысяч 25, значит нормы уменьшили. И действительно - 3 мкм ширина затвора и проводников. У ВМ1 было 5 мкм, у ВМ2 - 4 мкм. Не великий прогресс за 8 лет, но то такое. Стекло на кристалле грязноватое, попробую спиртиком помыть и отфотать на увеличении x10. Но уже мелковато, как бы не пришлось снимать на x20 (а это за 400 снимков выйдет), и у меня уже 16ГБ памяти такую панораму собрать не хватает.
Кристалл незначительно больше по площади чем 1801ВМ1 (на 20-25 процентов), но транзисторов по прикидкам должно быть тысяч 25, значит нормы уменьшили.
На картиночке качества несколько не хватает для понимания.
По сравнению со стройными рядами элементов в ХМ1, выглядит хаотично)
На картиночке качества несколько не хватает для понимания.
Дело не только в качестве, структура нерегулярная, нельзя выделить библиотеку ячеек. А чтобы можно было разобраться - надо шлифовать слой металла и снимать "диффузию", иначе неразбирабельно даже при очень-очень качественной картинке и бОльших проектных нормах (сужу по 580 и 581 сериям).
ВМ3 - это уже КМОП или еще НМОП?
Как выяснилось - проблема именно в CPP-версии модели Qsync.
Ну, я никогда и не утверждал, что CPP модель достоверно работает, она наоборот, в силу каких-то неясных для меня нюансов работает не так, как Verilog модель, хотя казалось бы, всё сделано точь-в-точь как в верилоге.
Vslav, вот есть такая штука "always @(posedge pin_clk_p)", в ней регистр mjres меняет своё значение, допустим с 0 на 1.
Как в таком случае должен выполняться "always @(posedge pin_clk_p or posedge mjres)"? Сперва часть кода в соответствии с "posedge pin_clk_p", как и для предыдущего alwaysа, а затем в этой же итерации - часть кода в соответствии с вновь возникшим "posedge mjres", затирая результаты выполнения этого alwaysа для "posedge pin_clk_p" или всё таки обрабатывать "posedge mjres" в следующей итерации?
ВМ3 - это уже КМОП или еще НМОП?
Все тот же n-МОП.
- - - Добавлено - - -
Vslav, вот есть такая штука "always @(posedge pin_clk_p)", в ней регистр mjres меняет своё значение, допустим с 0 на 1.
Как в таком случае должен выполняться "always @(posedge pin_clk_p or posedge mjres)"? Сперва часть кода в соответствии с "posedge pin_clk_p", как и для предыдущего alwaysа, а затем в этой же итерации - часть кода в соответствии с вновь возникшим "posedge mjres", затирая результаты выполнения этого alwaysа для "posedge pin_clk_p" или всё таки обрабатывать "posedge mjres" в следующей итерации?
При положительном фронте clk_p для always @(posedge pin_clk_p or posedge mjres) надо сначала обработать событие положительного фронта. Там в блоке стоит обычно сразу if (mjres), если он ненулевой на момент наступления фронта, то объект и останется в сбросе. Если же mjres нулевой, то отрабатывается смысловая часть объекта, на выходе получается набор каких-то значений, которые еще не перенесены в основное состояние, а находятся в промежуточном буфере, то есть оно ни на что еще не повлияло. Потом вычисляется mjres, и оказывается что его состояние изменилось с 0 в 1, и возникло событие posedge mjres, тогда снова обрабатывается объект, он переходит в состояние сброса, но значения на выходе опять-таки попадают в промежуточный буфер. Когда в процессе итераций всякие изменения закончились - можно считать что событие фронта clk_p полностью обработано, можно переносить новые состояния всех сигналов в постоянный буфер. Поэтому порядок обработки событий posedge pin_clk_p и posedge mjres никак не должен влиять на результат.
Еще есть особенность что новый mjres находится в промежуточном буфере и ни на что вроде бы не должен влиять, но поскольку он упомянут в posedge, то для него надо делать исключение. Там собственно всего четыре исключительных сигнала - reset, mjres, abort и qbus_tena (и в ВЕ-таймере еще парочка). Возможно их надо вычислить в начале обработки clk_p (они фиксируются по clk_p и более не изменяются), а дальше вычислять все остальное, учитывая новые значения 'исключительных'.
С регистрами в условии чувствительности разобрался, даже вроде как реализовал рабочий вариант.
А вот с wireм в условии чувствительности возникли проблемы. Возьмём этот always
always @(posedge pin_clk_n or negedge qbus_tena)
begin
if (~qbus_tena)
qbus_timer <= 6'o00;
else
if (~qbus_tovf)
qbus_timer <= qbus_timer + 6'o01;
end
допустим, где-то между фронтами частоты, произошло событие "qbus_tena 1->0", при этом этот always сработал, выполнилась часть
qbus_timer <= 6'o00;
затем случилось событие "posedge pin_clk_n", но qbus_tena остался равен 0, должен ли при этом выполняться код
if (~qbus_tovf)
qbus_timer <= qbus_timer + 6'o01; игнорируя условие "if (~qbus_tena)" или нет?
У меня работает только такой вариант:
void C1801VM1::eval_all_n()
{
...
if (wire.qbus_tena)
{
if (!snap_reg.qbus_tovf)
{
reg.qbus_timer = (snap_reg.qbus_timer + 1) & 077;
}
}
...
}
т.е. код по событию "posedge pin_clk_n" выполняется только если qbus_tena == 1, а иначе, если закомментировать строку "if (wire.qbus_tena)" перестаёт работать команда RESET, т.е. она становится бесконечной, и вызывает ошибку зависания на шине.
допустим, где-то между фронтами частоты, произошло событие "qbus_tena 1->0"
Это событие не может произойти между фронтами частоты. Находим источник qbus_tena:
assign qbus_tena = dout_out | din_out;
и видим что он зависит от двух регистров dout_out и din_out, которые, в свою очередь
меняются по clk_p и mjres, последний меняется тоже только по clk_p.
Поэтому оптимальный порядок при событии clk_p такой:
- вычислили значение mjres, abort, reset
- занесли, в виде исключения эти три новых значения в исходное состояние, на базе которого
будет вычисляться все остальное
- вычислили din_out, dout_out и производный qbus_tena
- для qbus_tena опять сделали исключение, сразу заносим в исходное
- тут можно повычислять еще "исключительные" сигналы, типа tve_reset
- вычисляем все остальное
В исходное состояние можно не заносить (если там есть какой анализ изменения ил чего еще),
но вычисление зависимых блоков надо делать на основе нового значения "исключительных" сигналов.
Если делать совсем правильно, то считать несколько событий:
- posedge clk_p
- posedge reset
- posedge abort
- posedge mjres
- negedge qbus_tena
При каждом вычислении мониторить не возникло ли какое новое событие и потом его снова перевычислять. То что описано ранее - это просто оптимизация, предлагается сначала вычислить "исключительные" сигналы
в ходе обработки события clk_p. Это основано на том что в данной модели эти исключительные сигналы после фронта clk_p не зависят от всех остальных сигналов и больше не будут меняться. А после однократно посчитать все остальное с учетом нового состояния этих "исключительных" сигналов.
затем случилось событие "posedge pin_clk_n", но qbus_tena остался равен 0, должен ли при этом выполняться код
if (~qbus_tovf)
qbus_timer <= qbus_timer + 6'o01; игнорируя условие "if (~qbus_tena)" или нет?
Не должен, почему следует игнорировать условие ~qbus_tena? Оно как раз выполняется при qbus_tena==0, там же инверсия ~. А код стоит в ветке else и он не выполняется.
У меня работает только такой вариант:
if (wire.qbus_tena)
{
if (!snap_reg.qbus_tovf)
{
reg.qbus_timer = (snap_reg.qbus_timer + 1) & 077;
}
}
Да, тут все правильно, соответствует исходному Верилогу. Если qbus_tena нулевой, то таймер удерживается в сбросе, если ненулевой - идет счет до появления флага переполнения, на нем счет останавливается.
balu_dark
11.12.2015, 22:35
Тут еще важно не путать Верилог с его параллельным исполнением всего и С с его последовательной обработкой. С никогда не будет при одинаковом написании вести себя как модель VHDL или Verilog. И если честно - я даже не представляю как реальную параллельность процессов представить в С.
Если ModelSim не шутит, то в модели QSync такой проблемы нетуНо есть проблема с запуском модели QSync под голым ModelSim ( без квартуса и альтеровских библиотек ) - во всяком случае с ModelSim SE 10.2c (http://rutracker.org/forum/viewtopic.php?t=4620396) такое не получилось. Предлагаю попробовать поставить на виртуальную машину голый ModelSim, создать в нём родной проект, запустить симуляцию теста команд в модели QSync и выложить получившийся тестовый комплект.
Но есть проблема с запуском модели QSync под голым ModelSim
Какая именно проблема? Модель зависает на снятии RPLY? Или проблемы создания/запуска собственно проекта?
Но есть проблема с запуском модели QSync под голым ModelSim
( без квартуса и альтеровских библиотек)
Нет понятия "голый ModelSim", Квартус просто создает файлы проекта для ModelSim и запускает его. Далее MS работает самостоятельно, Квартус на него никак не влияет - вся связь между программамми через файлы.
ModelSim-ы тоже бывают разные, можно в Квартусе указать какой именно запускать, раньше использовал ModelSim 10.1 Altera Starter Edition, но там включается ограничение на скорость симуляции после достижения предела ячеек, перешел на полный Altera Edition. Библиотеки, кстати, тоже нужны, там есть файл vm1_alib.v куда вынесены зависимые от альтеры модули, чтобы их можно было легко заменить при переходе на другую платформу.
Предлагаю попробовать поставить на виртуальную машину голый ModelSim, создать в нём родной проект, запустить симуляцию теста команд в модели QSync и выложить получившийся тестовый комплект.
Это бесполезная трата времени, вероятность что проблема в ModelSim невелика, лучше время потратить на поиск ошибки в C++, может быть, смогу разобраться.
Кстати, есть более простые симуляторы - например, Icarus Verilоg, с ним можно намного быстрее разобраться. Он, правда, больше текстовый, но диаграммы тоже можно получить.
Какая именно проблема?Проблема не одна.
Для начала добавление папки source в проект ModelSim не позволяет искать в ней включаемые файлы, поэтому проект не компилируется:
http://pic.pdp-11.ru/images/msim1.png
Решается перемещением содержимого папок в корень проекта.
Но запуск симуляции всё равно не идёт :
http://pic.pdp-11.ru/images/msim2.png
Решается исключением из проекта de0top.v и vm1_alib.v и редактированием vm1_qbus.v.
После этого модель загружается для симуляции, хотя макрос wave.do и ругается на отсутствие исключённых объектов.
Теперь запускаем симуляцию и получаем:
http://pic.pdp-11.ru/images/msim3.png
Для начала добавление папки source в проект ModelSim не позволяет искать в ней включаемые файлы, поэтому проект не компилируется:
Хорошо, тут надо видимо мне собрать проект для ModelSim "с нуля". Правда мне до сих пор этого делать ни разу не приходилось.
Решается исключением из проекта de0top.v и vm1_alib.v и редактированием vm1_qbus.v.
de0top можно безболезнено исключить, он нужен только квартусу для успешного синтеза и совсем не нужен для симуляции.
vm1_alib.v можно попытаться исключить если в config.v определить нулевое CONFIG_VM1_CORE_REG_USES_RAM.
Там оно еще не нашло файл с программой - test.mem, получается после компиляции тестов из папки Ztest.
надо видимо мне собрать проект для ModelSim "с нуля"Об том и речь - надо бы сделать тестовый комплект для запуска модели QSync на голом ModelSim.
Библиотеки, кстати, тоже нужны, там есть файл vm1_alib.v куда вынесены зависимые от альтеры модулиА есть ли эти библиотеки в комплекте ModelSim SE 10.2c (http://rutracker.org/forum/viewtopic.php?t=4620396) :
http://pic.pdp-11.ru/images/msim4.png
И если да, то как их использовать при симуляции ?
Об том и речь - надо бы сделать тестовый комплект для запуска модели QSync на голом ModelSim.
А почему бы не запускать симуляцию одной кнопкой из Квартуса?
Архив (http://u.zeptobars.ru/yuot/MISC/msingle.rar) для ModelSim Altera Edition.
- отредактировать пути в vm1_run.do
- запустить ModelSim
- перейти в каталог с проектом (->File->Change Directory)
- запустить vm1_run.do
- удалить диаграммы по умолчанию в окне диаграмм
- запустить wave.do
Дальше симулировать
В test.mem - исполняемая программа
А почему бы не запускать симуляцию одной кнопкой из Квартуса?Квартус весит на порядок больше - у меня в виртуальной машине с ModelSim осталось только 3 Гб свободного места, поэтому узнать простой и удобный способ запуска симуляции модели QSync в ModelSim будет (надеюсь) быстрее, чем качать и ставить Квартус.
Я в предыдущем письме добавил архив для ModeiSim, проверил, вроде работает. Но есть вероятность что ему все равно альтеровские библиотеки понадобяться (в Квартус у меня устновлен).
есть вероятность что ему все равно альтеровские библиотеки понадобятсяИ эта вероятность равна 100%.
Но изменение в config.v значения CONFIG_VM1_CORE_REG_USES_RAM на 0 действительно решает проблему ( мне слабо переделать vm1_run.do, поэтому набор для симуляции: QSync_for_ModelSim.zip (http://emulator.pdp-11.org.ru/misc/QSync_for_ModelSim.zip) надо запускать через создание обычного родного проекта ModelSim ).
http://pic.pdp-11.ru/images/msim5.png
Но вот вопрос - как заставить ModelSim выводить значение линий AD в инверсном ( т.е. нормальном ) виде ?
О, симуляция пошла, замечательно!
Но вот вопрос - как заставить ModelSim выводить значение линий AD в инверсном ( т.е. нормальном ) виде ?
Тут простого ответа я не знаю, можно завести дополнительный сигнал, например i_ad[15:0], назначить ему в исходниках инверсию от pin_ad, и смотреть уже его. Или в подпапке <root>/Qbus есть диаграммы регистров адреса (areg) и данных (qreg), они инвертированы, можно сами значения из них брать. Они вполне мышкой перетаскиваются, можно копи-пастить, то есть легко расположить рядом с диаграммой ad.
.
В тактовом генераторе tbench.v есть ошибка из-за которой весь нулевой такт сигнал clk остаётся неизменным, а первый такт ( как и все последующие ) начинается с положительного полупериода :
http://pic.pdp-11.ru/images/msim6.png
Если изменить код так:
//__________________________________________________ ___________________________
//
// Clock generator
//
initial
begin
ena = 1;
clk = 0;
nclk = 0;
forever
begin
`ifdef CONFIG_SIM_DEBUG_MC
$display("clk: %04d", nclk);
`endif
clk = 0;
#(`CONFIG_SIM_CLOCK_HPERIOD);
clk = 1;
#(`CONFIG_SIM_CLOCK_HPERIOD);
nclk = nclk + 1;
end
end
То работа тактового генератора приходит в норму и растактовка исправляется:
http://pic.pdp-11.ru/images/msim7.png
.
В тактовом генераторе tbench.v есть ошибка из-за которой весь нулевой такт сигнал clk остаётся неизменным, а первый такт ( как и все последующие ) начинается с положительного полупериода :
Это не ошибка, такая особенность первого клока в тестбенче не приводит ни к каким принципиальным последствиям - понятие такт очень условно, просто вот так нарисовалась сеточка на диаграмме, и все процессы сдвинулись на 5 нс. Можно банально вертикальную сеточку сделать 5 нс (оно автоматом, просто позумить в окошке), чтобы отметить и фронты и срезы и чуток проскроллить вправо - и разницы вообще глазом не увидеть. Отладочный nclk остался со времен отладки микроавтомата, тогда его фаза имела смысл, но сейчас его уже можно и вообще удалить.
Update: часто бывает что тактовая от PLL формируется, тогда в начальный момент симуляции тактовой частоты вообще нет, появляется со временем и в произвольной фазе, поэтому привязываться к "сеточке" бессмысленно.
Update2: сейчас LSI-11 разбираю, там 4 тактовых сигнала, все тоже должно быть инвариантно, независимо с какого C1-C4 начнется счет.
Update3: обновление 1.4D (http://u.zeptobars.ru/yuot/1801/VM1/vm1_rev14d.rar)
- изменена структура каталогов (потихоньку приближаемся к требованиям OpenCores)
- теперь можно перейти в каталог симуляции и запустить в ModelSim (Altera Edition можно Started/Полный) файл run.do. Удалены все зависимости от путей, для проектов Async/Qsync Quartus при этом не нужен, сразу симулируется с полным пакетом диаграмм.
- проект Async не требует для симуляции альтеровских библиотек
- добавлен тест вычисления знаков числа Пи
Отладочный nclk остался со времен отладки микроавтомата, тогда его фаза имела смысл, но сейчас его уже можно и вообще удалить.Сейчас как раз идёт отладка CPP-модели ( методом потактового сравнения содержимого переменных ), поэтому правильная фаза nclk играет важную роль.
- - - Добавлено - - -
Прояснилась причина, по которой CPP-модель не снимала SYNC при снятии RPLY между eval_p() и eval_n().
Сигнал oe_clr_fc использовался в eval_all_n() раньше, чем устанавливался в assign_all(), а поскольку этот сигнал активен только полтакта, то к следующему вызову eval_all_n() сигнал уже снова был сброшен и поэтому SYNC оставался установленным "вечно".
Вообще говоря - используемый в CPP-модели подход методически ложен:
void eval_n()
{
eval_all_n(); // выполняем все always для переднего фронта
assign_all(pMPI); // вычисляем все assignы
}
Методически корректный подход выглядит так:
void eval_n()
{
assign_all(pMPI); // вычисляем все assignы
eval_all_n(); // выполняем все always для переднего фронта
assign_all(pMPI); // вычисляем все assignы
}
А практически правильный подход может быть таким:
void eval_n()
{
assign_in(pMPI); // вычисляем все входные зависимости
eval_all_n(); // выполняем все always для переднего фронта
assign_out(pMPI); // вычисляем все выходные зависимости
}
- - - Добавлено - - -
В ходе тестирования модели QSync выяснился интересный момент.
При осуществлении записи сначала выставляются на шину прошлые данные записи и только затем - новые.
Например, при выполнении на модели процессора 1801ВМ1 следующего кода:
.ASect
. = 0
MOV R0, (PC)+
NOP
MOV R1, (PC)+
NOP
MOV R2, (PC)+
NOP
MOV R3, (PC)+
NOP
MOV R4, (PC)+
NOP
MOV R5, (PC)+
NOP
MOV SP, (PC)+
NOP
HALT
Процессор пишет в память начальное содержимое регистров:
gpr[0] = 0133000;
gpr[1] = 0100514;
gpr[2] = 0100410;
gpr[3] = 0040000;
gpr[4] = 0100057;
gpr[5] = 0060000;
gpr[6] = 0000011;
И при выполнении команды MOV R1, (PC)+ - осциллограмма выглядит так:
http://pic.pdp-11.ru/images/msim8.png
Лог при этом выглядит так:
# [000085]-1- ad_ena: 0 ; pin_ad_out: 000000 ; dout_out: 0 ; qrd: 133000
#
# [000085]-0- ad_ena: 0 ; pin_ad_out: 000000 ; dout_out: 0 ; qrd: 133000
#
# [000086]-1- ad_ena: 0 ; pin_ad_out: 000000 ; dout_out: 0 ; qrd: 133000
#
# [000086]-0- ad_ena: 1 ; pin_ad_out: 133000 ; dout_out: 1 ; qrd: 133000
#
# [000087]-1- ad_ena: 1 ; pin_ad_out: 100514 ; dout_out: 1 ; qrd: 100514
#
# [000087]-0- ad_ena: 1 ; pin_ad_out: 100514 ; dout_out: 1 ; qrd: 100514
#
# [000088]-1- ad_ena: 1 ; pin_ad_out: 100514 ; dout_out: 1 ; qrd: 100514
#
# [000088]-0- ad_ena: 1 ; pin_ad_out: 100514 ; dout_out: 1 ; qrd: 100514
Интересно, как выглядит аналогичная осциллограмма при выполнении записи реальным 1801ВМ1.
Интересно, как выглядит аналогичная осциллограмма при выполнении записи реальным 1801ВМ1.
Совсем так точно не выглядит - в реальной системе RPLY побыстрее ставится и снимается, а процессор ведет себя точно также - выставляет/снимает сигналы в той же фазе (ну еще задержку надо учитывать, примерно 10-15нс вносят буфера, остальное - родная задержка Tco микросхемы ВМ1). И достоверные данные появляются на шине одновременно со спадом DOUT: [http://s019.radikal.ru/i640/1512/28/ba14c1dfe198t.jpg (http://s019.radikal.ru/i640/1512/28/ba14c1dfe198.png)]
Update: в строке 1475 vm1_qbus.v можно сменить полярность pin_clk_n на pin_clk_p, тогда достоверные данные записи будут выставляться на шине за полтакта до DOUT. При этом граничная частота проекта на реальном Циклоне-3-С8 падает с 90МГц до 72МГц. Наверное, придется пожертвовать. Версии на Wishbone эта проблема не касается.
Update2: а вообще, не так плохо все, на speedgrade C6 частота падает до 95МГц всего, после тестирования изменение можно внести постоянно.
Методически корректный подход выглядит так:
При этом получается, что assign_all(pMPI); перед обоими eval_all_x(); избыточен, поскольку eval_n() и eval_p() вызываются последовательно друг за другом. Развёрнутая цепочка вызовов функций внутри цикла вызовов последовательности eval_n() и eval_p() выглядит так.
{
assign_all(pMPI);
eval_n();
eval_p();
assign_all(pMPI);
} init
eval_n();
assign_all(pMPI);
eval_p();
assign_all(pMPI);
eval_n();
assign_all(pMPI);
eval_p();
assign_all(pMPI);
.....
Именно так выглядит цикл, генерируемый Верилатором.
А практически правильный подход может быть таким:
Я такой подход реализовать не смог. Т.к. у меня не получилось сделать обёртку vm1.v над vm1_qbus.v, такая модель не получалась работоспособной в принципе, пришлось разворачивать их в одну большую плоскую функцию. При этом получилось так, что входные зависимости (ноги, у которых тип inout), зависят от выходных в текущей итерации. Поэтому функция assign_all у меня минимум двухпроходная. И изредка выполняется за три прохода, из-за изменения данных в переменной pin_ad_n.
При этом получается, что assign_all(pMPI); перед обоими eval_all_x(); избыточен, поскольку eval_n() и eval_p() вызываются последовательно друг за другом.Это ошибочное впечатление, потому что на самом деле там ещё есть вызов eval(pMPI) ( который делается в tboard.cpp ) и полная последовательность вызовов выглядит так:
eval_n();
assign_all(pMPI);
eval(pMPI)
eval_p();
assign_all(pMPI);
eval(pMPI)
eval_n();
assign_all(pMPI);
eval(pMPI)
eval_p();
А должна выглядеть так:
eval_n();
assign_all(pMPI);
eval(pMPI)
assign_all(pMPI);
eval_p();
assign_all(pMPI);
eval(pMPI)
assign_all(pMPI);
eval_n();
assign_all(pMPI);
eval(pMPI)
assign_all(pMPI);
eval_p();
- - - Добавлено - - -
Именно так выглядит цикл, генерируемый Верилатором.Если добавить в проект Верилятора обработку tbench.v, то результат будет другим ( из-за учёта влияния памяти и устройств на состояние сигналов шины между вызовами ).
Я такой подход реализовать не смог.Можно сделать две копии assign_all(pMPI) и выкинуть из первой все зависимости от сигналов, которые не изменяются памятью и устройствами ( типа BSY, SYNC, DIN, DOUT ), а из второй - от сигналов, которые не изменяет процессор ( типа IRQ1, IRQ2, IRQ3, VIRQ, DMR ).
- - - Добавлено - - -
можно сменить полярность pin_clk_n на pin_clk_p, тогда достоверные данные записи будут выставляться на шине за полтакта до DOUTВ реале данные выставляются на одном полутакте с DOUT, поэтому лучше задержать на полтакта активацию pin_ad_ena.
В реале данные выставляются на одном полутакте с DOUT, поэтому лучше задержать на полтакта активацию pin_ad_ena.
Нет, просто там была частота высокая (5.0МГц), задержки в кучу смешались.
http://pic.pdp-11.ru/images/dia01.png
При более низкой частоте видно что данные на шине появляются при высоком CLC (после фронта), а nDOUT активируется при низком CLC (после спада). И это правильно для МПИ, ГОСТ 26765.51-86 требует хотя бы 25 нс предустановленных данных перед спадом nDOUT. На диаграмме 100МГц отсчеты, поэтому одно деление - 10нс, требование стандарта успешно выполняется.
обновление 1.4D (http://u.zeptobars.ru/yuot/1801/VM1/vm1_rev14d.rar)В модели ASync фаза генератора тактовой частоты не исправлена.
Правильный код такой:
//__________________________________________________ ___________________________
//
// Clock generator
//
initial
begin
ena = 1;
forever
begin
clk = 0;
#(`SIM_CONFIG_CLOCK_HPERIOD);
clk = 1;
#(`SIM_CONFIG_CLOCK_HPERIOD);
end
end
В модели ASync фаза генератора тактовой частоты не исправлена.
Да оно непринциально, но ОК, внесу.
В модели Wsync частота с PLL берется, там на начальную фазу повлиять нет возможности.
При более низкой частоте видно что данные на шине появляются при высоком CLC (после фронта), а nDOUT активируется при низком CLC (после спада). И это правильно.Модель ASync подтверждает:
http://pic.pdp-11.ru/images/msim9.png
Да, Async правильно работает, там qreg является латчем. С исправлением на clk_p в регистре qreg, Qsync тоже так начинает работать, только Fmax падает (времени такта АЛУ не хватает чтобы результат на qreg дать). В Async коррекцию внесу, в Wsync - оно там не нужно, нет Qbus.
Да, Async правильно работает, там qreg является латчем.Значит ли это, что методически правильно вычислять значение qreg на каждом полутакте ?
Для CPP-модели сто вёрст не крюк, поэтому лишнее вычисление qreg на быстродействие модели не повлияет.
Значит ли это, что методически правильно вычислять значение qreg на каждом полутакте ?
Для Async модели надо вычислять значения всех величин по любому изменению входных сигналов, в том числе и по тактовому. И вычислять итеративно в цикле до достижения стабильного неизменного состояния выходных переменных.
Для Async модели надо вычислять значения всех величин по любому изменению входных сигналов, в том числе и по тактовому.Но CPP-модель основана на модели Qsync, поэтому вопрос про неё. Не зря ведь там qreg вычислялся именно по P-фронту.
Другими словами вопрос в том, справедливы ли следующие утверждения для модели Qsync:
1. Вычисление qreg по P-фронту имеет смысл.
2. Вычисление qreg по N-фронту имеет смысл.
Но CPP-модель основана на модели Qsync, поэтому вопрос про неё. Не зря ведь там qreg вычислялся именно по P-фронту.
До недавнего анализа диаграммы записи qreg защелкивалось по clk_n, видимо, когда портировалось это обеспечило хорошую прибавку к Fmax. Вы выложили диаграмму записи, я начал думать что Вас в ней смущает, увидел что данные перед спадом nDOUT выглядят не очень, посмотрел на реальный процессор и решил защелкивать qreg по clk_p, это обеспечивает правильные потакта опережения данных перед nDOUT, но снижает Fmax проекта. Поскольку для синтеза ветка Async не является основным проектом, на Fmax этой ветки можно подзабить. Пока это исправление в релиз не внесено (хотя тест 401 уже прошло). Для Wsync ничего не меняется, там Fmax > 100MГц остается.
1. Вычисление qreg по P-фронту имеет смысл.
2. Вычисление qreg по N-фронту имеет смысл.
В исправленной версии qreg изменяется только по фронту clk_p, тут имеет смысл только eval_p();
В неисправленной (предыдущей) версии qreg изменяется только по фронту clk_n, тут имеет смысл только eval_n();
- - - Добавлено - - -
Версия 1.4e (http://u.zeptobars.ru/yuot/1801/VM1/vm1_rev14e.rar)
Внес изменения и потестировал Async/qreg, поправил тактовую в тестбенче, окончательно разложил файлы в каталоги согласно шаблона OpenCores - оно хоть и немного громоздко, но обладает самодокументируемостью.
теперь можно перейти в каталог симуляции и запустить в ModelSim файл run.doПосле запуска run.do шаг симуляции устанавливается в 100 ps - приходится каждый раз изменять его вручную на 500 ns.
http://pic.pdp-11.ru/images/msim10.png
После запуска run.do шаг симуляции устанавливается в 100 ps - приходится каждый раз изменять его вручную на 500 ns.
Так и должно быть, потому что в config.v прописано `timescale 1ns/100ps, странно что раньше по-другому было (у меня было и осталось 100ps).
Для решения проблемы можно или исправить config.v или не удалять файл modelsim.ini (там есть Resolution=). Может быть там с этиv файлом какие-то проблемы - нет прав доступа или чего еще.
А насчет 500ns непонятно, там все значения в ns указываются, и они единичные, странно что оно дает 500ns поставить и симулируется.
Update: run.do необязательно каждый раз для Async выполнять.
Можно сделать так:
- остановить симуляцию (если еще не остановлена) - Simulation/Break
[- заменить файл прошивки test.mem, если нужно]
[- отредактировать файлы .v если нужно]
[- перекомпилировать измененные .v, если таковые есть]
- перестартовать симуляцию - Simulation/Restart + OK
- запустить симуляцию заново - Simulation/Run All
насчет 500ns непонятно, там все значения в ns указываются, и они единичные, странно что оно дает 500ns поставить и симулируется.Эта установка ModelSim задаёт, через сколько симулированного времени будет прервана симуляция, запущенная командой run без аргументов ( или соответствующей кнопкой GUI ). Когда там 100 ps - одно нажатие на кнопку run отрабатывает симуляцию меньше одного такта CLC, если изменить на 500 ns - каждый run отрабатывает симуляцию достаточного количества тактов для выборки и исполнения симулируемым процессором пары команд.
Эта установка ModelSim задаёт, через сколько симулированного времени будет прервана симуляция, запущенная командой run без аргументов
Для этого в ModelSim.ini есть параметр
; Default run length
RunLength = 100
timescale на него влиять не должен
Update: достаточно прописать: RunLength = 500ns и запускается с 500 нс. Это к проекту не относится, где-то .ini сбойнул (или его просто в новом каталоге не было локального), может быть надо было установить 500нс и выйти-зайти в ModelSim.
Update2: можно в run.do добавить set RunLength 500ns и будет совсем хорошо :)
Для этого в ModelSim.ini есть параметрДело в том, что изначально файл ModelSim.ini в каталоге sim отсутствует, но после запуска оттуда run.do - файл ModelSim.ini там создаётся со значением RunLength по-умолчанию. Если же изначально иметь в каталоге sim собственный вариант ModelSim.ini с более логичными настройками - удобство пользователей только возрастёт.
Нет, просто там была частота высокая (5.0МГц), задержки в кучу смешались. При более низкой частоте видно что данные на шине появляются при высоком CLC (после фронта), а nDOUT активируется при низком CLC (после спада).Важно знать, остаётся ли неизменным у реального процессора 1801ВМ1 количество тактов в циклах DATI, DATO, DATIO, DATOB, DATIOB на частотах от 2 до 6 МГц - ведь иначе будет невозможна точная потактовая эмуляция работы реального процессора на реальных частотах.
Для начала можно было бы сравнить продолжительность в тактах выполнения теста команд реальным процессором 1801ВМ1 на частотах 2 и 6 МГц.
Важно знать, остаётся ли неизменным у реального процессора 1801ВМ1 количество тактов в циклах DATI, DATO, DATIO, DATOB, DATIOB на частотах от 2 до 6 МГц
Количество тактов варьируется лишь моментом ответа RPLY, а в остальном машина состояний никак не может зависеть от частоты, у нее же всего один опорный клок. То есть - в тактах длительность циклов поменяться с частотой не может.
Количество тактов варьируется лишь моментом ответа RPLY, а в остальном машина состояний никак не может зависеть от частоты.Т.е. съехать на следующий полутакт могут только изменения сигналов AD ( в фазе адреса - для всех циклов, в фазе данных - для циклов записи ), а изменения управляющих сигналов происходят в пределах "своего" полутакта во всём диапазоне рабочих частот.
- - - Добавлено - - -
На осциллограммах видно, что фронты сигналов отстают от фронта CLC на неизменное количество наносекунд, определяемое переходными процессами в триггерах. Когда продолжительность полутакта становится меньше времени отставания сигнала - изменение сигнала происходит на следующем полутакте.
Т.е. съехать на следующий полутакт могут только изменения сигналов AD ( в фазе адреса - для всех циклов, в фазе данных - для циклов записи ), а изменения управляющих сигналов происходят в пределах "своего" полутакта во всём диапазоне рабочих частот.
Ну как съехать... Процессор - машина состояний, и состояние между событиями CLC не изменяется само по себе (разряд затворов не учитываем, это физическая особенность реализованной схемотехники). После того как возникло событие CLC (фронт или спад) происходит его отработка, и длится эта отработка определенное почти фиксированное время. Вот как было с данными в цикле записи, пришел фронт CLC, начали разрешаться выходные буфера, ALU там довычисляло данные и тд, весь этот процесс начинается по фронту CLC и продолжается скажем 100 нс. Длительность завязана только на физические характиристики конкретных вентилей, пока они все отработают новое состояние и выдадут выходной результат. На частоте 2.5МГц длительность состояния высокого уровня CLC равна 200нс, значит вентили успеют выдать результат (за 100нс) до спада CLC, если частота 5МГц - выдадут как раз на спаде (100нс задержки равно полупериоду CLC), а на 7.5МГц результат будет уже после спада CLC. Еще иллюстрация - nDOUT активируется по срезу CLC в течение примерно 40нс, если бы можно было разогнать ВМ1 до 12МГц - то nDOUT на реальном процессоре "съехал" бы в следующий полутакт.
Модели же являются идеальными, этих физических задержек не учитывают, у них результат появляется мгновенно после события. Поэтому и сравнивать можно только сами реакции на события (фронты CLC, защелкивание RPLY и тд) а не точную совсем времянку. Я сравнивал с медленным процессором в БК-0010 на 3МГц, чтобы физические задержки были некритичными и можно было четко идентифицировать событие фронта или среза CLC, породившее изменение сигналов.
- - - Добавлено - - -
На осциллограммах видно, что фронты сигналов отстают от фронта CLC на неизменное количество наносекунд, определяемое переходными процессами в триггерах. Когда продолжительность полутакта становится меньше времени отставания сигнала - изменение сигнала происходит на следующем полутакте.
Да, именно так. Это как свет от звезды долго идет, там уже давно сферу Дайсона построили, а нам она все еще светит :)
nDOUT активируется по срезу CLC в течение примерно 40нс, если бы можно было разогнать ВМ1 до 12МГц - то nDOUT на реальном процессоре "съехал" бы в следующий полутакт.И тогда, при неизменной задержке RPLY в наносекундах - сигнал RPLY придёт уже на другом такте от начала команды, нежели на более низкой частоте. По идее - это должно изменить растактовку.
- - - Добавлено - - -
Я сравнивал с медленным процессором в БК-0010 на 3МГц, чтобы физические задержки были некритичными и можно было четко идентифицировать событие фронта или среза CLC, породившее изменение сигналов.А если установить неизменное выравнивание RPLY на ближайший фронт CLC и прогнать тест команд на реальном 1801ВМ1 на 2 МГц и на максимальной частоте конкретного процессора - будет ли затраченное количество тактов одинаковым ?
И тогда, при неизменной задержке RPLY в наносекундах - сигнал RPLY придёт уже на другом такте от начала команды, нежели на более низкой частоте. По идее - это должно изменить растактовку.
RPLY должен прийти за сколько-то нс до фронта CLC, важно успеет зафиксироваться по фронту процессором или нет, остальные моменты ничего не значат. Конечно, если по-другому прийдет RPLY то изменится растактовка системы в целом. Такая картина (http://zx-pk.ru/showthread.php?t=21192&p=846008&viewfull=1#post846008) наблюдалась на модуле с ВМ3, когда переписывалась отработка установки/снятия RPLY, на 4МГц/5МГц/6МГц растактовка цикла чтения отличалась, но это обусловленно именно задержками внешней системы, а не самого процессора, как только внешняя схема RPLY стала достаточно быстрой, процессор заработал одинаково на всех частотах.
- - - Добавлено - - -
А если установить неизменное выравнивание RPLY на ближайший фронт CLC и прогнать тест команд на реальном 1801ВМ1 на 2 МГц и на максимальной частоте конкретного процессора - будет ли затраченное количество тактов одинаковым ?
На реальном ВМ3 это было проделано. Но, если настаиваете, то можно прогнать и на ВМ1, полагаю что результат будет точно такой же.
Кстати, на системе с ВМ1 RPLY синхронизирован по срезу CLC, то есть - RPLY всегда гарантировано не успевает на первый фронт CLC после спада nDIN/nDOUT. Поэтому и результаты числа Пи на ВМ1 были пропорциональны частоте - циклы шины в тактах не менялись.
- - - Добавлено - - -
Открылась очередная партия всяко-разных микросхем, интересна AY-3-8912.
http://s020.radikal.ru/i704/1512/30/0278fb884215t.jpg (http://s020.radikal.ru/i704/1512/30/0278fb884215.jpg)
Вроде один слой металла и один слой поликремния, но транзисторов пока не вижу. Кстати, площадок под выводы на кристалле 40 штук, это значит что 8910 и 8912 - одна и та же микросхема, просто упакована в разные корпуса.
Update: посовещались с BarsMonster и пришли к выводу что поликремния тут нет. О как - металлические затворы без самосовмещения. Дешевая технлогия пещерных времен :)
Открылась очередная партия всяко-разных микросхем, интересна AY-3-8912.
https://ru.wikipedia.org/wiki/AY-3-8910 ???
https://ru.wikipedia.org/wiki/AY-3-8910 ???
Угу. 8910 я найти не смог, подвернулась 8912, были опасения что кристалл модифицирован, но вроде бы нет, просто ноги "лишние" проволочками не разварены.
Там еще парочка интересных микросхем, и есть желающие их пореверсить, так что - следите за новостями нашей "икспидиции" :)
К тому что там написано "Исходный VHDL-код свободно доступен в сети Интернет" с ходу не нашел. Может здесь какие-то ссылки разместить, для реализации СРР модели, в БКашках (модули расширения) она тоже применялась.
К тому что там написано "Исходный VHDL-код свободно доступен в сети Интернет" с ходу не нашел. Может здесь какие-то ссылки разместить, для реализации СРР модели, в БКашках (модули расширения) она тоже применялась.
У нас тут целая тема (http://zx-pk.ru/showthread.php?t=12086) есть. 8910/12 особо реверсить не рвусь, просто сделаю панорамы, пусть полежат. С существующими моделями 8910 вроде не совсем все гладко, как я понимаю. Дойдут руки до прикручивания 8910 к ПЛИС-реплике БК - увидим, есть ли реальные проблемы с ней и надо ли их будет решать раскопкой 8910. Кристалл там маленький, нормы относительно большие, структура простая, поэтому подъемно.
У нас тут целая тема есть.
Да, но она пустая и ссылки дохлые.
Дойдут руки до прикручивания 8910 к ПЛИС-реплике БК - увидим
так я и не тороплю :)
Да, но она пустая и ссылки дохлые.
В исходниках (https://code.google.com/p/speccy2010/source/checkout) Speccy2010 есть реализация YM2149.
В CPP-коде модели обнаружилась ошибка формирования значения reg.plir, что впрочем никак не влияло на работоспособность, наверное потому что, пока не возникало требований немаскируемых прерываний.
Исправленный вариант вот: 55208
Кроме всего прочего там проведено множество изменений, вроде как считающихся оптимизациями, но изменение метода вычислений wires свело всё на нет. Работать прога стала даже медленней.
А из-за того, что даже в релизном варианте со всеми оптимизациями под x64 частота модели не превышает 320кГц (без распараллеливания и только задействуя одно ядро ЦП 4ГГц, что крайне удивляет). И это при полностью отключенном всём выводе диагностики и на экран, то дальнейшая работа как-то утрачивает смысл. Эмуляция процессора в реальном времени не получается.
В CPP-коде модели обнаружилась ошибка формирования значения reg.plir, что впрочем никак не влияло на работоспособность
plir только на начальный старт влияет, это режим ожидания деактивации nACLO.
выводе диагностики и на экран, то дальнейшая работа как-то утрачивает смысл. Эмуляция процессора в реальном времени не получается.
Я микрокод потихоньку разбираю, скоро буду документировать. Может быть имеет смысл делать не эмуляцию всех схем как таковых, а именно микромашины? Пример - для АЛУ задана операция сложения, можно не вычитать все разряды поочередно, а просто выполнить сложение и выставить флаги. Аналогично для других операций. Тогда растактовка сохранится с отчностью до такта, возможно будет неточность на уровне полутактов, но сама суть независимо-работающих блоков и их растактовка сохранятся.
У нас тут целая тема (http://zx-pk.ru/showthread.php?t=12086) есть. 8910/12 особо реверсить не рвусь, просто сделаю панорамы, пусть полежат. С существующими моделями 8910 вроде не совсем все гладко, как я понимаю. Дойдут руки до прикручивания 8910 к ПЛИС-реплике БК - увидим, есть ли реальные проблемы с ней и надо ли их будет решать раскопкой 8910. Кристалл там маленький, нормы относительно большие, структура простая, поэтому подъемно.
Для точной эмуляции отечественнных машинок по любому нужно вскрывать AY/Ямаху, ВГ93, Z80. А для зарубежных еще и Юлу.
дальнейшая работа как-то утрачивает смысл. Эмуляция процессора в реальном времени не получается.Изначально было понятно, что V-модель имеет смысл главным образом как "калибровочная" для настройки потактово идентичной A-модели.
Можно запустить эмулятор ДВК с адаптером МПИ и убедиться, что единственным внешним отличием поведения A-модели от поведения V-модели является в 20 раз более высокая скорость эмуляции.
- - - Добавлено - - -
Может быть имеет смысл делать не эмуляцию всех схем как таковых, а именно микромашины?Научный смысл в этом точно есть - можно будет сравнить быстродействие потактово идентичных V-, M- и A- моделей одного и того же процессора.
- - - Добавлено - - -
Исправленный вариант: VM1CPPr006.rarВ 6-й версии V-модели есть ошибка, приводящая к отставанию на один такт фазы записи в циклах DATIO.
Вместо:
wire.dout_start = wire.dout_req_rc && wire.qbus_flag_rc && !reg.rply_ack[3];
Должно быть:
wire.dout_start = wire.dout_req_rc && wire.qbus_flag_rc && !reg.rply_ack[2];
.
Возникло сомнение в правильности фазы выдачи сигналов SEL1 и SEL2 в модели Qsync ( и её CPP-варианте ).
Async :
http://pic.pdp-11.ru/images/msim11.png
Qsync
http://pic.pdp-11.ru/images/msim12.png
Реальный 1801ВМ1А (http://zx-pk.ru/showthread.php?t=11557&p=591840&viewfull=1#post591840)
http://s003.radikal.ru/i201/1304/a3/dfea2b1f7420.png
.
Аналогично для начального изменения сигнала INIT :
Async
http://pic.pdp-11.ru/images/msim13.png
Qsync
http://pic.pdp-11.ru/images/msim14.png
- - - Добавлено - - -
Реальный 1801ВМ1АЕсли модель Async верна - в модели Qsync все сигналы должны изменяться точно так же, как и в модели Async.
При текущем алгоритме изменения SEL1 - при входе в HALT_TRAP он остаётся установленным при уже выданном на шину адресе 177676 :
################
HALT Trap to 160002 = HALT
################
; 000010 -> 177716:000000
-------------------------------------------------
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
-------------------------------------------------
1 177716 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 177716 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
1 160001 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0
1 160001 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
1 160011 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0
1 160011 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
; PSW :000344 -> 177676:177777
-------------------------------------------------
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
-------------------------------------------------
1 177676 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
1 177676 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000344 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000344 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000344 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000344 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Проверил ~SELx, там нет ошибки в Async, все соответствует схеме, видимо, сигнал через два регистра и дешифратор долго проходит.
По INIT фаза в моделях будет отличаться, так выполнен переход на синхронную модель, триггер был нужен. Сигнал длительный, практически никогда в работе не используется, поэтому разницу в такта в момент сброса не считаю принципиальной.
Проверил ~SELx, там нет ошибки в Async, все соответствует схеме, видимо, сигнал через два регистра и дешифратор долго проходит.В том и проблема модели Qsync, что адрес там выставляется без задержки ( как в модели Async ), а SEL1 изменяется с задержкой ( не как в модели Async )
По INIT фаза в моделях будет отличаться, так выполнен переход на синхронную модель, триггер был нужен. Сигнал длительный, практически никогда в работе не используется, поэтому разницу в такта в момент сброса не считаю принципиальной.Но в CPP-модели такая неадекватность явно лишняя - надо ( наверное ) особо подчеркнуть в комментариях к коду модели Qsync, каким должно быть правильное поведение сигнала INIT в данном случае.
В том и проблема модели Qsync, что адрес там выставляется без задержки ( как в модели Async ), а SEL1 изменяется с задержкой ( не как в модели Async )
Я второстепенные сигналы (BSY, INIT, SEL, входы прерываний) не очень точно переносил, там может быть фазовое отличие на полтакта/такт.
Но в CPP-модели такая неадекватность явно лишняя - надо ( наверное ) особо подчеркнуть в комментариях к коду модели Qsync, каким должно быть правильное поведение сигнала INIT в данном случае.
Я уже не помню как оно было, там относительно запутанный сдвиговый регистр с обратной связью, как я понимаю, оно сделано для того чтобы обеспечить минимальную длительность сигнала сброса периферии процессора, если сигнал приходит извне. Ну и сброс всего провессора по INIT если есть ACLO. Проще на реальном процессоре посмотреть как ведет себя INIT при старте.
Я второстепенные сигналы (BSY, INIT, SEL, входы прерываний) не очень точно переносилСигнал SEL должен выставляться синхронно с адресом, а сниматься синхронно с SYNC - иначе на шине возникает куча-мала.
Проще на реальном процессоре посмотреть как ведет себя INIT при старте.В текущей CPP-модели сигнал INIT ведёт себя не как в реальном процессоре, а как в модели Qsync - и это не радует.
- - - Добавлено - - -
Если в модели Qsync при вычислении pin_init_out заменить reset на reset_rc - сигнал INIT начинает изменяться синхронно с DCLO :
assign pin_init_out = init_out[0] | reset_rc;
Есть ли у такого решения какие-то недостатки ?
Сигнал SEL должен выставляться синхронно с адресом, а сниматься синхронно с SYNC - иначе на шине возникает куча-мала.
По схеме процессора - nSELx это защелка (латч) равенства состояния шины AD адресу 1777xx, фиксируется по nSYNC. То есть - пока nSYNC высокий, состояние nSEL изменяется согласно состоянию AD, когда nSYNC активируется (спад в низкий уровень, начало цикла) - nSEL замораживается. То есть, это не какой-то сакральный внутрений сигнал, который как-то влияет на исполнение кода или внутренности процессора, это просто тупой дешифратор адреса.
С установкой nSELx при высоком nSYNC в обоих моделях все в порядке, Async ставит строго согласно схемы, в реальном процессоре сигнал физически запаздывает (там на картинке видно что по срезу CLC на шину наконец вылазит достоверный адрес и почти сразу за его установлением активируется nSEL1). То есть - Async строго кошерный, но из-за своей идеальности дает немного отличную картинку от реального процессора. Qsync дешифрацию и защелкивание nSELx выполняет по фронту CLC. Это реальное отличие, да. Связано с тем, что у нас в схемотехнике не допускаются латчи, а на полтакта ранее по срезу CLC дешифрацию выполнить нельзя - потому что еще нет адреса и не разрешена работа шины. Но, главное, nSELx все равно активирован до среза nSYNC, то есть логика шины никак не нарушается. Со снятием непонятно что смущает, в любом случае на шине имеется минимум длительностью один такт высокого nSYNC, nSELx при этом в Async/Qsync вполне корректно снимается:
http://pic.pdp-11.ru/images/sel1mym.png
Итого - Async идеальный, строго по схеме, из-за этого сигнал nSEL выглядит как пришедший на полтакта раньше. Qsync задерживает nSEL на полтакта (не по схеме), но так же выглядит и реальный процессор. Принципиальных проблем для работы шины тут нет - взаимный порядок событий с nSYNC соблюден. Еще надо не забывать что nSYNC и AD - это комбинации внутренних и внешних сигналов, от внутреннего и внешнего агентов, процессор же может читаться-писаться внешним агентом, и тут уже фазу защелкивания во флип-флопе подкручивать бесполезно. Теоретически, для того чтобы ставить nSEL в Qsync на полтакта ранее, для внутреннего обращения можно было бы куда-то залезть глубого внутрь, вытащить адрес для дешифрации прямо с ALU, предсказать запись в регистр адреса areg, предсказать разрешение шины (если она опоздает то надо дешифровать позже, то есть уже с выхода регистра areg, а не с АЛУ - появится мультиплексор адреса, замечательно), и выполнять фиксацию дешифрации одновременно с этими всеми событиями. А для внешнего обращения это все вообще не работает, надо строить еще один параллельный дешифратор. В итоге получим достаточно сложную и нечитаемую схему. Для сохранения фазы многих внутренних управляющих сигналов это было оправдано и делалось (теперь иногда приходится вникать, потому что оно совсем уж дико выглядит местами), для второстепенного сигнала дешифратора, с незначительным непринципиальным отставанием фазы - нет.
Впрочем, для CPP-модели внести изменение проблем нет, можно защелки sel_xx
always @(posedge pin_clk_p)
begin
if (~pin_sync_in)
begin
sel_xx <= sel177x;
sel_00 <= sel177x & (pin_ad_in[3:1] == 3'b000);
sel_02 <= sel177x & (pin_ad_in[3:1] == 3'b001);
sel_04 <= sel177x & (pin_ad_in[3:1] == 3'b010);
sel_06 <= sel177x & (pin_ad_in[3:1] == 3'b011);
sel_10 <= sel177x & (pin_ad_in[3:1] == 3'b100);
sel_12 <= sel177x & (pin_ad_in[3:1] == 3'b101);
sel_14 <= sel177x & (pin_ad_in[3:1] == 3'b110);
sel_16 <= sel177x & (pin_ad_in[3:1] == 3'b111);
end
end
обрабатывать по обоим фронтам. Верилог такого не пропустит, а на C++ это запросто. Тогда и будет счастье, всем и даром :)
В текущей CPP-модели сигнал INIT ведёт себя не как в реальном процессоре, а как в модели Qsync - и это не радует.
Этот кусок инициализации при переносе в синхронную модель некоторое время не хотел работать и требовал отладки, поэтому немного отличается от реальной схемы. Qsync строится на совсем других принципах, отличных от Async и реального процессора, в ней не допускается применение латчей. Чисто теоретически в Qsync можно добиться точно такой же картинки как в Async, но в некоторых местах это требует неоправданного усложнения и изменения логики (становится менее понятной и читаемой). Поэтому незначительные фазовые отличия для редких событий на второстепенных сигналах, скорее всего, в Qsync останутся.
- - - Добавлено - - -
assign pin_init_out = init_out[0] | reset_rc;
Есть ли у такого решения какие-то недостатки ?
Чисто теоретические - сбросы пытаются не делать сложными комбинационными схемами. Выход станет зависеть напрямую от DCLO, несинхронизировано. pin_init_out снаружи соединен с pin_init_in, который используется для сброса таймера и детекторов спада прерывания, поэтому его желательно для реальной ПЛИС таки синхронизировать - разветвленные комбинационные схемы иногда дают ложные короткие пики и асинхронные сбросы их успевают поймать. По pin_init_in предполагается внешняя синхронизация при реальном использовании. Но если практически - то, думаю, можно так поступить, особенно для CPP модели (мне в Qsync стабильность и нежелание потенциальных проблем все-таки важнее, но ОК, тоже внесу коррекцию).
PS. DCLO в реальных схемах (БК/1201.01) по срезу CLC синхронизировано вне процессора, поэтому такой ситуации как на диаграмме не будет.
DCLO в реальных схемах (БК/1201.01) по срезу CLC синхронизировано вне процессораПотому в tbench.v более актуален такой код :
//
// CPU start
//
@ (negedge clk);
@ (negedge clk);
@ (negedge clk);
@ (negedge clk);
dclo = 1;
@ (negedge clk);
@ (negedge clk);
@ (negedge clk);
@ (negedge clk);
@ (negedge clk);
@ (negedge clk);
@ (negedge clk);
@ (negedge clk);
aclo = 1;
$display("Processor ACLO and DCLO deasserted");
Да, можно и так сделать, внесу изменения.
- - - Добавлено - - -
Кстати, начальная цель при переходе на Qsync была оставить только одну тактовую частоту и только одно событие по фронту тактовой частоты (это бы и ускорило CPP-модель, только eval_p остался бы). Две фазы достаточно сильно усложняют логику и забирают избыточные ресурсы, это я просто не осилил за один проход такое упрощение сделать. Поэтому все фазы соблюдались бы с точностью максимум до полутакта. Теперь есть модель Wsync, если и будет модификация до единой частоты, то уже на ней, Qsync в этом плане меняться не будет.
.
При следующей модификации модели Qsync - изменение сигналов SEL1 и SEL2 происходит аналогично модели Async :
always @(posedge pin_clk_n)
begin
sync_out <= qbus_win_h;
sync_ena <= sync_out_h;
if (~qbus_win_h)
begin
sel_14 <= sel177x & (pin_ad_in[3:1] == 3'b110);
sel_16 <= sel177x & (pin_ad_in[3:1] == 3'b111);
end
end
always @( posedge pin_clk_p or posedge sel177x )
begin
if (~pin_sync_in)
begin
sel_xx <= sel177x;
sel_00 <= sel177x & (pin_ad_in[3:1] == 3'b000);
sel_02 <= sel177x & (pin_ad_in[3:1] == 3'b001);
sel_04 <= sel177x & (pin_ad_in[3:1] == 3'b010);
sel_06 <= sel177x & (pin_ad_in[3:1] == 3'b011);
sel_10 <= sel177x & (pin_ad_in[3:1] == 3'b100);
sel_12 <= sel177x & (pin_ad_in[3:1] == 3'b101);
sel_14 <= sel177x & (pin_ad_in[3:1] == 3'b110);
sel_16 <= sel177x & (pin_ad_in[3:1] == 3'b111);
end
end
- - - Добавлено - - -
Кстати, начальная цель при переходе на Qsync была оставить только одну тактовую частоту и только одно событие по фронту тактовой частоты (это бы и ускорило CPP-модель, только eval_p остался бы).Именно так работает текущая A-модель ( все сигналы изменяются только по срезу CLC ). По иронии судьбы как раз сейчас я добавляю в A-модель полутактовую синхронность с V-моделью, потому и появились претензии к тем полутактам, где V-модель даёт маху.
.
always @( posedge pin_clk_p or posedge sel177x )
В симуляторе оно, возможно, и собирается, но Квартус синтезировать такое не сможет (update: попробовал - ага, ModelSim норм, а Quartus послал, даже до синтеза не дошел). В принципе, можно попытаться использовать асинхронный сброс (но с огромной комбинационной функцией с шины sel177x - это очень плохая идея), но деактивацию тогда сделать не получится. Также есть методы все-таки позволяющие реализовать аналог схемы always @(posedge clk1 or posedge clk2), но будет слегка громоздко и некрасиво, поэтому нафиг.
- - - Добавлено - - -
Там еще оказывается и по always @(posedge pin_clk_n) sel_14/sel_16 изменяются. Одна из первых вещей, когда обучают Верилогу - НЕ писать обработку одной и той же переменной в разных блоках. Часто можно нарваться на невозможность синтеза, неоднозначное поведение, не всегда очевиден порядок следования событий в списке чувствительности, или просто легкость внесения ошибок.
- - - Добавлено - - -
.
добавляю в A-модель полутактовую синхронность с V-моделью, потому и появились претензии к тем полутактам, где V-модель даёт маху.
Имелось ввиду что в Qsync-е полутактовая синхронность изначально не планировалась. Когда же стало понятно что одной фазой не обойтись, и все равно будут полутакты, то некоторое внимание было уделено основным сигналам qbus, чтобы ставились-снимались согласно "фазовому расписанию". SELx это все-таки не qbus-ные сигналы, поэтому их никто не смотрел и к фазовой точности не стремился. Да и сейчас считаю что усложнять промежуточный синтезируемый дизайн ради второстепенного сигнала не самый лучший вариант. Реальные платы если SELx используют - то только в связке с nDIN/nDOUT. Также нет смысла ставить внешнюю защелку на SELx, потому что она есть внутренняя, так что фаза относительно nSYNC тоже не особо важна для внешних схем.
Я пытаюсь начать проект БК0011М для MIST-board. Опыт программирования FPGA у меня небольшой. До этого тренировался на портировании ZX Spectrum 128 для достижения 100% совместимости по тактам с железом с ULA чипом. Поскольку цель достигнута, перехожу к проекту БК0011М. Видел одну реализацию, но там, ВМ1 эмулируется чисто функционально (как Т80, который популярен, но мало общего имеет с настоящим Z80), а не по тактам. В проекте Spectrum 128 я использовал прецизионную модель процессора A-Z80. Что мне нравится в той модели - то, что модуль имеет сигналы идентичные железному прототипу. По сути можно запихнуть в CPLD и вставить в сокет вместо Z80.
Для проекта БК0011М хочу взять модель из этого топика, поскольку видно что это самая точная модель ВМ1.
Но вот с сигналами - полный швах. Ничего подобного в реальном ВМ1 нет. Это сильно огорчает, поскольку возникает куча неизвестных и попутно некоторые непонимания решения.
В первую очередь о клоках:
1) Зачем столько клоков? Какой клок использовать для частоты 4мгц?
2) Зачем используются два противофазных клока? Разве нельзя обойтись одной полярностью и обрабатывать в коде posedge и negedge?
- - - Добавлено - - -
Ay8910 было бы классно получить от вас. В Spectrum128 использую одну из моделей, но по демонструшкам видно, что не всегда точно симулируется.
1) Зачем столько клоков? Какой клок использовать для частоты 4мгц?
2) Зачем используются два противофазных клока? Разве нельзя обойтись одной полярностью и обрабатывать в коде posedge и negedge?
Модель воссоздавалась по схеме реального процессора 1801ВМ1, а в нем события происходят как по фронту, так и по срезу тактовой частоты. Как чуть выше писалось, была предпринята попытка привести эту модель к единому событию по фронту, но, ввиду сложности модели, она пока не увенчалась успехом, поэтому имеются две частоты.
На промежуточном этапе был вариант с posedge и negedge одного тактового сигнала, но это накладывает требования на его форму - определенное соотношение длительностей высокого и низкого уровней (сейчас это должен быть меандр (равные полупериоды)), поэтому был добавлен еще один тактовый сигнал и вся модель переведена на posedge (есть парочка negedge, но они относятся к асинхронным сбросам). Сложность отрабатывающей логики между фазами неравнозначна, поэтому я еще игрался с фазами - двигал тактовые сигналы относительно друг друга для поднятия Fmax проекта, но в итоге удалось достичь запланированных 100МГц и на меандре. Форма записи с двумя тактовыми вполне позволяет использовать и один тактовый сигнал, при условии что он является меандром (тут надо аккуратно с настройками PLL), снаружи на модуль vm1_wb надо просто на вход vm_clk_n подать инвертированный сигнал.
Если будет применяться модель Wsync, то для работы на 4МГц следует использовать не тактовый сигнал, а вход vm_clk_ena (подать импульсы с периодом 4МГц, длительностью один такт vp_clk_p, синхронизированные с vm_clk_p), а также активировать vm_clk_slow, который будет притормаживать интерфейсный блок и запускать транзакции точно в моменты когда это сделал бы реальный процессор на 4МГц. Такой подход позволяет добиться точной потактовой симуляции и при этом сохранить быструю шину.
Но вот с сигналами - полный швах. Ничего подобного в реальном ВМ1 нет
В модели Qsync есть файл vm1.v, это обертка над синтезируемым ядром vm1_qbus, приводит его сигналы к реальному процессору (все, отличия только в тактировании). Там уже можно просто подать 4МГц на pin_clk_p/pin_clk_n. pin_ena в этой модели влияет только на ВЕ-таймер.
pin_ena в этой модели влияет только на ВЕ-таймерВ модели Async - pin_ena тоже влияет только на ВЕ-таймер, а в реальном 1801ВМ1 это так ?
В модели Async - pin_ena тоже влияет только на ВЕ-таймер, а в реальном 1801ВМ1 это так ?
В реальном процессоре нет такого вывода pin_ena. В модели Async/Qsync он добавлен чтобы можно было обеспечить разные частоты таймера и ядра. Например, ядро запустить на 100МГц, а на таймере оставить на 4МГц. В модели Wsync этот вывод стал называться более внятно vm_clk_tve.
Update: наверное в Async надо pin_ena удалить, чтобы поближе к процессору быть, все равно эту модель на ПЛИС запускать вряд ли будут, хотя надо бы попробовать, вдруг заработает, несмотря на 600+ предупреждений и матюков от Квартуса :))
наверное в Async надо pin_ena удалить, чтобы поближе к процессору бытьА в CPP-модели pin_ena вообще делать нечего.
То есть для эмуляции БК0011М достаточно использовать Qsync модель? Какие-то подводные камни с этой моделью есть? Просто в ридми написано так, что Wsync типа самая правильная. Собственно поэтому я в другие папки даже не заглядывал.
Правильно ли я понимаю, что для Qsync надо так?
vm1
(
pin_clk_p(clk4mhz),
pin_clk_n(~clk4mhz),
pin_ena(1'b1),
...
- - - Добавлено - - -
вдруг заработает, несмотря на 600+ предупреждений и матюков от Квартуса
У A-Z80 порядка 1600 предупреждений, однако работает :) Он тоже по маскам создавался, если верить автору.
То есть для эмуляции БК0011М достаточно использовать Qsync модель?
Зависит от того как будет построена "эмуляция БК". Если по типу SoC, то конечно надо брать Wsync и строить SoC на основе шины Wishbone.
Правильно ли я понимаю, что для Qsync надо так?
vm1
(
pin_clk_p(clk4mhz),
pin_clk_n(~clk4mhz),
pin_ena(1'b1),
Да.
У A-Z80 порядка 1600 предупреждений
Могу предположить, как не специалист, что цифра - это не показатель.
Показатель отсутствие "критически важных для эмуляции" предупреждений, наверное?
Показатель отсутствие "критически важных для эмуляции" предупреждений, наверное?
На модели Async значительная часть предупреждений звучит так:
Warning (10240): Verilog HDL Always Construct warning at vm1_qbus.v(924): inferring latch(es) for variable "plir", which holds its previous value in one or more paths through the always construct
Warning (13012): Latch vm1:cpu|vm1_qbus:core|plir has unsafe behavior
Warning (13013): Ports D and ENA on the latch are fed by the same signal vm1:cpu|vm1_qbus:core|au_alsl
Такие предупреждения часто приводят к тому что от сборки-к-сборке проект может спорадически не работать. То есть, вдруг повезло и работает, просто перекомпилил - и все, уже не работает :) Связано это с тем что трассировщик каждый раз может по-разному раскладывать ячейки, он стартует с некоторым начальным псевдослучайным значением. Можно использовать блокировку расположения ячеек LogicLock, но это не везде и не всегда помогает. В-общем, не надо писать кривые дизайны.
.
Обнаружилось довольно любопытное поведение CPP-модели в случае, когда задержка установки RPLY равна нулю ( RPLY устанавливается на первом же срезе CLC после установки DIN ), а задержка снятия RPLY равна 3 тактам ( RPLY снимается перед 4 срезом CLC после снятия DIN ).
В таком случае команды NOP и SWAB Rx ( далее NOP ) не просто увеличивают время выборки кода следующей команды на один такт, а делают это только после двух команд NOP подряд после сброса предвыборки или после первой же команды NOP, если после предыдущего сброса предвыборки уже выполнялись команды NOP.
На шине это выглядит так ( выделены такты, добавленные командой NOP ) :
000000 [000340] NOP
-------------------------------------------------
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
-------------------------------------------------
1 000000 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000002 [000340] NOP
-------------------------------------------------
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
-------------------------------------------------
1 000002 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000002 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000004 [000340] SWAB R0 ; R0 :133000
-------------------------------------------------
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
-------------------------------------------------
1 000004 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000004 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000300 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000300 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000300 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000300 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000300 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000006 [000350] NOP
-------------------------------------------------
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
-------------------------------------------------
1 000006 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000006 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000014 [000350] TST R0 ; R0 :000266
-------------------------------------------------
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
-------------------------------------------------
1 000014 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000014 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000016 [000340] NOP
-------------------------------------------------
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
-------------------------------------------------
1 000016 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000016 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000020 [000340] NOP
-------------------------------------------------
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
-------------------------------------------------
1 000020 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000020 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000042 [000340] TST (R0) ; 000266:000000
-------------------------------------------------
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
-------------------------------------------------
1 000042 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000042 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005710 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005710 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005710 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005710 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005710 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 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
-------------------------------------------------
1 000266 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000266 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000044 [000344] NOP
-------------------------------------------------
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
-------------------------------------------------
1 000044 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000044 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000046 [000344] NOP
-------------------------------------------------
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
-------------------------------------------------
1 000046 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000046 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000050 [000344] NOP
-------------------------------------------------
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
-------------------------------------------------
1 000050 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000050 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000240 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
У реального процессора тоже так или это глюк модели ?
пока еще изучаю и пытаюсь решить какую модель удобнее использовать.
Поэтому хочу уточнить по поводу Wsync:
vm1_wb (
.vm_clk_p(clock),
.vm_clk_n(~clock),
.vm_clk_ena(clock4Mhz), // период 4мгц и длительностью импульса равным периоду clock.
.vm_clk_tve(1),
.vm_clk_sp(1),
.vm_clk_slow(1),
...
Так? Какую оптимальную частоту clock посоветуете? Количество тактов и прочие времена будут считаться как у реального процессора относительно клока 4мгц?
- - - Добавлено - - -
Вопрос, который давно пытаюсь выяснить: За год существования вашей модели, так и не было создано эмулятора БК или другого компьютера на базе вашей модели? Просто система сигналов ВМ1 достаточно сложная чтобы вот так с нуля начать делать эмулятор. Хочется иметь какую-то начальную "рыбу".
.
Обнаружилось довольно любопытное поведение CPP-модели в случае, когда задержка установки RPLY равна нулю ( RPLY устанавливается на первом же срезе CLC после установки DIN ), а задержка снятия RPLY равна 3 тактам ( RPLY снимается перед 4 срезом CLC после снятия DIN ).
...
У реального процессора тоже так или это глюк модели ?
Быстро это проверить не получится, надо менять схему снятия RPLY, вводить туда счетчик и тестировать изменения.
- - - Добавлено - - -
.vm_clk_ena(clock4Mhz), // период 4мгц и длительностью импульса равным периоду clock.
Надо только учесть что это короткие импульсы, а не меандр.
Так? Какую оптимальную частоту clock посоветуете?
Максимальную, которую тянет примененная микросхема, я использую 100МГц.
Количество тактов и прочие времена будут считаться как у реального процессора относительно клока 4мгц?
Да.
Вопрос, который давно пытаюсь выяснить: За год существования вашей модели, так и не было создано эмулятора БК или другого компьютера на базе вашей модели? Просто система сигналов ВМ1 достаточно сложная чтобы вот так с нуля начать делать эмулятор. Хочется иметь какую-то начальную "рыбу".
Рабочая модель существует с конца августа. Я как раз сейчас занимаюсь разработкой БК на базе Wsync. Начальная "рыба" - проект для платы DE0 в каталоге модели Wsync. Собственно работоспособность этой модели проверена на реальной плате DE0.
Быстро это проверить не получится, надо менять схему снятия RPLY, вводить туда счетчик и тестировать изменения.В общем виде ситуация с NOP выглядит так:
if( nWord <= 0257 )
{ // NOP .. CCC
word nMask = nWord & 017;
PSW &= ~nMask;
Make_ALU_Delay();
if( !nRPLY_ON_Latency )
{
if( nRPLY_OFF_Latency < 3 ) { nOverrun = 1; }
else
if( nRPLY_OFF_Latency == 3 ) { nNOP_Delay++; }
if( nNOP_Delay > 1 )
{
nNOP_Delay = 1;
nOverrun = 1;
}
}
return; /* continue */
}
Поэтому даже при нулевой задержке установки и снятия RPLY - можно проверить, увеличивают ли команды NOP и SWAB Rx продолжительность выборки кода следующей команды на один такт.
В Qsync модели меня смущают сигналы DIN, DOUT, RPLY, SYNC - они же должны быть однонаправленными, а в моделе они inout.
Вот, например тут описаны как однонаправленные:
http://www.emuverse.ru/wiki/%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_% D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D1 %80%D0%BE%D0%B2_%D1%81%D0%B5%D1%80%D0%B8%D0%B8_180 1-1806
Вообще, есть ли где на просторах интернета полное описание ВМ1 с графиками обмена в разных режимах?
Надо только учесть что это короткие импульсы, а не меандр.
именно это я и имел ввиду.
В Qsync модели меня смущают сигналы DIN, DOUT, RPLY, SYNC - они же должны быть однонаправленными, а в моделе они inout.
Вот, например тут описаны как однонаправленные:
http://www.emuverse.ru/wiki/%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_% D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D1 %80%D0%BE%D0%B2_%D1%81%D0%B5%D1%80%D0%B8%D0%B8_180 1-1806
Ну что я могу сказать... В сети достаточно много не совсем достоверной информации по 1801ВМ1. Заводской документации на микросхему в открытом доступе нет, есть более-менее приличная информация в статье в МПСС и в некоторых справочниках типа Шахнова. Процессор ВМ1 имеет внутри недокументированный периферийный блок - таймер и три управляющих регистра. Поэтому внешняя шина является разделяемой - может работать как ведущее так и ведомое устройство МПИ. Некоторый внешний агент (например другой процессор), может выставить DMR, получить шину и читать-писать периферийные регистры процессора. При этом ножки DIN, DOUT и SYNC будут являться входами, а RPLY - выходом. То есть - эти выводы именно inout.
- - - Добавлено - - -
В общем виде ситуация с NOP выглядит так:
Поэтому даже при нулевой задержке установки и снятия RPLY - можно проверить, увеличивают ли команды NOP и SWAB Rx продолжительность выборки кода следующей команды на один такт.
Тестовая последовательность на ВМ1А работает в цикле с адреса 001612: [http://s009.radikal.ru/i308/1512/9a/d8907b1939f7t.jpg (http://s009.radikal.ru/i308/1512/9a/d8907b1939f7.png)]
Задержки связаны с тем как процессор запускает выборку следующей команды, иногда это происходит в середине исполнения текущей команды, иногда только после опроса прерываний, надо анализировать микрокод, пока ясная закономерность не выявлена.
пока ясная закономерность не выявленаЗакономерность приведённых на картинке таймингов станет вполне понятной, если учесть запрет предвыборки.
Запрет предвыборки происходит при любом переходе, при любом обращении к памяти в последнем операнде и в некоторых других случаях ( в исходнике A-модели MPI_1801VM1.cpp запрет предвыборки кодируется так: bPreFetchEnabled = false ).
Общий алгоритм вычисления добавочных тактов nALU_Delay после чтения кода команды ( в обсуждаемой ситуации нулевых задержек RPLY ) следующий:
1. Если предыдущая команда запретила предвыборку: nALU_Delay = 2
2. Если предыдущая команда не запретила предвыборку: nALU_Delay = 3 + nOverrun
3. Если предыдущая команда NOP или SWAB Rx - nOverrun = 1
Для интереса - если предыдущая команда MovB x, Rx - то nOverrun = 3, а для команды MovB Rx, Rx на ВМ1г: nOverrun = 5.
Поэтому, если на ВМ1г выполнить последовательность:
MOVB R0, R1
TST R0
TST R0
TST R0
То между первым циклом чтения и вторым пройдёт 2 такта, между вторым и третьим - 8 тактов, а между третьим и четвёртым - 3 такта.
На шине это будет выглядеть так:
;
000000 [000340] MOVB R0, R1 ; R0 : 177 -> R1
-------------------------------------------------
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
-------------------------------------------------
1 000000 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 110001 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 110001 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000002 [000340] TST R0 ; R0 :077577
-------------------------------------------------
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
-------------------------------------------------
1 000002 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000002 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000004 [000340] TST R0 ; R0 :077577
-------------------------------------------------
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
-------------------------------------------------
1 000004 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000004 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
000006 [000340] TST R0 ; R0 :077577
-------------------------------------------------
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
-------------------------------------------------
1 000006 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000006 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 005700 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 000000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Надо только учесть что это короткие импульсы, а не меандр.
Хочу уточнить: длительность импульса должна быть равна полу-периоду системного клока?
так?
reg vm_clk_ena = 1'b0;
reg old_clk = 1'b0;
always @(posedge sys_clk_p) begin
vm_clk_ena <= 1'b0;
old_clk <= clk_cpu;
if(!old_clk && clk_cpu) vm_clk_ena <=1'b1;
end
Хочу уточнить: длительность импульса должна быть равна полу-периоду системного клока?
Почему полупериоду? Периоду. Впрочем, код правильный. Можно чуть компактней записать:
reg vm_clk_ena;
reg old_clk;
always @(posedge sys_clk_p) begin
old_clk <= clk_cpu;
vm_clk_ena <= !old_clk & clk_cpu;
end
Избегать инициализаций в Верилоге - хорошая практика (одобренная ведущими собаководами в том числе OpenCores), не всегда синтезируется, а если и да, то отсутствие инициализации предоставляет синтезатору дополнительную степень свободы. Также блоки initial следует применять только в коде для симуляции.
Vslav,
а нельзя ли для комплекта ВП1-014 для Wishbone сделать?
Может, конечно, показаться, что всего лишь контролер клавиатуры, который можно накидать и без копирования оригинала, но это не совсем так. У него есть свои особенности и глюки. Помню, лет 20 назад, когда писал демонструшки и другой софт для БК, я обнаружил, что можно опрашивать боле одной кнопки заставив его счетчик "провернуться" далее уже нажатой кнопки. Вот только сейчас я не помню уже как я это делал. Но как минимум 2 одновременно нажатых кнопки можно было определить.
В общем, не всё так просто с этим ВП1-014 :) Было бы классно иметь точную модель (как и AY8910) для Wishbone. Про вариант QBUS я знаю.
CodeMaster
21.12.2015, 07:19
Начальная "рыба" - проект для платы DE0 в каталоге модели Wsync
А в DE1 оно поместится?
Vslav,
а в качестве клока wb_clk (для памяти и других устройств) использовать vm_clk_ena, я так понял?
Vslav,
а нельзя ли для комплекта ВП1-014 для Wishbone сделать?
Все можно :) ВП1-014 вскрыта и отреверсена и промоделирована, вот материалы (http://u.zeptobars.ru/yuot/1801/VP1/014.rar) по этой микросхеме. Ос
Vslav,
Про вариант QBUS я знаю.
Значит осталось только немного "доработать напильником". Я буду делать контроллер "типа 014" на Wishbоne с интерфейсом PS/2.
- - - Добавлено - - -
А в DE1 оно поместится?
Должно. Надеюсь не то что рыба, а и модель БК в Speccy2010 с его EP2C8 поместится.
- - - Добавлено - - -
Vslav,
а в качестве клока wb_clk (для памяти и других устройств) использовать vm_clk_ena, я так понял?
Смотря какая память, для SDRAM сильно маловато. Для обычной динамической - даже в БК диаграммы памяти вырабатывались от 6МГц,
Смотря какая память, для SDRAM сильно маловато. Для обычной динамической - даже в БК диаграммы памяти вырабатывались от 6МГц,
Про SDRAM речи не идет. Я пока использую внутреннюю память FPGA. У меня EP3C25 и можно уместить всю память (вместе со всеми ПЗУ) БК0010. Поэтому я начал именно с БК0010. Позже, когда основные узлы будут работать, я перейду на SDRAM и сделаю БК0011М.
Речь идет о ваших моделях памяти из "рыбы". Например mem_wb. Там же сигналы ответов формируются из входного клока, который не должен иметь больше тактов чем vm_clk_ena. Так?
Речь идет о ваших моделях памяти из "рыбы". Например mem_wb. Там же сигналы ответов формируются из входного клока, который не должен иметь больше тактов чем vm_clk_ena. Так?
На сегменте шины Wishbone тактовый сигнал должен быть общий для всех подключенных к сегменту модулей. Соответственно, wb_clk везде подается один и тот же - 100МГц. vm_clk_ena - этот сигнал используется для работы внутреннего замедлителя процессора, чтобы снаружи он выглядел так, как будто работает на низкой частоте. Транзакции на Wishbone будут происходить на полной частоте 100МГц, просто запускаться они будут редко, как будто их запускает 4МГц процессорное ядро. Еще надо будет добавить замедлитель, эмулирующий тормоза ВП1-037, пока не решено где его сделать - внутри или снаружи модуля vm1, но надо пытаться снаружи, тогда его можно будет использовать и с другими процессорами.
Тогда ерунда какая-то получается. Блок памяти, значит должен отвечать сигналом ack через 2 такта 100мгц после получения чтения?
Если в случае с SRAM это можно сделать, то с SDRAM это будет не реально.
Да и странно это, при vm_clk_ena в 4мгц, процессор будет "шагать" раз через 25 импульсов, а ответы от устройств будут приходить в каждом?
Что-то я совсем запутался..
- - - Добавлено - - -
Хорошо, зайду с другой стороны:
А что если просто sys_clk_p и sys_clk_n тактовать обычным меандром 4мгц и vm_clk_ena(1'b1), vm_clk_slow(1'b0)?
Тогда ерунда какая-то получается. Блок памяти, значит должен отвечать сигналом ack через 2 такта 100мгц после получения чтения? Если в случае с SRAM это можно сделать, то с SDRAM это будет не реально.
Почитайте спецификацию Wishbone. Модуль должен отвечать не через два такта, а по мере готовности данных.
Для SDRAM время обращения будет плавающим - от 7 до 30-40 тактов 100МГц, так как будут идти еще конкурирующие процессы - чтение памяти видеоконтроллером, рефреш, обращение другого агента (КЦГД или КСМ, например, но это не для БК уже).
Да и странно это, при vm_clk_ena в 4мгц, процессор будет "шагать" раз через 25 импульсов, а ответы от устройств будут приходить в каждом?
Что-то я совсем запутался..
Ядро от шины не зависит. Все модули в системе работают в едином клоковом домене - wb_clk. В том числе и процессорное ядро. Когда ядру требуются данные оно обращается к своему интерфейсному модулю. В vm1_wb этот модуль работает на Wishbone. В нем есть счетчик, он считает такты ядра wb_clk, если оно не ждет готовности данных. Когда приходит обращение на транзакцию - счетчик начинает считать в обратную сторону, тактами 4 МГц, и только когда досчитает до нуля - запускает фактическую транзакцию на шине. Ядро в это время стоит, ждет данные. Кстати, эту часть я еще не проверял, там код реализован только в первом приближении, уже видно что его надо усложнять чтобы достичь точной потактовой внешней совместимости с реальным CPU.
А что если просто sys_clk_p и sys_clk_n тактовать обычным меандром 4мгц и vm_clk_ena(1'b1), vm_clk_slow(1'b0)?
Можно и так, начните с простого варианта.
Еще надо будет добавить замедлитель, эмулирующий тормоза ВП1-037, пока не решено где его сделать
а расскажите если не сложно как он замедляет процессор. Делать полную модель 037, мне кажется, смысла нет.
так как будут идти еще конкурирующие процессы - чтение памяти видеоконтроллером
У меня видеоконтроллер точно не будет тормозить шину. Я использую уже проверенный способ - кэш во внутренней памяти.
что-то не получается.
после ACLO -> 0 на шине должен быть выставлен адрес 177716, а там почему-то 0.
скрин прилагается. 55293
в чем может быть проблема?
wire clk_cpu = clk_4mhz;
vm1_wb cpu
(
.vm_clk_p(clk_cpu),
.vm_clk_n(~clk_cpu),
.vm_clk_slow(1'b0),
.vm_clk_ena(1'b1),
.vm_clk_tve(1'b1),
.vm_clk_sp(1'b0),
.vm_pa(2'b00),
...
.vm_reg14(16'o000000),
.vm_reg16(16'o100000),
.vm_sel(vm_sel)
);
чёрт, не получается оригинальный размер картинки залить. Форум упорно уменьшает размер :(
http://imageshack.com/a/img910/319/pH6Uxm.png
Форум упорно уменьшает размер
Откажись от jpeg
Откажись от jpeg
У меня картинка в PNG.
- - - Добавлено - - -
Vslav,
Нашел в чем была проблема: файл инициализации vm1_reg.mif находится у меня не там, где прописано у вас. Самое странное, что Quartus никак не ругался на это. Компилировалось без ошибок. Хотя, я помню когда мои файлы инициализации ПЗУ указывали на неправильный путь, Quartus ругался ошибками и не хотел синтезировать. Может имеет смысл отказаться от такого варианта?
- - - Добавлено - - -
А вот и Hello World.
55301
вдохновляет :)
А вот и Hello World.
Извините за оффтоп, а что за плата видео захвата? через RGB?
balu_dark
21.12.2015, 22:56
Если кто забалабасит школьный БК ( модель не помню - но не первая модель с пленочной клавиатурой а с полноценной но обрезанной клавой и с Вильнюсским басиком - шла в составе школьных классов с мафонами электроника.) тому вечный и пламенный респект от меня прибудет.
Vamos,
AverMedia ExtremeCap U3 (HDMI)
У меня так: MIST Board -> PAL RGBS -> SCART to HDMI converter -> U3.
SCART to HDMI converter
А эта коробочка как называется?
- - - Добавлено - - -
А УКНЦ (МС-0511) случайно нет? :)
Если кто забалабасит школьный БК ( модель не помню - но не первая модель с пленочной клавиатурой а с полноценной но обрезанной клавой и с Вильнюсским басиком - шла в составе школьных классов с мафонами электроника.) тому вечный и пламенный респект от меня прибудет.
Уже "заколбасили". Закажите себе реплику БК-0011М у Voland'а на pk-fpga.ru, и будет вам счастье.
А эта коробочка как называется?
http://www.aliexpress.com/item/LKV362A-1080P-Scart-to-HDMI-Video-Converter-with-US-Plug-100-240V-for-DVD-STB-With/32567142892.html
УКНЦ у меня никогда не было.
Клаву прикрутил. Пока без 014.
О, на полдня отошел, а в теме нафлудили, может быть для БК отдельную заведем, я тоже там писать буду? А то тут свежие микрофоточки ожидаются :)
файл инициализации vm1_reg.mif находится у меня не там, где прописано у вас. Самое странное, что Quartus никак не ругался на это. Компилировалось без ошибок. Хотя, я помню когда мои файлы инициализации ПЗУ указывали на неправильный путь, Quartus ругался ошибками и не хотел синтезировать.
Может имеет смысл отказаться от такого варианта?
Он ругается, зависит от того какой уровень предупреждений выставлен. Скорее всего как Warning прошло. А предупреждения полезно просматривать, а не забивать на них :). Здесь нужна инициализация памяти константами, причем в модуле который вынесен в альтеровскую библиотеку, mif файл это стандартный способ инициализации, рекомендуемый производителем.
А вот и Hello World.
вдохновляет :)
Отлично, поздравляю!
- - - Добавлено - - -
Свежие фоточки:
YM2148 (388MB) (http://u.zeptobars.ru/yuot/214X/ym2148.jpg)
YM2148 (диффузия, 392MB) (http://u.zeptobars.ru/yuot/214X/ym2148_dif2.jpg)
AY-3-8910 (435MB) (http://u.zeptobars.ru/yuot/214X/ay-3-8910.jpg)
8910 интересная, сделана по дешевой классической технологии с металлическими затворами. Никаких поликремниевых самовыравнивающихся затворов и прочего хайтека. Отсюда возможна нестабильность параметров, кстати.
8910 интересная, сделана по дешевой классической технологии с металлическими затворами. Никаких поликремниевых самовыравнивающихся затворов и прочего хайтека. Отсюда возможна нестабильность параметров, кстати.
Какая может быть нестабильность у фактически чисто цифровой схемы? В чем она может выражаться?
Кстати, реверсить AY более предпочтительнее (во всяком случае не менее), чем Ямаху, т.к. AY - это классика звука.
Какая может быть нестабильность у фактически чисто цифровой схемы? В чем она может выражаться?
Нестабильность параметров - геометрия транзисторов "гуляет", получается большой разброс собственно в параметрах - время переключения, ток утечки, пороговое напряжение. На фотографии хорошо видно что окна тонкого оксида (подзатворный слой), диффузия и металл смещены друг относителmно друга, то есть фотошаблоны накладывались с небольшой погрешностью. А самовыравнивающийся затвор - это когда наносят сам затвор, а потом еще дополнительно выполняют ионную имплантацию (легирование) областей стока и истока вокруг затвора, при этом фотошаблоном служит сам затвор, получается как-бы самовыравнивание транзистора вокруг затвора, разброс параметров таких транзисторов становится существенно меньше.
Кстати, реверсить AY более предпочтительнее (во всяком случае не менее), чем Ямаху, т.к. AY - это классика звука.
Это да, 8910 - это General Instruments, первоисточник. Но посмотрите какая Ямаха открыта. Это не 2149 :)
Человек откопал относительно редкий YM2148 и попросил сделать снимки, и уже начал рисовать :)
Там крошечный кристалл, я его два раза в ванной потерял, прежде чем отшлифовал слои :)
Нестабильность параметров - геометрия транзисторов "гуляет", получается большой разброс собственно в параметрах - время переключения, ток утечки, пороговое напряжение.
Чем грозит такая нестабильность параметров транзисторов в данном чипе на практике?
Чем грозит такая нестабильность параметров транзисторов в данном чипе на практике?
Да всякое может быть, вероятность дефектов резко увеличивается, думаю:
- может не работать в указанном диапазоне тактовых частот
- может не работать в указанном диапазоне температур
- может не работать в указанном диапазоне питающих напряжений
- просто отказы каких-то фрагментов схем, иногда некритичные
- есть шанс что выйдет из строя банально после хранения
Voland жаловался недавно, у него партия 8910 совсем не хотит в БК на 6 МГц работать, да и часть просто тупо в БК-0011М не работает и на штатной частоте - просто коротковаты стробы записи.
Это да, 8910 - это General Instruments, первоисточник. Но посмотрите какая Ямаха открыта. Это не 2149 :)
Человек откопал относительно редкий YM2148 и попросил сделать снимки, и уже начал рисовать :)
Там крошечный кристалл, я его два раза в ванной потерял, прежде чем отшлифовал слои :)
Чем отличается 2149 от 2148?
- - - Добавлено - - -
- есть шанс что выйдет из строя банально после хранения
Хорошо, что так) А то я уж подумал, что звуком может отличаться один экземпляр от другого)
Чем отличается 2149 от 2148?
Первая цифра на единичку больше второй? :biggrin:
2148 - это контроллер MIDI-интерфейса, применялся в MSX-ах.
- - - Добавлено - - -
Хорошо, что так) А то я уж подумал, что звуком может отличаться один экземпляр от другого)
В какой-то степени тоже может быть, но думаю надо совсем хорошие уши иметь, чтобы на слух услышать :)
Vslav,
сколько времени уйдет до окончания перевода AY8910 в Verilog? Или она не в первой очереди?
Vslav,
сколько времени уйдет до окончания перевода AY8910 в Verilog? Или она не в первой очереди?
Далеко не в первой. Сейчас я SDRAM контроллер пишу, потом видеоконтроллер БК, потом запускаю двухпроцессорную схему, потом уже прикручиваю AY к БК, вот в рамках этого прикручивания, возможно, будет реверсится AY.
Должно. Надеюсь не то что рыба, а и модель БК в Speccy2010 с его EP2C8 поместится.
Было бы интересно БК на 2010-ом запустить...
Vslav,
Для модели процессора очень нужно иметь доступ к регистрам общего назначения и PC. Это нужно для перехвата обращения к некоторым адресам чтобы реализовать, например, обращение к диску. Большого смысла симулировать полную работу ВП1-128 нет. Даже регистры нет смысла симулировать, поскольку всегда было обращение через подпрограммы ПЗУ. Вот я и думаю, что возможно имеет смысл просто перехватывать начало функций ПЗУ и возвращать управление на конец с уже инжектированными данными.
- - - Добавлено - - -
потом запускаю двухпроцессорную схему,
Какой же БК вы создаете?
Какой же БК вы создаете?
Эээ... эт самое интересное, по описанию процессора можно сделать четырех ядерную БК:v2_dizzy_roll::v2_dizzy_roll::v2_dizzy_roll:: v2_dizzy_roll:
Vslav,
Большого смысла симулировать полную работу ВП1-128 нет.
Почему же? Я собираюсь именно полноценную 128 сделать, уже даже плату рисую (хочу челнок заказать) - переходник от DE0 к реальному дисководу.
Даже регистры нет смысла симулировать, поскольку всегда было обращение через подпрограммы ПЗУ.
Вот я и думаю, что возможно имеет смысл просто перехватывать начало функций ПЗУ и возвращать управление на конец с уже инжектированными данными.
Может быть тогда проще ПЗУ подкорректировать?
Vslav,
Какой же БК вы создаете?
Это не БК, это экспериментальный двухпроцессорный модуль, интересно как два процессора работать вместе будут. А от БК там только видеоподсистема, каждый процессор будет вывод в свою половинку осуществлять.
Почему же? Я собираюсь именно полноценную 128 сделать, уже даже плату рисую (хочу челнок заказать) - переходник от DE0 к реальному дисководу.
Не лучше ли эмулировать на SD карте чем возиться с реальными дискетами?
Может быть тогда проще ПЗУ подкорректировать?
Это запасной вариант, если у вас нет желания сделать доступ к манипуляциям регистров.
- - - Добавлено - - -
Vslav,
Как бы вы порекомендовали останавливать процессор (на время эмуляции дисковых запросов)? Блокировать тактовую частоту или есть лучше способ?
perestoronin
24.12.2015, 09:02
Про заказ челнока, наверное можно собрать желающих присоединиться и поддержать проект и заодно снизить издержки. Я бы взял некоторое количество челноков из расчета 4 платки.для подключения 128х к девбордам. Что ещё планируется разместить на челнок? Может заодно и платки для подключения к DE 1806ВМ2 пожелаете втиснуть на челнок? Тоже подписался бы и на такие 4 платки.
Не лучше ли эмулировать на SD карте чем возиться с реальными дискетами?
Это другой подход, я его тоже хочу сделать, но уже в виде драйвера под RT-11 - отображение устройства сразу в файл образа. Даже возможно кто-то такое уже и сделал, надо поискать.
Это запасной вариант, если у вас нет желания сделать доступ к манипуляциям регистров.
Так а что тут от меня требуется? Соберите ядро (Async/Wsync) с опцией VM1_CORE_REG_USES_RAM = 0, регистры превратятся просто в набор триггеров, считать их тогда вообще без вопросов, для записи уже добавите свой код.
Как бы вы порекомендовали останавливать процессор (на время эмуляции дисковых запросов)? Блокировать тактовую частоту или есть лучше способ?
Мне не очень нравится сам такой подход, он достаточно сложный, но то такое. Наверное да, можно попробовать останавливать частоту,
- - - Добавлено - - -
Про заказ челнока, наверное можно собрать желающих присоединиться и поддержать проект и заодно снизить издержки. Я бы взял некоторое количество челноков из расчета 4 платки.для подключения 128х к девбордам. Что ещё планируется разместить на челнок? Может заодно и платки для подключения к DE 1806ВМ2 пожелаете втиснуть на челнок? Тоже подписался бы и на такие 4 платки.
Мне надо достаточно быстро для рабочего проекта изготовить переходники от альтеровскогоо разъема HSMC на PCIe и SATA - с одной стороны HSMC, с другой SATA, PCIe 1x и 40-pin GPIO. А хоббийные проекты уже идут довеском, что успеваю - это адаптер дисковода (с одной стороны 40 пин в GPIO DE0, с другой - 34-pin FDD) и видео-АЦП по схеме от Svofski (можно будет поиграться с видеоадаптером ретро->VGA), может быть смогу их объединить даже в одном адаптере. Если кому интересно - излишки продам по себестоимости, но добавлять что-то еще времени сейчас нет, сроки горят, сорри. Ну не последний челнок, будут еще :)
Vslav,
vm1_reg_ff отвечает за регистры, так я понял? А что там собственно является регистрами R0-R7?
Я тут наткнулся на собственную защиту, написанную в 95 году :v2_lol:
Сейчас у меня перехват дисковых функций идет через специально написанные затычки в ПЗУ 326, но в нашем самарском контроллере HDD была специальная ПЗУ, проверка на которую и сделана в CSIDOS HDD edition ;)
Поэтому хочу сделать перехват вызовов дисковых функций без изменения их кода.
- - - Добавлено - - -
Как правильно сформировать IRQx сигнал? Не могу найти инфу о том сколько его нужно удерживать и когда снимать.
Или можно задействовать уже готовый ваш VIC и использовать VIRQ вместо, например, IRQ2?
vm1_reg_ff отвечает за регистры, так я понял? А что там собственно является регистрами R0-R7?
Модуль vm1_reg_ff находится там же в vm1_wb.v. Переменная с названием gpr (General Purpose Register) содержит 14 16-разрядных регистров. Нумерация переведена в "правильную" - R0-R7 соответствуют gpr[0]-gpr[7].
Как правильно сформировать IRQx сигнал? Не могу найти инфу о том сколько его нужно удерживать и когда снимать.
Не менее одного такта, там детектор фронта (или среза, если обертка применяется), дальше можно сигнал не удерживать. В "рыбе" на IRQ2 системный таймер подключен.
Или можно задействовать уже готовый ваш VIC и использовать VIRQ вместо, например, IRQ2?
Это по желанию, тут я за Вас решить никак не могу :)
Может не совсем в тему, но никак не могу найти (вспомнить уже не реально) какая частота была у AY8910 на БК. Судя по найденным схемам там делитель на 4 частоты 6мгц. Получается 1.5мгц, но на слух как-то низковато звучит. Сделал 1.71 (12МГц/7) - стало вроде нормально. Непонятно почему тогда на схемах 1.5мгц.
Было (есть) несколько схем: и 12/7 = 1,71 , и 6/4 = 1,5. Про разные схемы есть ветка на bk0010.org, там же описаны слуховые ощущения различных схем.
.
На фоне текущих знаний о работе процессора 1801ВМ1 - опубликованная ранее (http://zx-pk.ru/showthread.php?t=23978&p=778161&viewfull=1#post778161) осциллограмма работы реального процессора выглядит немного странно:
http://i057.radikal.ru/1501/34/f7bcb7c0d1b7.png
Вопросы вызывает дополнительная задержка снятия SYNC на один такт в зомби-цикле после команды MTPS R0.
.
Вопросы вызывает дополнительная задержка снятия SYNC на один такт в зомби-цикле после команды MTPS R0.
ЕМНИП, на части диаграм RPLY мониторился с разъема МПИ а не с процессора (у меня спаян переходник от БК к логическому анализатору, чтобы не втыкать полторы дюжины зондов). То есть, сигнал взят на входе триггера ТМ2, который защелкивает RPLY по фронту CLC и через резистор подается собственно на процессор. Поэтому реальный RPLY с ноги процессора снимался позже, и SYNC тоже снимается позже. Это также видно по DIN, который снимается на третий фронт CLC, а не на второй.
реальный RPLY с ноги процессора снимался позже, и SYNC тоже снимается позжеВопрос немного в другом - почему на приведённой осциллограмме снятие SYNC после снятия RPLY происходит в зомби-цикле на один такт позже, чем во всех остальных циклах чтения на той же самой осциллограмме.
Вопрос немного в другом - почему на приведённой осциллограмме снятие SYNC после снятия RPLY происходит в зомби-цикле на один такт позже, чем во всех остальных циклах чтения на той же самой осциллограмме.
Да, интересно.
На модели Async не подтверждается, пробовал разные режимы снятия/установки RPLY.
На реальном процессоре 1801ВМ1А тоже не подтверждается:
RPLY синхронизирован по спаду CLC [http://i081.radikal.ru/1512/19/f11326642bb1t.jpg (http://i081.radikal.ru/1512/19/f11326642bb1.png)]
RPLY синхронизирован по фронту CLC [http://s019.radikal.ru/i628/1512/88/2fa4b312f4cat.jpg (http://s019.radikal.ru/i628/1512/88/2fa4b312f4ca.png)]
Диаграмма снималась на БК-0010, вспомнилось что там схема RPLY не на ТМ2 сделана, там 155ИР1 стоит на синхронизацию RPLY, надо достать ту плату и восстановить реальную схему.
Посмотрел уравнения:
always @(*)
begin
if (~slk)
sync_out <= qbus_win_h;
if (slk)
qbus_win_h <= qbus_win;
end
always @(*)
begin
if (oe_clr)
qbus_win <= 1'b0;
else
if (dmr_req_l & qbus_gnt_l)
qbus_win <= 1'b1;
end
assign oe_clr = mj_res | (~rply_ack[0] & rply_ack[2] & ~qbus_flag);
assign qbus_done = (din_done & ~plrt[7]) | dout_done | mj_res;
assign din_done = din_out_l & rply_ack[3];
always @(*)
begin
if (qbus_done)
qbus_flag <= 1'b0;
else
if (sync_fedge)
qbus_flag <= 1'b1;
end
always @(*)
begin
if (~slk) rply_ack[0] <= (pin_rply_in & pin_bsy);
if ( slk) rply_ack[1] <= rply_ack[0];
if (~slk) rply_ack[2] <= rply_ack[1];
if ( slk) rply_ack[3] <= rply_ack[2];
end
Получается такое - DIN снимается по второму RPLY на фронте CLC, что наблюдается на диаграмме. Значит был активен din_done и qbus_done, qbus_flag очистился. oe_clr не активируется. А потом оно ждет снятия RPLY (комбинации ~rply_ack[0] & rply_ack[2]), тут видимо снятие RPLY на процессор не успело поступить через схему синхронизации, другого варианта для такой диаграммы я не вижу.
Упдата: RPLY на диаграмме формировался РЕ-мулятором (уже и не вспомнить с какой версией циклограмм), точный момент плавает на 10-30нс, так что вариабельность вполне возможна.
Диаграмма снималась на БК-0010До меня иногда доходили слухи о весьма различном поведении отдельных моделей ВМ1, поэтому (возможно) есть смысл найти ту БК-0010 и ещё разок протестировать.
Немножко археологии.
Был на днях в Бауманке, там один знакомый профессор показал мне одноплатную микроЭВМ на базе 1801ВЕ1. Говорит, что редкость большая, ни у кого такой не осталось скорее всего, т.к. даже музей Ангстрема пытался у него ее купить, но он не отдал, потому что у них докУментов нету. Говорит, что в начале 80-х на этой плате они делали распознавание речи.
Сфоткал:
http://s019.radikal.ru/i601/1512/36/99aad718bf90.jpg
Titus, Вот так, подарок! Я уж не думал вообще ВЕшку увидеть.:v2_thumb:
Titus, Вот так, подарок! Я уж не думал вообще ВЕшку увидеть.:v2_thumb:
А я ее даже трогал)))
А еще вот такие микросхемочки там видел:
http://i081.radikal.ru/1512/5f/d827b7944bcb.jpg
CodeMaster
30.12.2015, 10:00
Сфоткал:
А получше фоток нет, рассмотреть в деталях?
Говорит, что в начале 80-х на этой плате они делали распознавание речи.
Ещё одно подтверждение тому, что это было мегапопулярное направление тех лет.
Нет. Фоткал на телефон.
Не знаю на счет популярности, т.к. они речью занимались профессионально, делали речевое управление.
А я ее даже трогал))) Эмулятор будет? :)
потому что у них докУментов нету
Оказывается, и ТУ на ВЕшку где-то (?) есть.
CodeMaster
30.12.2015, 14:04
Эмулятор будет?
Прикинь, дилемма: у тебя есть последний рабочий экземпляр ВЕ1, если его декапить, то можно сделать 100% симулятор (и возможно узнать ещё много чего интересного), однако, не на чем будет его отладить и проверить, а если не декапить, то можно создать эмулятор и до бесконечности пытаться (на основе сравнения с рабочим процом) приблизить его поведение к 100% соответствия :-/
Эмулятор будет? :)
От меня нет, ибо ничего под этот проц нет.
- - - Добавлено - - -
Оказывается, и ТУ на ВЕшку где-то (?) есть.
Стоп! А вроде даже есть дока на ВЕ или на эту плату. Спрошу у профессора.
Прикинь, дилемма: у тебя есть последний рабочий экземпляр ВЕ1, если его декапить, то можно сделать 100% симулятор (и возможно узнать ещё много чего интересного), однако, не на чем будет его отладить и проверить, а если не декапить, то можно создать эмулятор и до бесконечности пытаться (на основе сравнения с рабочим процом) приблизить его поведение к 100% соответствия :-/ А оно нужно? Это же Электроника НЦ, совершенно самостоятельная архитектура, вроде-бы, наша. Программа была свернута из-за переориентации на PDP-11. Подозреваю, ни софта, ни нормальных тех. описаний не сохранилось, это, все-таки, не -11.
CodeMaster
30.12.2015, 16:00
А оно нужно?
Как минимум для истории - нужно понять насколько наши разработки были впереди планеты всей, а нужна ли 100% совместимость при отсутствии софта - вопрос философский.
Это же Электроника НЦ
Ладно, заменим для универсальности "последний рабочий экземпляр ВЕ1" на "последний рабочий экземпляр некого процессора для которого существует софт"
Спрошу у профессора.
Ага, спроси! Спроси ещё распиновку На ВЕ1. Насколько я знаю ВЕ так-же с шиной МПИ сделана как и ВМ1. Система команд возможно как и в НЦ-31.
Система команд НЦ-31 (http://www.nc-31.narod.ru/sk.htm)
Ура! Описание есть!
За него огромное спасибо преподавателю Бауманки Ю.Н.Жигулевцеву!
Микро-ЭВМ "Электроника НЦ-8001" - Техническое описание (http://rghost.ru/8StKhWbvh)
CodeMaster
30.12.2015, 17:17
Ура! Описание есть!
Ещё бы сделать качественные фото с обоих сторон (кстати, не знаю одному мне или нет, плата очень напомнила плату БК)
- - - Добавлено - - -
ни нормальных тех. описаний не сохранилось, это, все-таки, не -11
Вот смотрю сейчас тех. описание одним глазом, очень много параллелей с PDP-11. Да это не клон, но как минимум "по мотивам".
Ещё бы сделать качественные фото с обоих сторон
Хорошо бы, но как было сделано (а, подозреваю, что сканам уже лет 8 судя по дате), так и есть) Это те сканы, которые просил Ангстрем вместе с самой платой, но Ю.Н. Жигулевцев сделал им только сканы, а плату оставил себе на память.
CodeMaster
30.12.2015, 18:48
Хорошо бы, но как было сделано (а, подозреваю, что сканам уже лет 8 судя по дате), так и есть)
Фото платы.
Фото платы.
А что с ним не так? Все вполне видно)
CodeMaster
30.12.2015, 20:02
А что с ним не так? Все вполне видно)
В принципе да, на другом компе фотка маленького размера показывалась. Единственно, не понял, что за рыжие многоножки.
(кстати, не знаю одному мне или нет, плата очень напомнила плату БК)
Посмотрел в качестве получше - не особо похоже.
Хорошо бы, но как было сделано
Схемы не видно (фрагменты только).
Единственно, не понял, что за рыжие многоножки.
Резисторные сборки.
...
CodeMaster, По прямой ссылке можно увидеть более крупное фото- 3257*1894 (http://s019.radikal.ru/i601/1512/36/99aad718bf90.jpg)
О, а там в документации описание таймера есть :)
Биты в регистре ошибок 7,3,2 так и не описаны, увы
Регистр управления и адресного прерывания совпадают.
CodeMaster
30.12.2015, 21:45
CodeMaster, По прямой ссылке можно увидеть более крупное фото- 3257*1894
О, супер, это и было надо, просто я думал оно некликабельное.
Прикольно, что в одной номерной серии 2 разных процессорных серий.
Секретные технологии запутывания врага? ;)
Прикольно, что в одной номерной серии 2 разных процессорных серий.
Секретные технологии запутывания врага? ;) Мне кажется, что 1801 задумывалась именно для Э-НЦ, но, только успели сделать первый процессор, как поступила команда: "НЦ свернуть, приступить к PDP-11".
Мне кажется, что 1801 задумывалась именно для Э-НЦ, но, только успели сделать первый процессор, как поступила команда: "НЦ свернуть, приступить к PDP-11".
[Offtop On] Народ, давайте не будем создавать легенды на пустом месте! На наши исторические вопросы г-н Отрохов уже успел ответить на форуме ixbt, и, по-моему, все точки над i расставлены. Инициатива переделки ВЕ1 в ВМ1 исходила не от большого начальства, а как раз снизу. Сам Отрохов и говорит, что это было его решение, которое он долго пробивал и в конце концов добился, чтобы ВЕ1 переделали в совместимый с PDP-11 процессор. Напомню, что ВЕ1 - это не процессор, а контроллер. Когда его сделали, то обнаружили, что кроме как в ЧПУ серии НЦ его ставить никто не собирается. Просто нет заказчиков. В то же время на горизонте вырисовывались универсальные ЭВМ, встраиваемые системы, АСУ и.т.п. Во-первых, у НИИ ТТ просто не было ресурсов разрабатывать инструментарий и ОС. Вы посмотрите в ТО, там упоминается кросс-система для ЕС ЭВМ и БЭСМ! В то же время воронежцы уже клепали Э-60 и стали головным предприятием МЭП. Надо было догонять и перегонять. Э-60 уже стала вытеснять НЦ с рынка управляющих машин, где, по-хорошему, и должны были использовать ВЕ1. И не забываем про периферию, модули, разработанные для Э-60. В том числе и буржуйские станки, платы расширения и.т.п. Не зря, ВЕ1 и сделали с МПИ изначально. [Offtop Off]
Дорогие археологи, а не хотите ли вы выложить свои изыскания на github? Совсем не хочется парсить весь этот длинный форум в поисках ответов на вопросы, когда все это можно сложить в одном месте и открыть доступ к последнему для всех.
Народ, давайте не будем создавать легенды на пустом месте! На наши исторические вопросы г-н Отрохов уже успел ответить на форуме ixbtМы ixbt не читаем, там сильно много не по нашей теме. Это же, в основном, писюшный форум...
Тем не менее, я почти не ошибся, 1801 создавалась именно под НЦ и лишь потом была переориентирована на Э-60.
Дорогие археологи, а не хотите ли вы выложить свои изыскания на github? Совсем не хочется парсить весь этот длинный форум в поисках ответов на вопросы, когда все это можно сложить в одном месте и открыть доступ к последнему для всех. Может наоборот, пригласим сюда г-на Отрохова, может еще расскажет что-нибудь, а, может быть, он еще и сохранил что-нибудь из тех времен, да поделится с общественностью?
Мы ixbt не читаем, там сильно много не по нашей теме. Это же, в основном, писюшный форум...
Тем не менее, я почти не ошибся, 1801 создавалась именно под НЦ и лишь потом была переориентирована на Э-60.
Может наоборот, пригласим сюда г-на Отрохова, может еще расскажет что-нибудь, а, может быть, он еще и сохранил что-нибудь из тех времен, да поделится с общественностью?
Ну это вы сами спрашивайте Юрия Леонидовича. Его много куда приглашали. В этой ветке несколько людей участвовали в дискуссии с ним. Про документы тоже интересовались. Многих людей, работавших над 1801, к сожалению, уже нет на этом свете, а сам Ангстрем безобразно относился к архивам документов. В любом случае, это все лирика. Эта ветка немного про другое.
Дорогие археологи, а не хотите ли вы выложить свои изыскания на github? Совсем не хочется парсить весь этот длинный форум в поисках ответов на вопросы, когда все это можно сложить в одном месте и открыть доступ к последнему для всех.
Все ссылки на результаты "изысканий" есть в первом посте этой темы, он регулярно обновляется. Если чего там, по Вашему мнению, не хватает, пишите - добавлю. По ВМ1 можно и на гитхаб, но пока есть намерения сделать проект на OpenCores.
Все ссылки на результаты "изысканий" есть в первом посте этой темы, он регулярно обновляется. Если чего там, по Вашему мнению, не хватает, пишите - добавлю. По ВМ1 можно и на гитхаб, но пока есть намерения сделать проект на OpenCores.
Первую страницу видел. Спасибо, что поддерживаете все в порядке. Но я говорил про то, что туда не попало. Тут уже 99 страниц, и среди них где-то разговор про то, как запускать модель в Modelsim, какая модель что делает и.т.п. Все это в вопросах-ответах раскидано по всей теме. Opencores - это хорошо, но я не понял, а там есть некое подобие version control и wiki? Или все сваливается на странице проекта автором без всякой системы?
а там есть некое подобие version control
SVN есть
Vslav,
Не могли бы рассказать о том как ВП1-037 тормозит процессор? Я бы не хотел вставлять всю модель в эмулятор, но хочется сделать торможение хотя бы в неком приближении.
Нечто подобное я добавлял для ZX Spectrum - там вышло всего несколько строчек кода.
Не могли бы рассказать о том как ВП1-037 тормозит процессор?
Сам еще во всех подробностях не разобрался. Если без подробностей - то 037 работает циклами по 4 такта частоты 6МГц. Каждый второй цикл отдается на чтение видеопамяти. Вроде бы даже в то время когда изображение не выводится (гашение и синхронизация). Бит короткого экрана просто выводит нулевые данные в нижних 3/4 экрана, на сканирование памяти не влияет. Оставшийся каждый второй 4-тактный цикл может быть отдан процессору, если он успел выставить запрос. Вопрос, к какому моменту уже должен быть запрос и когда принимается решение выполнить цикл доступа для процессора - пока открытый.
- - - Добавлено - - -
Opencores - это хорошо, но я не понял, а там есть некое подобие version control и wiki? Или все сваливается на странице проекта автором без всякой системы?
Да, там есть SVN (я к нему привыкший по работе), и некоторая структура страничек тоже присутствует. В архиве проекта есть файлик readme.txt, там краткое описание моделей, а также история проекта. Про запуск моделей в ModelSim добавлю в него информацию.
Vslav,
судя по демонструшкам, где используется задержка при выводе на экран, реальный процессор почти в два раза медленнее работает чем получается в моем эмуляторе, где пока он не тормозится.
- - - Добавлено - - -
Сам еще во всех подробностях не разобрался.
означает ли это что Verilog модель не до конца протестирована?
означает ли это что Verilog модель не до конца протестирована?
Процессорная модель - до конца, по краней мере, по ней открытых вопросов нет. Модель 037 - просто промежуточный итог для моделирования. Схема там простая и достоверная, надо просто осмыслить как оно работает.
За него огромное спасибо преподавателю Бауманки Ю.Н.Жигулевцеву!
Оказывается есть и упоминание в журнале на тему распознавания речи.
Журнал- читать стр.78-82 (http://speechtechnology.ru/files/1-2008.pdf)
.
В новом релизе адаптера МПИ (http://zx-pk.ru/showthread.php?t=25252&page=3&p=849241#post849241) абстрактная модель поведения процессоров 1810ВМ1А и 1801ВМ1Г ( объект MPI_1801VM1 ) совпадает с поведением последней CPP-версии модели Qsync ( объект MPI_1801VM1_Verilog ) с точностью до половины такта.
Оказывается есть и упоминание в журнале на тему распознавания речи.
Журнал- читать стр.78-82 (http://speechtechnology.ru/files/1-2008.pdf)
Это наш журнал, мы его выпускали, когда я работал с этими товарищами в распознавании речи)
Вернее, они выпускали журнал, а я с ними работал, в сам журнал ничего не писал.
Сам еще во всех подробностях не разобрался. Вопрос, к какому моменту уже должен быть запрос и когда принимается решение выполнить цикл доступа для процессора - пока открытый.А что мешает просто добавить исходник модели ВП1-037 в реализацию ( например ) модели памяти проекта Qsync ?
Titus, Спасибо за информацию. И всё таки 2 вопроса остаются открытыми.
1)Распиновка 1801ВЕ1, лучше конечно полное описание.
2)Схема в описании Электроника НЦ-8001 не отсканировалась (видны только фрагменты)
Если пересканируете схему, вопрос о распиновки ВЕ1 отпадет.
Titus, Спасибо за информацию. И всё таки 2 вопроса остаются открытыми.
1)Распиновка 1801ВЕ1, лучше конечно полное описание.
2)Схема в описании Электроника НЦ-8001 не отсканировалась (видны только фрагменты)
Если пересканируете схему, вопрос о распиновки ВЕ1 отпадет.
Если буду в Бауманке, то сфоткаю на телефон схему, если она там есть. Но это не в ближайшие времена, возможно.
А что мешает просто добавить исходник модели ВП1-037 в реализацию ( например ) модели памяти проекта Qsync ?
Модели Xsync служат всего лишь для тестирования процессорного модуля, это тестбенчи и отнюдь не полноценные проекты. Добавление модели 037 влечет за собой добавление модели динамической памяти, дополнительных регистров и прочего, что совершенно излишне для отладки собственно процессора. В проекте 037 есть свой тестбенч для моделирования, в нем можно задать нужные обращения, не связываясь с программой процессора и прочим. Я совершенно не возражаю (и даже приветствую), если кто-то сделает свой проект для совместного моделирования ВМ1 и 037. Мне в данный момент интереснее закончить контроллер SDRAM и универсальный (с хорошим заделом на ДВК с КЦГД) настраиваемый видеоконтроллер на его базе, чтобы получить первую версию реплики БК. Как будет готово - можно будет уточнить подробности 037 и задержки остальных компонентов в БК для наилучшей имитации. Также уже можно будет погонять демки и тесты потактового исполнения команд, чтобы сравнить с реальной БК - это такое относительно невремязатратное тестирование, сразу даст понять насколько наша реплика близко подошла к оригиналу.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot