Вид для печати
Меня всегда поражает на форуме одна и та же повторяющаяся ситуация. Вот, допустим, кому-то интересна какая-то тема. Человек исследует и делится откртытиями с сообществом. И вот в тему приходит другой человек и пишет ПОЛТОРА ДЕСЯТКА сообщений о том, как ему это все неинтересно и какая вообще это все ненужная никому фигня. Да все все поняли, не нужная тебе это ерунда. Ну чего ходить в эту такую неинтересную тему и писать как это все отвратительно.Цитата:
Сообщение от Deadly
В смысле не нужно? Яж написал что нужно компактная выписка, а не поиск в 100500 страниц?
- - - Добавлено - - -
Ты попутал с ccf и scf в соседней теме, не путай. А то всегда найдется чел, который не разобравшись, делает выводы
- - - Добавлено - - -
Титус вот ты написал как в and, а как оно в нем я хз, где искать, я хз, не перелистывать же 48 страниц. Но ты проигнорил мой вопрос, а потом вы обижайтесь..
Команда AND описана всеми, кому не лень, и в фирменной документации тоже.Цитата:
Сообщение от Deadly
Понятно, что ничего не понятно.
Документация полная и детальная, но не полная и не детальная...
Согласен с предыдущими ораторами, форум это древний и неудобный формат общения.
Мы все результаты выкладываем на гитхаб и оформляем как Markdown (быстро, просто и красиво получается).
А всё обсуждение происходит в чате, т.к. по сути оно только уточняет формализацию, а после просто "замусоривает" контент.
Не призываю к революции, можно же и альтернативный вариант -- выложить результаты куда-то в компактном скомпилированном виде (хоть в .txt файл), а обсуждение продолжить как и раньше в этой ветке.
Но формализация результатов в отдельном виде нужна. Т.к. нет форума - нет и информации (мало ли что, хостинг упал, ддос и проч.)
Понятное дело, что финальные результаты надо выложить компактно, чтобы никто не собирал информацию по тысячам страниц форума.Цитата:
Сообщение от org
Где их можно уже лицезреть, хотя бы то что накопано?
Мне нечего сказать стоящему в воде, который не может напиться.:v2_dizzy_botan:Цитата:
Сообщение от Deadly
Все только в этой теме.
Хотя, есть чего - постарайся поменьше флудить)
я могу не заходить, жаль что ты воспринимаешь это ка флуд...Цитата:
Сообщение от Titus
Выполнена основная часть исследования по регблоку TOSHIBA Z80 MPU (CMOS).
https://github.com/emu-russia/SEGACh...4C/regblock.md
Выкладываю также пдф для (более комфортного?) чтения: https://github.com/emu-russia/SEGACh...lock-rev1-pdfs
Синопсис: работа регблока почти не отличается от эталонной NMOS реализации, которая тут ковыряется. Если что-то обнаружим подозрительное описание будет дополнено.
Я так понял, потранзисторную схему всего чипа никто рисовать не будет?Цитата:
Сообщение от org
- - - Добавлено - - -
Тошиба случайно не TMPZ84C00AP-6?
Она в тестах SCF9 давала другие результаты, чем все остальные Zilog'овские CMOS.
Транзисторные схемы мы уже давно не делаем для всего чипа, сразу переходим к модульному дизайну (вентили целиком, стандартные ячейки). Для некоторых хитрых модулей трансы иногда используются для уточнения работы ячеек.Цитата:
Сообщение от Titus
T84C00AM-5.Цитата:
Сообщение от Titus
Не больше ли шансов накосячить, пропуская этап транзисторной схемы? Я понимаю, для регулярных структур, типа регистров, можно не рисовать все. Но для всякой разнообразной мелкой нерегулярной логики, которой бывает изрядно много?Цитата:
Сообщение от org
Шанс накосячить в трансах гораздо выше чем в ячейках, но да, ошибки случаются, исправляются. Цифровая логика она, знаешь ли, очень логичная :) Если где-то косяк, то его сразу видно на прогоне в тест бенче или логисиме.Цитата:
Сообщение от Titus
- - - Добавлено - - -
P.S. Если интересно какой у нас workflow, то его можно наблюдать из раздела по IDU CLA: https://github.com/emu-russia/SEGACh...arry-lookahead
1. Получается топология (необязательно, если вместо кастомного дизайна используются стандартные ячейки)
2. Из топологии выделяются логические элементы (в IDU CLA это куча nand, not, nor)
3. Определяются порты (input, output) исследуемого куска схемы
4. В утилите Deroute получается netlist. Этот шаг можно представить по аналогии с дизассемблированием программ - получается как бы "исходник" (дизасм)
5. Утилита Deroute умеет экспортировать готовый к употреблению Verilog исходник ( https://github.com/emu-russia/SEGACh...list/idu_cla.v )
6. Полученный верилог можно запихать куда угодно (для симуляции например). В частности верилог был запихнут в Xilinx PlanAhead и она сама "нарисовала" логическую схему которую можно вдумчиво вкурить, разобрать на части, проверить в логисиме. Или сразу использовать верилог в прикладных целях.
Такой подход мы используем где-то последние два года и он МЕГА эффективный для изучения микросхем.
Т.е. базовым элементом отреверсенной схемы является логический n-входовый элемент?Цитата:
Сообщение от org
Ну это тоже неплохо.
- - - Добавлено - - -
В основном да. Но могут быть нюансы, если, например, перепутал полярность тактового сигнала, и что-то сдвинулось на пол-такта. Вроде и работает по скорости так же, а тайминг чуть нарушен.Цитата:
Сообщение от org
Не обязательно один логический, это может быть композитная ячейка составленная из кучки nand,nor,mux и часто повторяющаяся (например DFF). Тут применяется подход, схожий с "макро-программированием" (макросы).Цитата:
Сообщение от Titus
Про полярность сигнала это старая боль, нужно просто глаз набить на это. Есть простое правило как не запутаться в полярности - если сигнал проходит not, nor или nand, то не важно с какими другими сигналами он замешивается - на выходе полярность поменяется.
То есть если условно на вход какой-то схемы пришёл сигнал "a" с точно известной полярностью и нужно узнать полярность выходных сигналов, нужно всего-лишь пробежаться по цепочке элементов и каждый раз менять полярность после прохода через not,nand,nor.
(причём это можно делать и задом-наперёд)
Предварительное описание особенностей работы M-циклов:
- Каждый M-цикл отвечает за новый доступ к памяти. Поэтому, собственно, он и называется M-циклом.
- M1 отвечает за выборку кода операции. В общем случае длится 4 такта, но может увеличиваться до 6 тактов. Во время этого цикла выполняется текущая и завершается предыдущая стандартная АЛУ-операция.
- M2 отвечает за выборку байта смещения для индексной адресации. В общем случае длится 3 такта. Он используется как в методах адресации с индексными регистрами, так и в командах относительного перехода (JR, DJNZ). Если цикл используется в команде условного перехода, и условие не соблюдено, то является последним циклом команды.
В этом цикле после чтения байта смещения из памяти происходит его загрузка в ALUB, а младший байт адреса (PC.L или IDX.L) загружается в ALUA. После чего складывается младшая часть адреса и байт индекса. Далее устанавливается знак для следующей АЛУ-операции (плюс или минус) в зависимости от старшего бита байта смещения, если это команда относительного перехода.
- M3 отвечает за продолжение вычисления исполнительного адреса для индексной адресации. Обычно длится 5 тактов.
Так как этот цикл используется для вычисления исполнительного адреса, в нем блокируется доступ к внешней памяти по адресу, автоматически загруженному в PCR в предыущей команде.
В этом цикле полученный в АЛУ младший байта адреса сохраняется PC.L или WZ.L, затем в АЛУ загружается старшая часть адреса, и константа 0, для сложения со старшей частью адреса, и снова складывается и записывается в PC.H или WZ.H.
В результате, если это команда перехода, в регистре PC получаем новый адрес. Если же это команда индексной адресации, то в регистре WZ получаем исполнительный адрес.
- Циклы M2 и M3 могут быть пропущены, если команда не использует индексную адресацию.
- M4 отвечает за байтовый доступ к памяти в стандартных командах типа ADD A,(HL) или ADD A,(IX+nn). Обычно длится 3 такта.
- M5 пока не изучался, но, похоже используется в 16-битных командах, таких как ADD HL,dd, PUSH/POP HL, LD (nn),dd и т.д.
- - - Добавлено - - -
p.s.: Небольшая ремарка. Некоторые действия могут инициироваться в одном M-цикле, а завершаться в следующем, т.к. чуть ли не большая часть активности процессора всегда задержана на пол-такта или такт относительно такта, инициировавшего ее.
M-цикл это "машинный цикл", из официального программинг мануала от создателей: https://www.zilog.com/docs/z80/um0080.pdf
И так так тоже подходит по смыслу)Цитата:
Сообщение от org
- - - Добавлено - - -
Как не набивай глаз, невнимательность никто не отменял. Особенно при работе с большими схемами. У меня это почти единственный тип ошибок при переводе транзисторной схемы в логическую. И да, 99% таких ошибок, если не 99.99% приведут к неработоспособности того или иного участка схемы и будут замечены.Цитата:
Сообщение от org
Не очень понял как можно сломать схему, если перепутать название (полярность) сигнала, ну да ладно :)Цитата:
Сообщение от Titus
В смысле как? Если я вместо, допустим, 2ИЛИ-НЕ впилю 2ИЛИ, то схема сломается.Цитата:
Сообщение от org
А почему должен впиливаться какой-то другой вентиль? Если переименовать провод он по другому работать не будет. Тут судя по всему не в полярности проводов дело, а в том что трансы перегоняются в вентили неправильно. Полярность сигнала тут причём?Цитата:
Сообщение от Titus
И наконец, особенности установки 5 и 3 бит регистра флагов после выполнения команды BIT r,(HL).
В команде BIT n,(HL) в отличие от команд типа ALU (HL) цикл чтения аргумента из памяти (M4) длится 4, а не 3 такта!
Почему такое происходит, при том что команды абсолютно однотипные?
Дело в том, что все команды с префиксом CB активизируют сигнал GRP_OFFSET, как и команды работающие только с индексной адресацией. Очевидно, это сделано для универсализации работы набора CB с индексной адресацией. А быть может просто вследствие ошибки. Если бы не эта совершенно ненужная особенность, команда BIT n,(HL) выполнялась бы не 12, а 11 тактов.
Сигнал GRP_OFFSET в основном влияет на циклы M2 и M3, отвечающие за индексную адресацию. Но при этом он еще и влияет на длительность цикла M4, продлевая его с 3 до 4 тактов. И этот 4-й такт совершенно для нашей команды бесполезен!
Но самое главное, что в такте M4.T4.2 всегда активно чтение старшего байта выбранного регистра на шину HBUS. А какой же регистр у нас выбран? А выбран WZ, т.к. когда не выбран никакой регистр, всегда выбирается WZ. В результате на обьединенной шине HBUS/LBUS оказывается не содержимое рабочего регистра r, как в команде BIT n,r, а старший байт регистра WZ, который используется другими командами для вычисления исполнительного адреса при индексной адресации.
Возникает вопрос, ведь в последнем такте любой команды должен выбираться регистр PC, и это должно блокировать выбор WZ?
Нет, не блокирует, т.к. выбор регистра PC для чтения кода операции управляется отдельной линией, и не блокирует выбор WZ. Иными словами, в первом такте следующей за BIT n,(HL) команды одновременно читается регистр PC из дополнительного регистрового блока (регистры PC и IR) для выборки кода команды, и читается регистр WZ.H из основного регистрового блока на шину HBUS/LBUS, откуда через несколько тактов и попадает в 5 и 3 биты флагового регистра.
- - - Добавлено - - -
При чем тут название провода. От имени ничего не меняется. Когда я перегоняю трансы в вентили, либо же когда оптимизирую схему, соединяя несколько вентилей в триггер, или меняя полярность какой-то линии, т.к. в оригинале она инверсная, а для лучшего понимания схемы следует линию сделать прямой. Вот тут и может закрасться ошибка. Повторюсь еще раз, я не делаю схему для клонирования ее в ФПГА. Прежде всего я делаю схему, чтобы она была наглядной и понятной, поэтому вследствие этих оптимизаций и может закрасться ошибка перепутанной полярности.Цитата:
Сообщение от org
Понял. Мы этот процесс называем "деморганизация". За годы убедились что оно подвержено ОЧЕНЬ большому количеству ошибок и поэтому лично я де-Моргана не проворачиваю. Оставляю как есть.Цитата:
Сообщение от Titus
Ну ведь они же выявятся, когда схема не заработает? И исправятся)Цитата:
Сообщение от org
- - - Добавлено - - -
Да, через 'деморганизацию' у меня прошла вся схема вдоль и поперек.
Нет деморгана - нет дополнительных ошибок. Исправятся, да, но зачем вносить лишние ошибкиЦитата:
Сообщение от Titus
У меня нет другого варианта преобразовать схему в самый дружественный и понятный вид, кроме как таким образом.Цитата:
Сообщение от org
Ну опять же возвращаясь к теме "понимания". Комбинаторно-последовательностная логика, в которой ты копаешься - понимается путём изучения временных диаграмм.Цитата:
Сообщение от Titus
Это brainchild разработчиков чипа.
Даже если ты красиво восстановишь схему - тот кто будет искать практическое применение не будет изучать вентили - "ммм а тут у нас AND, тот OR агась потом это идёт на этот FF". Ему интересней будет понимать какие диаграммы порождает данный кусок логики. Схему никто "читать" не будет, только в крайнем случае, если возникнут вопросы, на которые нельзя ответить просматривая вейвы.
Это тоже самое что восстанавливать дизассемблированный код умножения двух матриц написанный на SSE. Не нужно понимать почему одна SSE следует за другой. Нужно понимать просто как работает каждая инструкция ("вентили") и что в итоге делает весь кусок кода ("логики").
И к другим новостям. Я начал восстанавливать топо верхнего левого угла тошибовского з80. Там находится клоковый гена, буферы для DB интерфейса и АЛУ.
Изучение диаграмм - это смотреть только на последствия, но не на причину.Цитата:
Сообщение от org
Для простого повторения чипа в ФПГА и контроля идентичности - вполне подходяще. Экономит время и деньги.
Однако, для моих целей - детального изучения особенностей работы Z80 смотреть только на последствия - не информативно.
Попробуй найти, почему шумит команда SCF/CCF по диаграммам? Диаграммы даже не покажут этот шум.
Почему OUT (c),0 выдает ноль? Почему BIT n,(HL) выставляет так флаги, и как?
Видя схему, это понимается достаточно легко и быстро.
Диаграммы модели в проекте Z80 Explorer существуют уже 10 лет. Но как-то это не особо продвинуло в понимании некоторых загадок Z80, которые без видения причин, а не последствий отгадать можно только умозрительно и предположительно.
Твой подход хорош для твоих целей. А мой для моих. Каждому своё)
- - - Добавлено - - -
Лучше картинки не прикреплять средствами форума, они несмотрибельные.Цитата:
Сообщение от org
Лучше на сторонний хостинг. Мы использовали pic.maxiol.com, хотя по стечению обстоятельств, он сегодня первый день, как не работает)
Упрощенное описание команд LDI(R)/LDD(R):
В такте M1.T4 сбрасываются флаги N и H.
В такте M2.T1 содержимое HL записывается в PCR и на шину адреса для чтения содержимого памяти по адресу (HL).
В такте M2.T3 инкрементированное (для LDI(R)) или декрементированное (для LDD(R)) содержимое PCR обратно записывается в регистр HL.
В такте М3.T1 содержимое DE записывается в PCR и на шину адреса для записи байта в память по адресу (DE).
В такте M3.T3 инкрементированное (для LDI(R)) или декрементированное (для LDD(R)) содержимое PCR обратно записывается в регистр DE.
В такте M3.T4 содержимое BC записывается в PCR. Если BC = 1, то флаг P=0, иначе флаг P=1. Если BC = 1 или команда LDI/D, то этот цикл является последним циклом команды.
В такте M3.T5 декрементированное содержимое PCR записывается обратно в регистр BC. Также в этом такте + 1 на шину HBUS выдается результат работы АЛУ. В нашем случае (точно пока не изучал) АЛУ должно было сложить содержимое регистра A и байта, который копировался из (HL) в (DE). Таким образом, 5 и 3 биты регистра флагов берутся из A + (HL).
В такте M4.T1 содержимое PC записывается в PCR.
В такте M4.T3 декрементированное содержимое PCR записывается обратно в PC и снова читается в PCR
В такте M4.T5 декрементированное содержимое PCR записывается обратно в PC.
Мои пять копеек. Нарисовать "транзисторную схему" - значит понять ВСЕ нюансы поведения схемы. Особенно если применить аналоговое моделирование (что то типа Verilog-AMS). Если рисовать сходу "логическую схему" - то потеряется ВСЯ информация об UB (неопределённое поведение). Посему можно добиться "правильного поведения" при "правильных входных воздействиях", но если создать "не штатную ситуацию" - "логическая схема" даст сбой в поведение (она не будет на все 100% совпадать с оригиналом.).
Задача сего топика - это полноценное вскрытие "чОрного ящика" для полноценного раскрытия оного UB.
ПС: а для целей создания сеги/несов итд это излишнее знание...
Никто не запрещает модули где есть UB разметить специальным образом, в том числе тупо трансами.Цитата:
Сообщение от AlexG
Оба правы. Давайте жить дружно. У каждого свои цели и способы (адекватные к задачам). Лично мне нравится способ ТС.
Товарищ @Vslav, который и заварил всю эту кашу с реверсами на форуме, делал вообще только транзисторную схему, а уже с нее Verilog-модель. И если что, сверялся только с транзисторной. Я так не могу, мне нужна транзисторная, как базис, и логическая, как удобная для быстрого анализа и оптимизации.Цитата:
Сообщение от AlexG
Заполнены разделы по клоковому гене и по интерфейсу с внешней шд.
https://github.com/emu-russia/SEGACh...T84C/clkgen.md
https://github.com/emu-russia/SEGACh...ain/T84C/db.md
(включая анализ падов)
Также подглядывая в NMOS Z80, сформировалось 2 подозрения (пока нет 100% уверенности):
- чип в Visual Z80 лежит вверх ногами
- сигнал clk в Visual Z80 на самом деле _clk (active-low), т.к. из того что я вижу у себя в регблоке - на время clk=0 производится подзарядка бит лайнов ячеек SRAM и регистры в этом время использовать нельзя ("команды" reg_load_xxx).
https://i.imgur.com/lwBCOnv.png
Такие картинки у нас показывал ув. М.Гамаев, где явно видно что reg_load_af активируется на clk=0, что мне очень подозрительно.
А в чем несостыковка? Внешний вход /CLK инверсный, затем внутри он инвертируется. Т.е. при внешнем CLK = 0 заряжаются лайны.Цитата:
Сообщение от org
- - - Добавлено - - -
В смысле вверх ногами? Чип крутят так, как удобно, у него нет ни верха, ни низа) А то, что надписи на кристалле ориентированны в какую-то сторону, это еще ничего не значит.Цитата:
Сообщение от org
Несостыковка в том, что по даташитам - он Active High. И как раз с учётом всех инверсий в CMOS Z80 - внутренний clk такой же полярности, что и внешний.Цитата:
Сообщение от Titus
https://github.com/emu-russia/SEGACh...sim/clkgen.png
В даташите от Zilog'а он инверсный:Цитата:
Сообщение от org
https://pic.maxiol.com/images2/17287...595414782..png
Я вот сижу и думаю - что это значит если CLK - Active Low.Цитата:
Сообщение от Titus
Также сижу втыкаю в z80 remix и в упор не вижу, чтобы входной пад назывался _clk:
https://i.imgur.com/CESj5sL.png
Видимо, назвали пин, как в старых даташитах без инверсии.Цитата:
Сообщение от org
- - - Добавлено - - -
Это загадка, но ее надо просто принять)Цитата:
Сообщение от org