Давно хотел спросить, но как-то руки не доходили...

Вот есть некие сигналы внутри ПЛИС (пусть для определенности какая-нибудь FPGA типа Cyclone от Altera):



Задача вывести поток данных наружу на внешнее устройство: выходит шина данных (data) и сигнал тактовой частоты (clock). Есть требование, чтобы clock был сдвинут по фазе относительно данных - задержан, т.е. чтобы на том внешнем устройстве выполнялись требования по setup.

До сих пор задача успешно решалась так: в PLL заводилось два клока - один системный (например, 100 МГц), второй вспомогательный (200 МГц), сдвинутый относительно системного на четверть периода (2.5 нс). Данные выходят наружу через выходные триггеры IO элементов ПЛИС, которые тактируются системным клоком, а clock выходит наружу тоже через выходной триггер IO элемента, но подается он на вход данных триггера, а тактируется этот триггер вышеуказанным вспомогательным высокочастотным клоком, сдвинутым на 2.5 нс. Таким образом, на выходе получаются данные и клок без перекосов и с четко выдержанной времянкой. Все это работает.

Но есть сомнение. Как-то все это кажется сложновато и некрасиво - есть подозрение, что можно вывести клок с заданной задержкой без всяких подобных наворотов, а просто обконстрейнив. На "некрасивость" еще указывает то, что квартус на этот финт выдает предупреждение:

Warning: PLL "ClkGen|pllclkgen:PLLClkGen|altpll:altpll_component|pll" output port clk[0] feeds output pin "SCLK" via non-dedicated routing -- jitter performance depends on switching rate of other design elements. Use PLL dedicated clock outputs to ensure jitter performance

Понятно, что страшного ничего нет, но нехорошо.

Какие мнения? Как делать правильно?

Ну, например, вывести клок наружу через dedicated output c CLK0, а недра затактировать с CLK1, задав в параметрах PLL нужные фазовые взаимоотношения между ними... Как-то так. По крайней мере варнинг умрет.

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

Еще вариант - не размещать выхонные сигнады в триггеры IO и просто задать констрейны задержек от внутренних регистров до пинов. Что скажете?

P.S. Там есть еще одно мелкое обстоятельсво - поток выходной нерегулярный, есть паузы, когда все стоит (и данные, и клок, управляется по внутреннему сигналу разрешения), если выводить клок на dedicated pin, то с такой блокировкой видятся трудности.

Тогда Ваш вариант, и других вариантов пожалуй нет. Если мудрить констрейнами, то квартус начнет вытягивать времянки путем расставления буферов и удлинения разводки, а это, мягко говоря, фигня. Ну или выходной клок формировать тоже IO-триггером, тактируемым отдельным внутренним клоком, в два раза более быстрым, чем выходной клок. И не говорить квартусу (да он и не поймет), что этот выход - клок.

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

Т.к. я работал только с Xilinx FPGA, то и нижеперечисленные подходы ориентированы на ресурсы присущие Xilinx FPGA. Думаю в FPGA, есть только 2 варианта создания гарантированного временного сдвига между сигналами:
1. Если есть возможность, то использовать фазосдвигатели в PLL/DCM. В крайнем случае, если есть элементы задержки во входном буфере CLK, то можно используя их получить 2 ветви CLK разведенных во времени (но в этом случае, хоть и в слабой форме, уже будут иметь место все вышеперечисленных зависимости от температуры и т.д.).
2. Работать на очень большой частоте внутри ПЛИС, и выходные сигналы формировать по различным фронтам этого высокочастотного clock (например: по 1 положительному фронту выставлять данные, по 1 отрицательному - clock, затем подождать несколько тактов и продолжить всё с начала) - но этот подход работает только для низкочастотных интерфейсов.

В FPGA от XILINX очень удобно использовать блоки DCM - Digital Clock Manager. Блоки PLL (DLL), входящие в их состав, выдают 4 клока, сдвинутых между собой на 90 градусов. Таким образом, используя подходящий клок, можно получить нужные задержки. Кроме того, если не ошибаюсь, можно также задавать задержку между входным и выходным клоком, используя параметры CLKOUT_PHASE_SHIFT и PHASE_SHIFT. Вероятно, нечто похожее есть и у Альтеры.

Интересно если в альтере это диствительно есть? Написана программа - которая выводит данные .Требования вывести те же данные, но с другого места с задеркой. есть ли смысл писать программу для задержки или есть ещё какие то способы

Не кажется Вам, что перемудрили?
Сравните полученный для FPGA Tco и требуемый Tsu...
Если Tclk - Tco > Tsu - то и не каких проблем быть не должно (Tclk - период тактовой)

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

Интересно, а чем плохо просто из PLL вытащить два клока 100 МГц и 100 МГц, сдвинутые на четверть периода. Первый тактирует выходные D-триггеры, а второй тупо наружу?
Или расчет строится на то, что при тактировании триггеров разными клоками компилятор разместит их в глобальных шинах и задержка там будет минимальна, т.е. лишенго сдвига по времени не будет (при условии одинаковых выходных триггеров и самое главное одинаковых нагрузочных емкостей)?

dxp, правильно вам quartus наругался, клок ходит по проводам, которые для данных предназначены. И неприятность этого заключается не только в разбеге фаз и зависимости от условий. Так как клок покидает глобальную сеть, P&R и STA начинают учитывать не только глобальную сеть клока, но и "отросток", который идет к выходным буфферам. В результате, в узких местах будет надублирована логика, что увеличит площадь, что еще ухудшит разводку и еще надублируется логика. Если действительно узко, CRC какой-нибудь.

Чтобы избавиться от отростка при формировании выходного клока, можно применить трюк:
Что у вас есть - два клока с гарантированным PLL-ем сдвигом фаз и готовые констрейны о нем - о них заботятся quartus или ISE.
Предполагается, что сдвиг не слишком маленький, чтобы были трудности при передаче данных из регистра в регистр в разных доменах. На VHDL этого примерно так, а вы уложитесь в пару строк:


Если знать ограничения на сигналы, да сопоставить их с температурой и напряжением, то допустимых некрасивых решений может оказаться много. В таких случаях интересно делать тупо, то есть, сначала рассмотреть решение, которое приводит к минимальным зависимостям от внеших условий и разводки. Например, как писал во втором пункте Boris_TS, задрать частоту.
Частота умножается в два раза в PLL (DCM), выход подается на буффер глобальной сети клока и оттуда поступает к тактовым входам выходных буфферов и выходного клока, и данных. Выходной клок формируется как данные (смотри выше), а не берется с выхода PLL и тем более не проходит напрямую к ножке. Чтобы не тратить зря логику, нужно сделать clock enable для основной части схемы. А чтобы не греть напрасно все вокруг, надо постараться сделать этот clock enable на глобальном буффере клока. В идеале, клок из PLL идет на два глобальных буффера, один для вывода, другой для остальной схемы. В VirtexII-pro я HyperTransport так делал, там клок тоже на 90 градусов сдвинут, ввод/вывод у меня работал на 400 MHz, а основная схема на 200MHz.

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

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

Честно говоря, не понял вашего замечания. Не могли бы вы уточнить, что имелось в виду. Напомню, у меня есть данные и клок, клок должен быть сдвинут (задержан) относительно данных, я реализую это путем размещения выходного регистра данных в триггерах IO элементов ПЛИС, а клок тоже в таком же триггере IO элемента, но подаю его на вход данных (не на тактовый), а на тактовый вход этого триггера подаю вдвое более быстрый клок, сдвинутый на четверть периода основого клока (2.5 нс в моем случае). Таким образом, на выходе четко и гарантировано присутствуют данные с малым "перекосом" и клок, сдвинутый четко на указанную величину.


Такая мысль тоже посещала, но взяло сомнение насчет временных соотношений. Ведь в случае пропускания клока через триггер выходного элемента имеем четкое соотношение в виду жесткой связности клоков. А тут если просто на выход клок метнуть, кто гарантирует, что он выйдет с четкой задержкой относительно данных, протактированных вторым клоком (ловим-то ведь единицы и доли наносекунд)? Ведь у него совершенно другой путь наружу в отличие от варианта с тактированием клока другим - сдвинутым высокочастотным.

К тому же, преимуществ никаких все равно не видно - все та же возня с клоками - их надо два, надо сдвиг, т.е. все упирается в наличие соответсвующей аппаратной приблуды (PLL).


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


Это что, весь этот наворот только для того, чтобы вывести сигнал клока в разряд данных?


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

господа, я что то не понимаю или как. что мешает вывести комбинаторно ИНВЕРТИРОВАННЫЙ клок? Не нужны никакие дополнительные выходы PLL, усложнение логики(удвоение системного клока) и т.д. и т.п. Если есть DDRIO то "проблема" вообще решается тривиально и просто(даже warning не будет), на виртуальном инверторе. В этом случае фронт клока будет стоять в середине окна данных и принять его можно будет без проблем.

Проверено на многих ФПГА, для частот до 180 МГц, работает без нареканий.


PS. правда при этом разводка на плате сделана с выравниваем длин шины.

++
Всегда так делали, правда, не на сотнях МГц, но суть от этого не меняется.
Разве только речь идёт о DDR, которая по обоим фронтам работает

А вы знаете, какие временные соотношения будут в сигналов в том случае? Вот клок фиксирует сигнал данных в триггере IO элемента, далее сигнал через время Tco выходит из триггера и следует до выходного пина через всякие мультиплексоры, элементы задержки, минуя трехстабильный буфер и т.д. Это тоже вносит задержку. Экспериментально для циклонов это время составляет порядка 2.2 нс. Так вот вопрос: а вот этот самый клок, которым такировали вышеописанный триггер, если его пустить тупо напрямую на внешний пин, - какая у него будет задержка? Ведь у него-то путь совсем другой. Начиная с того, что он идет со слоя глобальных сигналов, и заканчивая тем, что он идет мимо триггера.

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


Т.е. если данные выводить точно на DQ, а клок на DQS? Ну, так это привязка к конкретным пинам, чего бы не очень хотелось, вообще-то.

насколько другой путь будет у цепи клока ? особенно по времени ? он пройдет почти те же самые цепи, за исключением выходного триггера. и задержка будет отличаться где то на 0.2-0.5 нс, что при запасе влево-вправо в 5нс (данные на 100МГц) вам это более чем за глаза. А поднять тактовую с глобальной линии и вывести ее на LUT/IO буфер можно в любом месте. И ква поднимает его по месту, а не где то вначале у PLL. В температуре плыть задержки у клока и данных будут в ту же самую сторону, так что и тут я проблем не вижу.



вам никто не мешает использовать возможности Time Quest который умеет анализировать Clock as Data и прописать диапазоны задержек.



у хилых я делал так

А я что-то запутался. А откуда квартус знает, что выход триггера это клок? Ему и на вход данных что-ли клок приходит? Так это глюк идейный.

да, dxp поднимает с глобальной линии клок и нарезает его в IO ячейке на клоке в 2 раза выше со сдвигом по фазе %)

В ваших рассуждениях есть логика. Осталось еще реализовать функцию clk_en (для клока и для данных - поток данных нерегулярный, в нем есть паузы). Если сделать просто тупо на логике (clock & clk_en), то эта логика будет размещена во внутренней ячейке ПЛИС, и оттуда до IO элемента время доставки сигнала уже не 0.2-0.5 нс и, соответсвенно, этот сигнал уже будет иметь иную (возможно, неприемлемую) задержку.





А вы как понимали до этого? И как правильно с вашей точки зрения?

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

В чем криминал, если подать клок на вход данных триггера? Почему его нельзя просто использовать, например, как сигнал частоты 100 МГц?

Я в подобной ситуации (дело давно было - уже не вспомню, уже на ACEX1K или ещё на FLEX8000) сделал так -
"ну и пусть себе на выходе изменения данных болтаются около фронта такта"
Такт восстанавливался, но не как у Shtirlits - мне было проще, так как передача шла на половине основного тактирования и в качестве выходного такта просто ena триггеров данных пропускался через триггер. В этих условиях очень просто было сделать и жёстко стоящий инвертированный такт, но мне это не нравилось, так как по дороге были ещё разные набегания, размножение сигналов через шинники на кучку принимающих товарищей на MAX-ах, и я не хотел сокращать вдвое окно.
В итоге я просто на приёме пропустил линии данных через latch, тактируемый этим же пришедшим вместе с ними clk (всё принимающее устройство от этого тактирования работало)
Т.е. на приёме данных/команд стояла цепочка LATCH + DFF, тактируемые приходящим clk. Выходила дополнительная конвейерная задержка в один такт, но она меня не волновала.
В данном случае прерываемого такта это надо учесть, в том числе выдачей "лишнего" тактового импульса в конце.

У ксалинса в ДДР было сделано так: выход клока заводился снова в ПЛИС, и от него синхронизировался выход данных. При этом на DCM можно задавать нужную задержку, а не только данные в центр клока ставить. И все это работает со стандартными констрейнами offset out. Т.е. проверяется автоматически, не нужно думать попадают данные в окно или нет при изменении в проекте. И заморочек с удвоенной частотой нет. А потом в ксалинксе научили MIG делать автокалибровку и эти заморочки не потребовались.
Ну по рисунку все понятно.

Ага. Целых 2 или 3 регистра.


Есть, вы им воспользовались. Но нужно иметь в виду, что клок и данные им тактируемые не сдвинуты на время срабатывания регистров. Сначала случается фронт клока, а потом фронт данных вызванный фронтом клока. На 10MHz это не важно, на 500 может помешать.

DXP, у вас все хорошо, на warning можно забить, но в жертву перфекционизму можно принести перевод тактирования всех выходных регистров на тот же клок, которым вы тактируете выход клока.

Вот это замечание хорошенько не понял. Сначала случается фронт клока (основного, системного, который у меня 100 МГц), потом случает фронт данных на выходе триггеров, а сам клок (его уровень) в это время присутствует на входе данных другого триггера (тоже в IO элементе), который тактируется другим клоком (200 МГц, сдвинутым на 90 градусов - 2.5 нс - относительного основного), и после фронта этого 200 МГц клока сам клок вываливается наружу уже как сигнал данных, пройдя по тому же пути, что и остальные данные (в своих элементах, понятно). Поэтому временнЫе соотношения снаружи между данными и клоком получаются четкими и не зависят от частот. Насколько я понимаю (и по скопу, вроде, тоже все стоит, как вкопанное). Как тут может сказываться влияние частоты хоть 10 МГц, хоть 500 МГц?

В данном случае то, что клок чуть раньше данных только "лучше". Я имел в виду вообще неприятности от использование клока как данных на больших частотах.

Я тоже думал, что 200 МГц делятся на два
Может шутка?



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

Я имел в виду, что когда активный фронт приходит к регистру, данные на его выходе изменятся позже. А это значит, что фронты данных и клока будут несовпадать, совсем немного.
Тут имеет место быть путаница в терминологии. Клок схемы и клок на выходе называется одинаково клоком
Если бы сдвиг был на полпериода, то было б проще. Но тут DDR, клок сдвинут на 90 градусов.

По идее ничем, кроме совершенно непонятно чем определяемым фазовым сдвигом (где есть выходы из дерева? А может из дерева выходов нет вообще, и он от источника по разводке идет...) Ну и Warning светится.

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

Несколько странно, что не предусмотрено какого-нить специального буфера для вывода сигналов из сегмента клоков в сегмент данных, чтобы не приходилось вот так финтить. Кстати, времянка получается достаточно напряженная - от второго триггера, который по negedge clk щелкает, до clk200 (который сдвинут относительно clk на 2.5 нс - 90 градусов) - всего 2.5 нс, и тут уже напряги возникают, если применять дополнительную логику типа разрешения клока.