[Muscat 0]

Вопрос вот какой.

 

В простом случае все триггеры работают от одного клока, например

if (clk'event and clk='1') then
......

if (clk'event and clk='0') then
.......

 

Я в своем проекте использую следующую конструкцию

 

То есть в одном процессе (FSM) генерится сигнал

if (clk'event and clk='1') then
.... READ<='1'

А в другом процессе по фронту этого сигнала происходит чтение

if (READ'event and READ='1') then
....

 

1) Чем черевато такое решение? Можно ли его применять, или лучше уходить от него, тактируя все по клокам, созданным на PLL, а сигнал READ Использовать как флаг разрешения?

2) Если делать так, то как указать синтезатору, что этот сигнал является тактовым и чтобы он учитывал его при составлении отчета о задержках?

3) Я какую то ерунду спросил?

[AJIEKCEu 0]

1. Чревато это в частности гонками - по сути в вашей схеме сложно сказать какой сигнал придет раньше - результат работы комбинационной логики или "псевдосинхросигнал". Однозначно лучше уходить от такого варианта (по крайней мере если вы не супер-гуру - точно).

2. Подозреваю что он сам догадается. А в случае XIlinx'a - ещё и напишет, что такое подключение не рекомендуется.

3. Да в общем нет, просто новичковый вопрос как мне кажется.

[Muscat 0]

Сам не догадался, синтезатор Synplify PRO D-2009.

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

[AJIEKCEu 0]

Сам не догадался, синтезатор Synplify PRO D-2009.

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

У вас теряется понятие такта в данном случае. В том смысле, что сравнивать надо уже не время работы схемы с моментом прихода следующего синхросигнала, а время работы комбинационной схемы со временем распространения сигнала с ножки Q4 триггера (не подписан сигнал). Поэтому если так уж сильно хочется - надо накладывать ограничения на время распространения от Q1 до входа данных другого триггера, и от Q4 до клокового входа триггера.

Но как мне кажется много проще сделать как правильно и забыть.

 

А встречный вопрос можно? Зачем вам именно такая схема? Чем не устраивает синхронная + CLK_EN?

[Muscat 0]

Хотелось сэкономить такты.

По переднему фронту генерируется сигнал считыванияl, по заднему читается на следующих триггерах.

 

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

[AJIEKCEu 0]

Хотелось сэкономить такты.

Не совсем понял... А что мешает после вашей логики поставить триггер с работой по заднему фронту и разрешением по Q4?

[des00 27]

Да и в книгах не встречал упоминания, что это плохой вариант.

вариант нормальный, но временной бюджет в 2 раза меньше

 

[Muscat 0]

Уже и сам понимаю, что толку нет от такого варианта. Буду переделывать.

 

То есть? Не понял про временной бюджет?

 

Попутный вопрос, связанный с клоками.

Не совсем понимаю, что такое Constraints. Это указания синтезатору, для каких частот следует оптимизировать проект?

[Kompot 0]

1) Чем черевато такое решение? Можно ли его применять, или лучше уходить от него, тактируя все по клокам, созданным на PLL, а сигнал READ Использовать как флаг разрешения?

 

Есть еще один нюанс. Глобальных клоков - мало. И распространяются они по особым выделенным линиям. Очень быстро. То есть с малой задержкой.

 

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

[Muscat 0]

Kompot, о! Теперь все совсем понятно стало. Спасибо!

[dxp 211]

вариант нормальный

ИМХО, не очень нормальный. Выходному сигналу, который используется в качестве клока, придётся переползти из домена сигналов в домен клоков, т.е. через аппаратные коммутации, которые, в общем-то, в ПЛИС для этого не предназначены. Это не считая того, что в самом домене сигналов задержки распространения тоже очень сильно варьируются от пути прохождения, температуры, конкретного кристалла и т.п. И это даёт непрогнозируемую задержку. Квартус на такие приёмы выдаёт предупреждение что-то типа, что сигнал проходит via non-dedicated path и jitter performance будет в дауне.

 

И главное - зачем так делать, если во всех современных ПЛИС в триггерах есть clk_en?

 

но временной бюджет в 2 раза меньше

Почему в два?

[des00 27]

вариант нормальный

слово про нормальность относилось к фразе про многофазную синхронизацию от одной тактовой. Инвертор тактовой находится у каждого триггера.

Почему в два?

это относилось тоже к многофазной синхронизации от одной тактовой.

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

Если говорить про использование логических сигналов как сигналов тактовой частоты, от если мне память не изменяет, тактовый вход триггеров у тех же сыклонов допускает коммутацию любого сигнала, а не только глобального. На сыклонах 1 сам пользовался этим (подавал тактовые не на глобальные линии).

 

 

[Muscat 0]

Продолжение вопроса

 

У меня есть буферы, но некоторые должны работать по переднему фронту, а какие то по заднему. Что сделать?

 

1) Описать 2 буфера, в 1 конструкция clk'event and clk='1', в другом clk='0'

2) Затолкать во второй сигнал not_clk<=not(clk)

 

Я так понимаю, что второй вариант лучше? Как бы покрасивее тогда сделать это в едином компоненте, чтобы фронт работы задавался через конфигурационную переменную generic?

Вариант, который вижу - описать внутри entity 2 процесса тактирования, по переднему и по заднему фронту, а на выход подавать выход только одного из них, по выбору переменной, тогда синтезатор сам выкинет неиспользуемый. Нормальный ход?

[des00 27]

Я так понимаю, что второй вариант лучше? Как бы покрасивее тогда сделать это в едином компоненте, чтобы фронт работы задавался через конфигурационную переменную generic?

лучше в компоненте этого не делать.

 

[Muscat 0]

Очень содержательный ответ :-)

 

А как лучше делать, если нужны буферы по переднему и по заднему?