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

Вид для печати

Показывать 40 сообщений этой темы на одной странице

14.12.2015, 23:27
Vslav

Цитата:

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

После запуска 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
14.12.2015, 23:37
Patron

Цитата:

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

насчет 500ns непонятно, там все значения в ns указываются, и они единичные, странно что оно дает 500ns поставить и симулируется.

Эта установка ModelSim задаёт, через сколько симулированного времени будет прервана симуляция, запущенная командой run без аргументов ( или соответствующей кнопкой GUI ). Когда там 100 ps - одно нажатие на кнопку run отрабатывает симуляцию меньше одного такта CLC, если изменить на 500 ns - каждый run отрабатывает симуляцию достаточного количества тактов для выборки и исполнения симулируемым процессором пары команд.
14.12.2015, 23:41
Vslav

Цитата:

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

Эта установка ModelSim задаёт, через сколько симулированного времени будет прервана симуляция, запущенная командой run без аргументов

Для этого в ModelSim.ini есть параметр

Код:

; Default run length RunLength = 100

timescale на него влиять не должен

Update: достаточно прописать: RunLength = 500ns и запускается с 500 нс. Это к проекту не относится, где-то .ini сбойнул (или его просто в новом каталоге не было локального), может быть надо было установить 500нс и выйти-зайти в ModelSim.
Update2: можно в run.do добавить set RunLength 500ns и будет совсем хорошо :)
15.12.2015, 00:02
Patron

Цитата:

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

Для этого в ModelSim.ini есть параметр

Дело в том, что изначально файл ModelSim.ini в каталоге sim отсутствует, но после запуска оттуда run.do - файл ModelSim.ini там создаётся со значением RunLength по-умолчанию. Если же изначально иметь в каталоге sim собственный вариант ModelSim.ini с более логичными настройками - удобство пользователей только возрастёт.
15.12.2015, 13:58
Patron

Цитата:

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

Нет, просто там была частота высокая (5.0МГц), задержки в кучу смешались. При более низкой частоте видно что данные на шине появляются при высоком CLC (после фронта), а nDOUT активируется при низком CLC (после спада).

Важно знать, остаётся ли неизменным у реального процессора 1801ВМ1 количество тактов в циклах DATI, DATO, DATIO, DATOB, DATIOB на частотах от 2 до 6 МГц - ведь иначе будет невозможна точная потактовая эмуляция работы реального процессора на реальных частотах.

Для начала можно было бы сравнить продолжительность в тактах выполнения теста команд реальным процессором 1801ВМ1 на частотах 2 и 6 МГц.
15.12.2015, 14:42
Vslav

Цитата:

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

Важно знать, остаётся ли неизменным у реального процессора 1801ВМ1 количество тактов в циклах DATI, DATO, DATIO, DATOB, DATIOB на частотах от 2 до 6 МГц

Количество тактов варьируется лишь моментом ответа RPLY, а в остальном машина состояний никак не может зависеть от частоты, у нее же всего один опорный клок. То есть - в тактах длительность циклов поменяться с частотой не может.
15.12.2015, 15:58
Patron

Цитата:

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

Количество тактов варьируется лишь моментом ответа RPLY, а в остальном машина состояний никак не может зависеть от частоты.

Т.е. съехать на следующий полутакт могут только изменения сигналов AD ( в фазе адреса - для всех циклов, в фазе данных - для циклов записи ), а изменения управляющих сигналов происходят в пределах "своего" полутакта во всём диапазоне рабочих частот.

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

На осциллограммах видно, что фронты сигналов отстают от фронта CLC на неизменное количество наносекунд, определяемое переходными процессами в триггерах. Когда продолжительность полутакта становится меньше времени отставания сигнала - изменение сигнала происходит на следующем полутакте.
15.12.2015, 16:20
Vslav

Цитата:

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

Т.е. съехать на следующий полутакт могут только изменения сигналов 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, породившее изменение сигналов.

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

Цитата:

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

На осциллограммах видно, что фронты сигналов отстают от фронта CLC на неизменное количество наносекунд, определяемое переходными процессами в триггерах. Когда продолжительность полутакта становится меньше времени отставания сигнала - изменение сигнала происходит на следующем полутакте.

Да, именно так. Это как свет от звезды долго идет, там уже давно сферу Дайсона построили, а нам она все еще светит :)
15.12.2015, 16:39
Patron

Цитата:

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

nDOUT активируется по срезу CLC в течение примерно 40нс, если бы можно было разогнать ВМ1 до 12МГц - то nDOUT на реальном процессоре "съехал" бы в следующий полутакт.

И тогда, при неизменной задержке RPLY в наносекундах - сигнал RPLY придёт уже на другом такте от начала команды, нежели на более низкой частоте. По идее - это должно изменить растактовку.

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

Цитата:

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

Я сравнивал с медленным процессором в БК-0010 на 3МГц, чтобы физические задержки были некритичными и можно было четко идентифицировать событие фронта или среза CLC, породившее изменение сигналов.

А если установить неизменное выравнивание RPLY на ближайший фронт CLC и прогнать тест команд на реальном 1801ВМ1 на 2 МГц и на максимальной частоте конкретного процессора - будет ли затраченное количество тактов одинаковым ?
16.12.2015, 01:01
Vslav

Цитата:

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

И тогда, при неизменной задержке RPLY в наносекундах - сигнал RPLY придёт уже на другом такте от начала команды, нежели на более низкой частоте. По идее - это должно изменить растактовку.

RPLY должен прийти за сколько-то нс до фронта CLC, важно успеет зафиксироваться по фронту процессором или нет, остальные моменты ничего не значат. Конечно, если по-другому прийдет RPLY то изменится растактовка системы в целом. Такая картина наблюдалась на модуле с ВМ3, когда переписывалась отработка установки/снятия RPLY, на 4МГц/5МГц/6МГц растактовка цикла чтения отличалась, но это обусловленно именно задержками внешней системы, а не самого процессора, как только внешняя схема RPLY стала достаточно быстрой, процессор заработал одинаково на всех частотах.

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

Цитата:

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

А если установить неизменное выравнивание 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

Вроде один слой металла и один слой поликремния, но транзисторов пока не вижу. Кстати, площадок под выводы на кристалле 40 штук, это значит что 8910 и 8912 - одна и та же микросхема, просто упакована в разные корпуса.

Update: посовещались с BarsMonster и пришли к выводу что поликремния тут нет. О как - металлические затворы без самосовмещения. Дешевая технлогия пещерных времен :)

Показывать 40 сообщений этой темы на одной странице