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

[ZXMAK]

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

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

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

[AlexG]

тактирование по фронт и спаду от одного клока - это ОДИН клок. остальные рассуждения неверны для данной ситуации...

[Titus]

Сама идея что Вы это хотите сделать подсказывает, что Вы чтото делаете неправильно. Вся схема должна тактироватьс от одного клока иначе не избежать проблем с асинхронностью и метастабильностью.

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

[aviator]

Вообще, если нужно несколько синхросигналов разной частоты (а это частая ситуация), то для этого есть встроенный PLL. Фаза таких клоков всегда одинакова, кроме того, внутри плисины ещё и применяются специальные меры, чтобы, на этапе синтеза, можно было рассчитать задержку распространения синхросигналов по шинам.
Несколько раз переделывал схемы с малой интеграции и сталкивался с тем, что разработчики использовали трюки с асинхронностью и собственными задержками переключения логических элементов. Главным образом для экономии, или ещё какие спецэффекты хотели получить. А в FPGA это всё повторять смысла не имело, так как синтез по совсем другим правилам.

[ZXMAK]

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

не совсем так. Я наблюдал типичные проблемы асинхронности при тактировании в двух always блоках от одного клока, но от разных фронтов. Это происходило для клока 100 МГц. Я не знаю точной причины почему это происходит, но подозреваю из-за того, что любой клок имеет джиттер и время между posedge и negedge плавает. Поэтому собственно говоря клок нужно на PLL генерировать, чтобы как можно точнее выдерживать 50% duty cycle, иначе из-за плавающего фронта может не хватить времени для переключения каких-то частей схемы. А за счет задержек клока от одной части кристалла до другой, вполне можно получить плавающие race conditions, несмотря на то, что оба always тактируются от одного клока, но от разных фронтов.

Если клок генерировать не на PLL, а каким-то счетчиком, как это делалось в наших ZX Spectrum клонах, то у такого клока будет заметный джиттер и это очень быстро приводит к проблемам, особенно если от клока тактируется большая схема занимающая почти весь кристалл FPGA.

Проявляются такие проблемы с клоком неприятно - всё может прекрасно работать до поры до времени, но в какой-то момент при внесении малейшего изменения (вплоть до изменения значения кода в табличке для FSM) приводящего к переразводке схемы, схема начинает сбоить.

И кстати, я большинство этих проблем наблюдал именно в ситуации использования двух always блоков от одного клока но по разным фронтам.

В FPGA есть еще проблема с тем, что если клок не сгенерирован на PLL блоке, то такой клок разводится как обычные сигналы, а для них в FPGA не предусмотрены меры по минимизации задержек. Clock сигналы имеют имеют отдельную шину, которая позволяет доставить клок в любую часть кристалла с минимальной задержкой или даже задать нужную задержку. Для минимизации задержек PLL блоки расположены с 4 сторон кристалла, что позволяет сократить путь clock сигнала от PLL к любой точке кристалла. Обычный сигнал превратить в клок невозможно, по крайней мере на Altera/Intel.

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

[Titus]

Я наблюдал типичные проблемы асинхронности при тактировании в двух always блоках от одного клока, но от разных фронтов. Это происходило для клока 100 МГц. Я не знаю точной причины почему это происходит, но подозреваю из-за того, что любой клок имеет джиттер и время между posedge и negedge плавает. Поэтому собственно говоря клок нужно на PLL генерировать, чтобы как можно точнее выдерживать 50% duty cycle, иначе из-за плавающего фронта может не хватить времени для переключения каких-то частей схемы.

На таких частотах Z80 гонять особо-то не планирую.
Чтобы перейти на однополярное тактирование, надо сперва сделать двухполярное синхронное, и посмотреть, возможна ли переделка на однополярное БЕЗ ущерба полной идентичности оригинальному NMOS Z80. Если это окажется возможным, то я только за однополярное тактирование. Но если нет, то я по любому сделаю выбор в пользу полной идентичности оригиналу, чем погоне за возможностью запускать спек на 100МГц.

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

В FPGA есть еще проблема с тем, что если клок не сгенерирован на PLL блоке, то такой клок разводится как обычные сигналы, а для них в FPGA не предусмотрены меры по минимизации задержек. Clock сигналы имеют имеют отдельную шину, которая позволяет доставить клок в любую часть кристалла с минимальной задержкой или даже задать нужную задержку.

Полезная информация. Учту на будущее.
Но пока что, если не гоняться за предельными частотами, думаю, что проблем не должно быть.

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

Плюс, на сколько я понимаю, некоторым линиям (тому же CLK) можно задать параметр, что они должны трассироваться для самого короткого (быстрого) пути прохождения сигнала.

[AlexG]

ZMAX местами не прав от слова совсем...
клок можно делать из чего угодно, но требуется выполнить ряд условий:
- оный клок должен быть описан в "временных ограничениях" (частота, скважность, фаза)
- должен использоваться только как "клок", но ни как обычный сигнал
- временами требуется явно указать что этот сигнал надо "разводить правильно"
ПС: отсутствие оных и других constrains - это основная ошибка "начинающих/любителей", а потом порождаются вот такие легенды


ПСПС: использование PLL приводит к не явному созданию "нужных ограничений" и посему совет использовать PLL приводит к желаемому результату.

[Titus]

- оный клок должен быть описан в "временных ограничениях" (частота, скважность, фаза)

Кстати, где это описывается и как?

[Barmaley_m]

Если клок генерировать не на PLL, а каким-то счетчиком, как это делалось в наших ZX Spectrum клонах, то у такого клока будет заметный джиттер

Вот не знаю. Я не вижу причин появления дрожания (джиттера) на выходе счетчика, если исходный тактовый сигнал не имел такого дрожания. Более того, даже делитель на 2 уже гарантирует 50% скважность, даже если исходный тактовый сигнал имел иную, или даже переменную, скважность. Опять же, при условии, что там не было дрожания нарастающего фронта.

Если же качество исходного тактового сигнала (в плане дрожания и скважности) вызывает сомнения - тогда да, тогда ФАПЧ (PLL) может в некоторой степени "очистить" тактовую частоту. Но у всего есть пределы. Если исходный сигнал совсем плохого качества - то не поможет и ФАПЧ.

Проявляются такие проблемы с клоком неприятно - всё может прекрасно работать до поры до времени, но в какой-то момент при внесении малейшего изменения (вплоть до изменения значения кода в табличке для FSM) приводящего к переразводке схемы, схема начинает сбоить.

Тут подписываюсь. Поскольку качество исходного тактового сигнала зачастую достоверно неизвестно - то инструменты синтеза не позволяют учесть все возможные отклонения. Также точность моделирования инструментов синтеза не 100%. Поэтому иногда появляются плавающие сбои даже в таких конфигурациях, синтез которых прошел без ошибок Timing Constraints.

В FPGA есть еще проблема с тем, что если клок не сгенерирован на PLL блоке, то такой клок разводится как обычные сигналы, а для них в FPGA не предусмотрены меры по минимизации задержек. Clock сигналы имеют имеют отдельную шину, которая позволяет доставить клок в любую часть кристалла с минимальной задержкой или даже задать нужную задержку.

На Xilinx таких проблем нет. Если какой-либо внешний или внутренний сигнал подается на тактовый вход триггера - то синтезатор автоматически пропускает его через глобальный тактовый буфер (BUFG), который рассчитан на большое количество нагрузок (много тактовых входов триггеров) и разводку с минимальной задержкой по всему кристаллу. Еще там есть локальные тактовые буфера (BUFH и т.д.), которые распределяют сигнал от BUFG на триггеры в локальной области чипа (напр. северозападный квадрант), но включение этих буферов полностью автоматизировано софтом для синтеза, в это лучше не вмешиваться.

Количество BUFG на кристалле очень ограничено. В моем чипе Spartan-6 их было 16 - это при десятках тысяч общего кол-ва триггеров.

Обычный сигнал превратить в клок невозможно, по крайней мере на Altera/Intel.

На Xilinx без проблем. Но на это расходуется ограниченный ресурс BUFG.

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

Для сигнала на входе ФАПЧ важно обеспечить, чтобы этот сигнал был периодическим, с одним импульсом за период. Не допускать выпадений тактовых импульсов и тому подобной грязи. В противном случае ФАПЧ не сможет синхронизироваться с таким сигналом и достичь стабильной работы. Некоторое дрожание входного сигнала ФАПЧ сглаживает, но есть предел.

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

Кстати, где это описывается и как?

Для Xilinx - UG612 "Xilinx Timing Constraints User Guide"
Пробиться сквозь дебри этого документа непросто. Даю небольшой лайфхак.
Достаточно только задать в Timing Constraints параметры входного тактового сигнала. Синтезатор прослеживает распространение тактовой частоты по всей схеме, в том числе случаи умножения и деления этой частоты на блоках ФАПЧ (PLL) и DCM). Также синтезатор контролирует время прохождения обычных (не тактовых) сигналов через комбинационную логику и разводку связей и автоматически обеспечивает, чтобы это время не превышало периода тактовой частоты для всех сигналов. Поэтому, особенно для простых схем, лишь указание параметров входной тактовой частоты достаточно.

Дополнительные Timing Constraints нужно указывать только в следующих случаях:
1) Обеспечение гарантий на внешних интерфейсах ввода-вывода;
2) Прохождение сигналов между разными тактовыми зонами (между системами триггеров с разной тактовой частотой);
3) Деление тактовой частоты "вручную" с помощью счетчиков - тогда нужно указать, какое соотношение с входной тактовой частотой имеет выходная.
- - - Добавлено - - -

Плюс, на сколько я понимаю, некоторым линиям (тому же CLK) можно задать параметр, что они должны трассироваться для самого короткого (быстрого) пути прохождения сигнала.

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

В конце своей работы (т.е. раскидывания логики по физическим ресурсам FPGA и разводки связей между ними) трассировщик либо сообщает, что он смог обеспечить заданные требования (напр. не более 10нс задержки для всех сигналов), либо не смог. В последнем случае приходится либо оптимизировать схему, либо снижать тактовую частоту.

[AlexG]

Уточню. тов Barmaley_m даёт ссылки на документацию для среды ISE 14.7
Сиё достаточно подробно описывает про ограничения, но в более современной среде Vivado используется другой формат описания ограничений (*.UCF заменяется *.SDC). Но суть временных ограничений от этого не меняется.