nedoPC.org

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

В бумажках я не путаюсь (пока?), проблема в другом.
- Придумываем архитектуру процессора.
- Рисуем схему на логических элементах. Карандашом на бумаге. Большой блок перерисовать или переместить - сложно.
- Не знаю было ли моделирование, но ошибки надо искать и исправлять. Желательно не перерисовывая всю схему.
- Рисуем кристалл. Не карандашом на бумаге, но близко к этому. Опять же большой кусок при нехватке места не переместишь, поэтому, например, один логический элемент может оказаться далеко от основной части схемы.
- Рисуют несколько человек, у каждого свой стиль перевода логических элементов в транзисторы.
- Внезапно обнаруживаются ошибки (логические, электрические), поэтому на кристалле есть и проводники в никуда, и неподключенные переходные отверстия, и перемычки... Есть даже задержка в виде нескольких последовательных инверторов, потом это складывается с исходным сигналом и это, если я правильно понял, управление precharge шины.
То есть процессор пропущен через хороший такой обфускатор и обратный процесс сильно затруднён. Разобрать схему целиком скорее всего не получится, да и не было у меня такой цели, но в процессе хотелось бы проверять работу уже разобранного. Моделировать на Паскале? Verilog + симулятор? ПЛИС? Может как-то по-другому? От советов не откажусь

Ну - тебе виднее... как оно тебе удобнее...


Про "обфускатор" сильно сомневаюсь - где-то читал от самих авторов- то ли 10...
то ли 16 подлянок вделаны были в уже готовую схему, когда они чухнУли, что схему
могут передрать...

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

Паскаль лучше бы не трогать, а вот "Verilog + симулятор? ПЛИС..." - посмотрим, что наши
специалисты скажут!

А, так это не баги, это фичи?
А вдруг?
Чем вам Паскаль не угодил?

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

Насчет пакета моделирования: ну мне привычно на уровне вентилей моделировать,
а как тебе привычнее и удобнее - мне предположить трудно, поскольку от
Паскаля до Verilog - диапазон довольно широкий...

Да я ж сам ещё не знаю как мне это удобнее, поэтому и диапазон такой.

С учетом того, что:

Мне кажется, что на логических вентилях тебе это будет неудобно, ты же транзисторы
видишь и срисовываешь...

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

К примеру - как вот здесь:



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

А на вентилях тут бы мультиплексоры понадобились... или с z-состоянием элементы.

Так что, как мне кажется, тебе нужен пакет, куда такую схемотехнику можно
перенести напрямую.

Хардварный, хардварный Почти разобрал счётчики тактов и циклов, выполнены на сдвиговых регистрах. 5 T-циклов, 5 M-циклов. А вот сброс-перенос, что на каком такте для какой команды - всё на комбинационной логике

Обнародуй промежуточные результаты. Интересно же.

Да он же выкладывал тут ссылки... но бумаги с фотографий читаются с трудом...

Почему я и намекнул, что может пора к электронке переходить...

Счётчики тактов и циклов, фотография с бумаги: http://yadi.sk/d/Sr-tAUhq7uKGG

Команда (машинная инструкция) делится на М-циклы, каждый М-цикл делится на Т-такты.

Вверху слева - счётчик на 5 тактов. Про 6-й такт пока ничего не скажу, но он зачем-то есть. Сюда же на 3-й разряд заведён сигнал wait.

Внизу слева - схема определяющая окончание М-цикла.
- Для команд 155 (выход декодера команд) окончание М-цикла происходит в момент М1Т4
- На Т3 М-цикл заканчивается если это М2 (то есть все циклы М2 длиной 3 такта), если это М3 для команд <...>, если это М4 для команд <...>, если это М5 для команд #115 (выход декодера команд).
- На Т4 М-цикл заканчивается если это М3 или М4 (для определённых команд).
- На Т5 цикл заканчивается только если это М5 (также только для определённых команд).
- Если ни одно условие не выполнилось - М-цикл выполняется за 6 тактов.

Сигнал #609 сбрасывает счётчик тактов и увеличивает счётчик М-циклов (вверху справа).

Внизу справа схема сброса счётчика М-циклов, сигнал 627 формируется для одних команд на М1, для других на М2, и т.д. При М5 сигнал сброса формируется всегда. Сброс, как и инкремент, происходит по сигналу #609.
Ещё есть странный сигнал 626, который с цикла М1 или М2 переводит счётчик сразу на М4. Возможно это команды вида 00xxx110, 11xxx110 и подобные, точнее в декодере команд буду разбираться потом.

Переход на М4 по сигналу 626 это пропуск вычисления IX/IY+d.

Последовательность М-циклов для команд без префиксов:

После перерыва продолжаю разбирать z80.

Обработка префиксов (предварительное описание).

Декодер команд (это у которого сотня выходов) состоит из нескольких частей:
- команды без префиксов;
- команды с префиксом ED (тут много дублирующихся и пересекающихся, видимо всё по той же причине - чтобы не тянуть проводник через весь кристалл);
- команды с префиксом CB;
- прочее (например, 8 "команд" xxNNNxxx).
При этом декодером также распознаётся комбинированный префикс DD/FD CB. Каждая часть декодера имеет свой сигнал запрета декодирования, всего таких сигналов 6, в том числе, например, halt (76) блокирует декодирование 01xxx110 и 01110xxx.

Команды с префиксами DD/FD особым образом в декодере не выделены, их обработкой занимается счётчик M-циклов, выполняя циклы M2 и M3 (чтение смещения и вычисление адреса, 3 и 5 тактов соответственно, для команд без префиксов они пропускаются), и какая-то дополнительная логика (не в декодере).

Префиксы DD и FD не различаются. Принцип такой же, как для F3 и FB - декодер распознаёт обе эти команды, но один из битов команды защёлкивается в триггере (разрешение прерываний; работа с IX или IY).

Префикс (CB, DD, ED, FD) это обычная инструкция, которая выполняется за 1 M-цикл длиной 4 такта. При её выполнении устанавливается соответствующий триггер и при выполнении следующей будет работать уже другая часть декодера, выдавая уже другие управляющие сигналы. Именно так распознаются комбинированные префиксы и именно поэтому в цепочке префиксов действует только последний и не обрабатываются прерывания.

Как устроены эти триггеры и что в какой момент с ними происходит - особая транзисторная магия

Про АЛУ Z80, и вообще интересный блог:
http://www.righto.com/2013/09/the-z-80- ... ow-it.html

pfgx, нужна помощь.
можешь рассказать про in a,(xx) и in a,(c).
Хотелось бы точную растактовку выполнения оных. Особенно с точностью до такта состояние n_iorq и n_rd, и что может повлиять на состояние этих сигналов. В частности может ли z80 сгенерить иголку по каким либо причинам(wait,int,nmi и всё что угодно) на этих двух ногах?

Выходные буферы #MREQ, #IORQ, #RD, #WR управляются через RS-триггеры, так что иголок быть не должно, но имеется интересная особенность: при переводе в Z-состояние у выходных буферов отключается только верхний транзистор, то есть RS-триггер при этом должен находиться в состоянии 1. Находится ли он в нём?

Про состояние с точностью до такта пока не скажу, не добрался. Сейчас тренируюсь в Verilog'е и думаю как это всё туда перенести. Железо для опытов уже есть (Cyclone II, EP2C5Q208C8N), никаких симуляторов