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

[Titus]

такие вещи взглядом не заметишь. Это как программа написанная, но ни разу не скомпилированная. Смотришь вроде все правильно, а начнешь компилировать и дебажить и вылезут ошибки.

Да, я думаю, если сконвертировать на верилог текущее состояние логической схемы (не транзисторной, с ней на 99.999% все ок), то это сразу не заработает)

[Barmaley_m]

Как поступить в случае, когда какие-то триггеры тактируются фронтом не глобального CLK, а каким-то другим сигналом, например, T1 (им тактируется счетчик фаз M1, M2 и т.д.). Как правильно сделать, вот так:

always @(posedge T1) begin
...
end

Либо же во так:

always @(posedge clk) begin
if (T1 = 1) begin
...
end
end

Однозначно второй вариант. По возможности надо делать так, чтобы все триггеры схемы тактировались одной частотой. Если какие-то части схемы работают на половине или других долях от этой частоты - то следует использовать вход триггеров Clock Enable (CE), описав его на HDL в виде команды if, наподобие твоего второго варианта, для достижения поставленной цели.

Деление тактовой частоты триггером и использование результата для тактирования какой-то части схемы имеет следующие недостатки:
1) Расходуются глобальные тактовые буферы (в примере Spartan6 - BUFG)
2) Поделенная тактовая частота будет из-за задержек элементов схемы и разводки выхода триггера на тактовый буфер и обратно сдвинута по фазе относительно исходной. Эти сдвиги затронут также все сигналы от триггеров, работающих от половины тактовой частоты. Все эти задержки будут отниматься от "бюджета времени" при переходе сигналов данных от триггеров, тактируемых полной тактовой частотой, на триггеры, тактируемые ее половиной, и обратно. В результате будет труднее обеспечить выполнение Timing constraints, снизится максимальная тактовая частота проекта.

[Titus]

Если какие-то части схемы работают на половине или других долях от этой частоты - то следует использовать вход триггеров Clock Enable (CE),

До того, как Hardwareman про это написал, я не знал, что у триггеров в ПЛИС есть входы разрешения тактирования. Так-то оно конечно, логичнее. Другой вопрос - на всех ли современных ПЛИС у триггеров есть входы CE?

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

1) Расходуются глобальные тактовые буферы (в примере Spartan6 - BUFG)

Сколько их в среднем бывает?
И прям на каждый клок триггера расходуется свой буфер, если клок не совпадает с уже имеющимися?

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

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

[AlexG]

1) У всех xilinx ( упоминал ранее UG768 v14.7) есть CE у триггеров.
2) К примеру плиса о 200 выводов 53200 LUT (универсальная логика) + 106400 FF (триггера) имеют всего 32 BUFG (глобального буфера для распределения тактовой).
3) зависит от настроек "компилятора" (наверное - я такое не практикую от слова совсем. посмотрел один раз на результат - ужаснулся, перекрестился, сплюнул три раза и зарёкся ТАК делать).
ПС: не надо заморачиваться специально про СЕ. Достаточно писать
always @(posedge clk) begin
if (T1 == 1) begin
....
синтезатор "сам придумает" схему как сделать лучше (через СЕ или через комбинационную схему или ...). Конечно есть специальные "указания/прагмы/аттрибуты" которые указавают КАК хочется автору (но это надо иметь экспириенс от 58).

----------------------------------------
Триггеры:
FDCE Primitive: D Flip-Flop with Clock Enable and Asynchronous Clear
FDPE Primitive: D Flip-Flop with Clock Enable and Asynchronous Preset
FDRE Primitive: D Flip-Flop with Clock Enable and Synchronous Reset
FDSE Primitive: D Flip-Flop with Clock Enable and Synchronous Set

[Titus]

3) зависит от настроек "компилятора"

Это ответ на какой вопрос?

[AlexG]

"каждый следующий каскад расходуется глобальный тактовый буфер?" - наверно зависит от настроек "компилятора" .
НО Я ТАК НИКОГДА НЕ ДЕЛАЮ (как на рисунке) - за это пожизненный эцих с гвоздями.

[HardWareMan]

Однозначно второй вариант. По возможности надо делать так, чтобы все триггеры схемы тактировались одной частотой. Если какие-то части схемы работают на половине или других долях от этой частоты - то следует использовать вход триггеров Clock Enable (CE), описав его на HDL в виде команды if, наподобие твоего второго варианта, для достижения поставленной цели.

Деление тактовой частоты триггером и использование результата для тактирования какой-то части схемы имеет следующие недостатки:
1) Расходуются глобальные тактовые буферы (в примере Spartan6 - BUFG)
2) Поделенная тактовая частота будет из-за задержек элементов схемы и разводки выхода триггера на тактовый буфер и обратно сдвинута по фазе относительно исходной. Эти сдвиги затронут также все сигналы от триггеров, работающих от половины тактовой частоты. Все эти задержки будут отниматься от "бюджета времени" при переходе сигналов данных от триггеров, тактируемых полной тактовой частотой, на триггеры, тактируемые ее половиной, и обратно. В результате будет труднее обеспечить выполнение Timing constraints, снизится максимальная тактовая частота проекта.

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

Он собирается вот так:


Смысл: использование nRD как такты для регистра хранения данных на шине данных гарантирует наличие актуальных данных в самый последний момент, как того гласит датащит. То же самое касается и сэмплирования сигнала TDO у JTAG: его следует синхронизировать именно к результирующему TCK, который по факту выходит наружу.

Ну и в конце концов разные IP могут работать на разных тактовых частотах, чтобы сэкономить несколько регистров и PIA, например. Поэтому, нужно просто подходит с умом и осознанно. С учётом синхронизации сигналов при переходе в другой тактовый домен. Ну а что касается вышеупомянутого асинхронного счётчика то это не для ПЛИС. Забудьте про 555ИЕ5, 555ИЕ10 должен быть ваш выбор.

[Barmaley_m]

имеют всего 32 BUFG (глобального буфера для распределения тактовой).

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

В моем большом проекте использовались следующие крупные области с разной тактовой частотой:
1) Процессор и основная периферия, а также внутренние шины - 80 МГц
2) Спец интерфейс - 960МГц (самые внешние его блоки ISERDES2), а связанная с ними FPGA-логика - 120МГц
3) Ethernet MAC (та его часть, которая непосредственно связана с интерфейсом GMII) - 125МГц
Если бы я использовал интерфейс HDMI - то там бы была еще область 1080МГц (для ISERDES2/OSERDES2). и 135МГц для "нормальной" связанной с этим FPGA-логики.

В том чипе, с которым я работал, частоту выше 80МГц для основной схемы использовать не удавалось - ругался компилятор из-за расхождения Timing Constraints. На относительно высоких частотах в моем проекте (120 и 125МГц) работали только небольшие части всей схемы, где данные частоты были обусловлены требованиями к интерфейсам ввода-вывода.

[Titus]

Не надо только без серьезной необходимости тактировать триггеры разной частотой.

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

[b2m]

Что делать, если выход одного триггера является тактовым сигналом для некоторых последующих участков схемы в данном процессоре.

По CLK защёлкиваем предыдущее значение и формируем сигнал CE логикой: CE = (Q AND NOT Qprev)