Реверс-инжиниринг Z80

[Titus]

Логика очень проста.
При активном уровне на C0, данные с D0 защелкиваются на выходе.
При активном уровне на C1, данные с D1 защелкиваются на выходе.

И т.д. В схеме 4-х портовые триггеры даже есть.

[Advertiser]

[Barmaley_m]

При активном уровне на C0, данные с D0 защелкиваются на выходе.
При активном уровне на C1, данные с D1 защелкиваются на выходе.

А, так это еще и "прозрачный" триггер-защелка, у которого при активном уровне на C0 или C1 данные со входа на выход проходят постоянно?

Регистры-защелки в FPGA имеются (в Spartan-6 - точно), но их использовать не рекомендуется, по тем же причинам, что асинхронные входы R/S.

По твоему описанию логики работы, такой элемент реализуется в FPGA с помощью мультиплексора, логики и одного триггера. Мультиплексор пропускает на свой выход сигнал D0 или D1 в зависимости от состояния C0. Логический элемент "ИЛИ" объединяет C0 и C1 в сигнал разрешения записи в триггер. И, наконец, сам триггер (лучше всего D-типа, работающий от основной тактовой частоты). Получается синхронный элемент памяти, работающий близко к тому, что ты описал. Как его вписать в остальную схему, пойдет ли он там со своей синхронностью - это уже надо разбираться глубже.

[Titus]

А, так это еще и "прозрачный" триггер-защелка, у которого при активном уровне на C0 или C1 данные со входа на выход проходят постоянно?

Да

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

Регистры-защелки в FPGA имеются (в Spartan-6 - точно), но их использовать не рекомендуется, по тем же причинам, что асинхронные входы R/S.

Да, я уже отметил, что все триггеры работающие по уровню в для FPGA надо будет сначала переделать в работающие по фронту.

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

По твоему описанию логики работы, такой элемент реализуется в FPGA с помощью мультиплексора, логики и одного триггера.

Да, я так примерно и представлял.

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

Пробежался по текущей схеме, заменил RS-триггеры, у которых входы тактировались одинаковой полярностью (CLK или /CLK) на RCS-триггеры. А триггеры, у которых входы тактировались разными полярностями пока оставил как есть. Я думаю, самое главное, что в данной схеме все RS-входы в триггерах так или иначе синхронны с CLK или /CLK, поэтому проблем с синтезом у FPGA не будет.

[AlexG]

Логика очень проста.
При активном уровне на C0, данные с D0 защелкиваются на выходе.
При активном уровне на C1, данные с D1 защелкиваются на выходе.
И т.д. В схеме 4-х портовые триггеры даже есть.

Для RS/вот этих триггеров и ещё что там по схеме.
И отслеживать "запрещённые входные комбинации":
- либо гарантировать их отсутствие
- либо отслеживать доп. логикой с выводом на "лампочка авария"
- тд пт

ПС:соглашусь: latch крайне не рекомендуется к употреблению, но в плисе он реализуем физически.

[aviator]

В силу смены работы писал на Verilog очень давно, но вставлю свои "5 копеек". Для обучения мне очень помогло отвлечься от абстракций в виде электрических принципиальных схем на "рассыпухе", а вернуться к математическо-программистским корням, к дискретной математике и теории вычислительных процессов. А именно - к комбинаторике, графам, автоматам различных типов и их оптимизации. И вот это всё на Verilog перекладывается просто превосходно. То есть, не надо заниматься "синтезом" из логических и прочих элементов, надо заниматься математическим описанием (и оптимизацией) того, что надо сделать. А синтезом займётся сама среда типа Quartus (в конторе были Альтеры в почёте). Например, не надо рисовать схему какого-либо узла Z80 из логических элементов, надо рисовать её в виде графа, описывающего автомат. Со входом, выходом, состояниями, памятью и т.п. И его математическо-текстового представления, если надо. И оптимизация тут будет - вычислительная, в первую очередь. А оптимизацией синтезируемой логической схемы займётся софт.
Андрей, моё почтение! Реверс-инжиниринг процессора это титанические усилия. Пройти весь путь в обратном порядке: транзисторы -> логика -> математика...

[Titus]

Например, не надо рисовать схему какого-либо узла Z80 из логических элементов, надо рисовать её в виде графа, описывающего автомат.

Мне наиболее удобно привести схему сперва в классический логический вариант. Именно такую схему я могу быстро читать и понимать, когда она такая глобальная, как Z80. Ведь перевести на FPGA - это лишь попутная идея. Основная моя идея - это привести в наиболее понятный вид (логический), описать, найти нюансы, ошибки, особенности, понять принцип работы. А уже из этой точки можно и эмулятор потактовый делать, и FPGA, и т.д. Конечно я могу читать и понимать потранзисторную схему. Но уровень ориентирования в ней для меня гораздо ниже, чем в логической. Это все равно как сравнить си и ассемблер. Я вообще удивляюсь, как @Vslav переводил в Verilog транзисторные схемы сразу, минуя логический этап. Мне такое неудобно. Поэтому все делаю последовательно, как мне понятнее. Сперва транзисторная, потом логическая, потом причесывания и понимание. А потом уже куда угодно можно двигаться. Да и другим понятнее она.

[aviator]

Поэтому все делаю последовательно, как мне понятнее. Сперва транзисторная, потом логическая, потом причесывания и понимание. А потом уже куда угодно можно двигаться. Да и другим понятнее она.

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

По поводу защёлок - надо смотреть каждый случай. Как уже сказали, она реализуема физически. Но! Может быть, что в математический и verilog-модели этот элемент будет вообще лишним. Либо же будет являться элементом памяти конечного автомата, а многие FPGA имеют для этих целей скоростную внутреннюю память.

[Barmaley_m]

... отвлечься от абстракций в виде электрических принципиальных схем на "рассыпухе", а вернуться к математическо-программистским корням, к дискретной математике и теории вычислительных процессов. А именно - к комбинаторике, графам, автоматам различных типов и их оптимизации. И вот это всё на Verilog перекладывается просто превосходно.... А оптимизацией синтезируемой логической схемы займётся софт.

Полностью абстрагироваться от железа и полностью полагаться на оптимизацию софтом - большая ошибка. С таким подходом получаются огромные и тормозные реализации в FPGA. Я видел множество примеров функциональных блоков от той же фирмы Xilinx, где такое вот абстрактное программирование раздувало потребление ресурсов кристалла сверх всякой меры.

Конечно, мышление в терминах логических схем плохо ложится на VHDL/Verilog. Но это объясняется тем, что VHDL/Verilog - это языки симуляции, а не описания логических схем. Их под роль описания приспособили насильно.

Из своего опыта могу сказать, что наилучшие результаты дает нахождение некоторого компромисса. Мыслить по-прежнему в логике, регистрах и мультиплексорах. Лишь некоторые сложные узлы, вроде конечных автоматов со сложной диаграммой переходов, можно оставить на синтез и оптимизацию софту, а самому придумывать их именно в виде конечных автоматов, а не логических схем, и напрямую описывать как автоматы на Verilog/VHDL.

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

Я в начале, как учился разработке на FPGA, пытался все делать в виде логических элементов, регистров и т.п., полностью на уровне схемы. Сделал себе VHDL-блоки для регистров, счетчиков и т.п. с настраиваемыми параметрами, а далее вставлял их в "схему", т.е. VHDL-элемент более высокого уровня. Такой подход работал, но позже я понял, что он неэффективный в плане удобства разработки. И стал уже напрямую не вставлять в схему счетчики, а писать для них "процессы" или даже вставлять реализацию счетчиков в другие процессы, которые еще чем-то занимались. Получал на выходе синтеза те же самые схемы, но более лаконично описанные.

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

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

Правда, пока не понял, как задавать такой блок И для спада CLK, и для фронта.
И при этом, чтобы в блоке для фронта и спада делались разные действия.

В твоем случае лучше всего иметь как минимум два разных always-блока, один для фронта, второй для спада. И выполнять в каждом из них соответствующие действия.

В Verilog или VHDL можно создать always-блок (или процесс), запускающийся и по фронту, и по спаду, и вообще по произвольным событиям. Но такой блок может быть затруднителен для синтеза схемы. Одно маленькое отличие логики внутри блока - и потребление ресурсов кристалла возрастет десятикратно. И триггеры будут реализовываться не на встроенных в кристалл триггерах, а на комбинационных схемах с обратной связью. И тому подобные аномалии. Лучше всего иметь только always-блоки по фронту или спаду, и никаких других.

[Titus]

Почитал про Verilog. В общих чертах все понятно, и что такое always-блоки.
Правда, пока не понял, как задавать такой блок И для спада CLK, и для фронта.
И при этом, чтобы в блоке для фронта и спада делались разные действия.

[AlexG]

Почитал про Verilog. В общих чертах все понятно, и что такое always-блоки.
Правда, пока не понял, как задавать такой блок И для спада CLK, и для фронта.
И при этом, чтобы в блоке для фронта и спада делались разные действия.

always-блок не может работать по фронту и спаду от одного и того же сигнала (в данном случае CLK). Только либо по фронту либо только по спаду.
https://www.asic-world.com/examples/...flip_flop.html