Добрый день. Вопрос в следующем. Работаю с Virtex5. Есть два канала данных, и два синхросигнала SCLK и SCLKx2, где SCLKx2 - частота в два раза больше чем у SCLK. Оба синхросигнала получаются с DLL и соотвественно синхронны и, если можно так сказать "синфазны". В схеме есть места, где данные передаются с триггера тактируемого SCLK на триггер, тактируемый SCLKx2 и наоборот. Тут вроде проблем нету. Но оба канала данных обрабатываются либо параллельно, на SCLK, либо последовательно, на SLCKx2. И тут появляется огромное желание сигнал SCLK использовать еще и как логический, т.е. заводить его на Ce триггера или управлять при помощи него мультиплексором. Но чувствую, что можно нарваться. Кто-нить встречал и может дать ссылку на доку, желательно Xilinx-кую, где написано, можно так делать или нет?

Делал я так. Но в качестве CE использовал не сам SCLK, а стробированный SCLKx2.

А вот где почитать, можно ли так делать и что будет на выходе?
В зависимости от того, как DCM выравнит фазы клоков, возможно два варианта соотношения фазы CE и синхросигнала SCLK. А уж если DCM будет заниматься подстройкой в процессе работы (чем она и занимается), и фаза SCLK будет то опережать, то от SCLKx2 (ессно, на величину указанную в спецификации), то возможно, что Ce вообще будет два такта иметь одинаковое значение (будет проскок). Если только задержка при входе на триггер будет больше чем возможное опережение фазы SCLK, тогда можно применить такую схему.

Вы же сами написали:
Вы не находите некоторое противоречие?

Делать так можно, но есть способ, при котором клок не выходит за пределы специально для него сделанных сетей и все части микросхемы и среды разработки используются по назначению.
Смысл заключается в том, чтобы сделать регистр, который бы инвертировался на каждом такте быстрого клока. Тогда он будет менять свой уровень как и медленный клок. Чтобы фаза этого регистра имела связь с фазой медленного клока, нужно начинать инвертировать с привязкой к медленному клоку. Для этого нужен еще один регистр сброса.
Констрейны в этом случае записываются проще и соблюдать их легче.

Убедитесь в надежном соблюдении setup time.

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


Спасибо, от этом я думал. Здесь один недостаток - этот сигнал придется дополнительно таскать по всему кристаллу, и у отдельных узлов делать вход для этого сигнала. Этакое неудобство, но видимо обойти его не удастся.

Правда для совпадения фазы я все-таки по другому сделал. Через триггер, как было предложено выше, только на вход D подал клок с выхода DCM, сдвинутого на 270 градусов.

Фазы Clk1x и Clk2x будут совпадать только на выходе DCМ. Как только вы их протянете через тактовые буферы, появится сдвиг.

Откуда?

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

А еще скажите, какого порядка частота, 500MHz, 50MHz ?
На 50MHz еще как-то можно говорить, что разные клоки на выходе чего-то у FPGA синхронных, а на 500MHz от такой фразы как-то не по себе.

Оттуда, что путь от DCM до буферов разный. Просимулируйте дизайн с реальными задержками и посмотрите на свои клоки.

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

100 и 200 МГц.



На сколько разный? На 1 микрон? Да вы на кристалл-то посмотрите.

Без констрейнов так делать нельзя.

Вот возьмите проект, где вы так делали и тщательно сделайте следующее:
1) в FPGA editor (если это xilinx) проследите сеть медленного клока, где и как он соединяется с входом регистра, который на быстром клоке
2) в анализаторе таймингов посмотрите, какое время распространения клока получилось после того, как вы его подключили к входу данных
3) ужаснитесь содеянному

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

Подключение клока к входам данных затрудяет работу.

Не очень здорово. Т.к. сразу в два раза уменьшаем setup для всех потребителей этого сигнала. Т.е. в моем случае вместо 5 нс, получаем 2.5 (без учета задержек на триггере и линиях связи). Если бы у меня было 10 и 20 МГц - я бы так и сделал. А тут я влетаю в эквивалентную частоту в 400 МГц.

Хотя... Если поставить два триггера последовательно, срабатывающих по разным фронтам.... Надо подумать.

А почему нельзя использовать глобальный SCLKx2, а там где требуется работа на вдвое низкой частоте cформировать соответствующий глобальный enable.

Ну тут две причины.
Первая и очень не маловажная. Хочется использовать уже наработанные схемы, которые не работают на CLKx2. Ну так было спроектировано.
Вторая причина возникает возможно из-за моего неумения задавать ограничения, но при таком проектировании при анализе времянок не учитывается то, что глобальный еnable идет через такт. И в результате, мы должны либо всю схему сделать работоспособной на 200 МГц, либо будем получать ошибки по времянкам.



Посмотрел. Но честно говоря ничего страшного не увидел. Медленный клок приходит все по тем же глобальным линиям, и лишь у самого лута через коммутационную коробочку идет в лут. Также как и быстрый клок. Опасение то как-раз и вызывает то, что задержки дополнительной не будет. Была бы она хотя бы в 1 нс, можно было бы жить наверное.

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

Нарваться можно "только в путь". По идеи должна быть аппаратно в самой структуре ПЛИС заложена возможность динамического мультиплексирования клоков.

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

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


Речь не идет о мультиплексировании клоков. Речь идет о заведении клока на вход данных.



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

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

А кто сказал что они плохие?
Вот констрейны соответствующие изучить - это надо. Только вот не нашел таких

Клок перестанет быть глобальным сигналом после такой операции.

Почему?

Да, multi-cycle задаётся через него.

Ну спуститесь по иерархии вниз до нужного блока. Если сигнал переименован, повесьте на него KEEP.

Из-за аппаратной реализации ПЛИС. Правда, 100% не берусь утверждать на счёт ПЛИС Virtex. Но проверьте лишний раз.

Xilinx-ISE-Documentation-Software Manuals
Constraints guide
ctrl+F "multi cycle path"

Пример .UCF файла для приемной части hypertransport 400MHz:


Вам нужно будет определить два клока, задать их частоты, как ts_rx_clk_0 у меня.
Определить 2 группы и задать ограничения по времени между двумя группами.
Отдельно описать сигнал clock enable.
Если использовать DCM, то достаточно описать сигнал, который поступает на вход DCM, дальше ISE сам все поймет, как вы его там умножали, делили и сдвигали.

Насколько я понимаю контролировать частоту работы схем через enable это вроде золотое правило.


Я честно сказать в констрейнах тоже не разбираюсь, но вот что-то есть у ксайлинкса по этому поводу:

http://www.xilinx.com/itp/xilinx4/data/doc.../strategy2.html

Multi-Cycle Paths Assignments

You can specify multi-cycle path assignments by identifying the start point and end point groups and then applying a FROM TO constraint for that path. For elements controlled by clock enables, use a TNM_NET on the clock enable to identify all of the elements. You can specify timing requirements as a function of the clock. Be aware of your specified units on the originating TSid. If in "MHz", "*" used as multiplication will make the new clock specification faster, if in "ns", "*" will make new clock specification slower.

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

Эх... Это мы с вами понимаем..

К сожалению (еще раз повторюсь) FROM TO может быть использован только в UCF файле. Я разрабатываю узел, который должен
иметь возможность использоваться во многих проектах. Все входные и выходные данные тактируются 100 МГц. Другого не дано по определению. 200 МГц заводится дополнительно. К сожалению, даже если я повешу KEEP на enable, могу сказать почти на 100%, другой человек в своем проекте это ограничение в UCF не внесет, пока не помучается с времянками. К сожалению многие разработчики умеют только задавать период синхросигнала.

Ну и поставьте dual clock fifo между доменами. Будет дорого, универсально и надежно. На любые подходящие частоты. Возможно, даже экономичнее по питанию, если какую-то частоту можно уменьшить.
Мы-то знаем, что можно было сделать лучше, но когда большая толпа своими ручонками лезет в проект не желая вдаваться в подробности,
то кто-то за это будет платить. Конечный потребитель или тот один, кто собирает верхний уровень проекта.

Кстати вопрос, а DCM на каком уровне иерархии возникает? Кто его входной сигнал констрейнами описывает?

DCM возникает уже на верхнем уровне. Пользователю дается два входа синхросигнала. И он их должен будет подключить.
А вот ФИФошки поставить - не лучшая идея. Т.к узел состоит из множества других узлов, интерфейс у которых тоже должен быть 100 мегагерцовым.
Да и еще раз повторюсь, проблем с переходом между доменами нет.

Так это вроде проблема многих разработчиков, а не ваша. У Xilinx например есть немало корок, которые не заработают, если не взять от них UCF.

Ну в общем ответ на свой вопрос я получил.
В лоб заводить клок на вход данных нельзя. Правильное у меня ощущение было.
Всем участникам - спасибо!

Опа, нате-здрасте.
Почему же нельзя? Я во всей теме, причин почему нельзя, не увидел. Не стоит - это да, но почему нельзя?
Фазовые соотношение между клоками известны. Следовательно P&R должен соблюсти сетапы/холды. К тому же это требуется только на переходе между доменами.

- эти ягоды есть можно?
- можно... только отравишься.

Да конечно можно.
Можно констрейны не записывать, а так, отсчитать 90 градусов клока, прикинуть сколько это в nS, проверить по документации, что успевать должно. Работать будет годами, ну, если правильно прикинуть. Вопрос ведь в том, что есть методы не более сложные, но существенно более качественные и универсальные.

PS: распространение асинхронного сброса еще не рассматривали.

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