[des00 25]

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

 

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

 

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

 

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

 

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

 

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

 

ODDR
ODDR
(
  .Q  ( clk_pin ), // 1-bit DDR output data
  .C  ( clk     ), // 1-bit clock input
  .CE ( 1'b1    ), // 1-bit clock enable input
  // this is virtual inverter 
  .D0 ( 1'b0    ), // 1-bit data input
  .D1 ( 1'b1    ), // 1-bit data input
  //
  .R  ( 1'b0    ), // 1-bit reset input
  .S  ( 1'b0    )  // 1-bit set input
);

[SM 0]

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

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

[des00 25]

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

 

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

[dxp 50]

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

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

 

 

 

 

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

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

[SM 0]

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

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

[dxp 50]

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

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

[ReAl 0]

И вообще это сильно попахивает асинхронщиной. :)

Я в подобной ситуации (дело давно было - уже не вспомню, уже на ACEX1K или ещё на FLEX8000) сделал так -

"ну и пусть себе на выходе изменения данных болтаются около фронта такта"

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

В итоге я просто на приёме пропустил линии данных через latch, тактируемый этим же пришедшим вместе с ними clk (всё принимающее устройство от этого тактирования работало)

Т.е. на приёме данных/команд стояла цепочка LATCH + DFF, тактируемые приходящим clk. Выходила дополнительная конвейерная задержка в один такт, но она меня не волновала.

В данном случае прерываемого такта это надо учесть, в том числе выдачей "лишнего" тактового импульса в конце.

[disel 0]

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

Ну по рисунку все понятно.

[Shtirlits 0]

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

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

 

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

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

 

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

[dxp 50]

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

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

[Shtirlits 0]

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

[Andr2I 0]

Цитата(SM @ Jun 22 2009, 14:32)

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

 

 

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

 

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

Может шутка?

 

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

 

Видно я тупой совсем - почему это клок должен быть раньше появления данных? :laughing:

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

[Shtirlits 0]

...почему это клок должен быть раньше появления данных...

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

Тут имеет место быть путаница в терминологии. Клок схемы и клок на выходе называется одинаково клоком :)

Если бы сдвиг был на полпериода, то было б проще. Но тут DDR, клок сдвинут на 90 градусов.

[SM 0]

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

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

[dxp 50]

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

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

 

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