[topor_topor 0]

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

может стоит внимательнее читать вопрос?

 

но даже с одним клоком

представьте что clk - 1 МГц, а снаружи данные ждет проц гигагерцовый. И что опять жмем зеленую кнопку?

Или все таки надо как-то управлять временем между тем как увидели 1 на выходе out_data_valid и тем как можно забрать готовые данные с out_data?

 

 

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

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

1) Помоему мы обсуждали только это:

 

always@(posedge clk)
     begin
         TheReg1 <= SomeFunction(TheReg1); //какие то действия, результат которых зависит от состояния TheReg1 
         TheReg2 <= SomeFunction(); //какие то действия, результат которых Не зависит от состояния TheReg2 
     end

и вотэто:

always @(posedge clk)
begin
   TheReg2 <= nReg1 ^ nReg2 & nReg3 * nReg4 - nReg5 ....  + nRegN;
end

Тут - зелёная кнопка (т.е неявные дефолтные констрейны) и никаких доменов.

-------------------------------------

2) Вот это:

always @(posedge clk1)
begin
    if(cond)
      begin
        RegCLK1 <= .....;  
        DataRDY <= 1;
      end
end

always @(posedge clk2)
begin
    RegCLK2 <= RegCLK1; 
end

 

...особенно когда clk1=1МГц, а clk2=1ГГц и они не связаны (делителем или ФАПЧ и фазы сдвигаются, как вы правильно заметели)

Работать не будет.

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

 

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

Как и констрейна, который выдаёт/получает данные с заданной задержкой относительно эджа внешнего асинхронного клока

 

В этой ситуации констрейн один: set_false_path -from clk1 -to clk2 и наоборот.

Схема дорлжна обеспечивать работоспособность при этом, за счёт физики.

 

----

4) пропустите вы ваши злощастные DataRDY через синхронизаторы на стороне приёмника и будет всё ОК.

[Golikov 0]

Ок. Значит я вас не понял, простите. По поводу 1 я считал что уже все выяснили.

 

2) Тут есть особенность, может быть какое угодно соотношение, изначально clk2 меньше clk1, но это я думал мало поможет.

 

Гораздо важнее что clk2 идет не всегда, а появляется по случаю, когда надо.

И тут

set_false_path -from clk1 -to clk2

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

RegCLK1 принимает значение и вместе с ним DataRDY становиться 1.

Это видит внешнее устройство и создает clk2.

И тут важно чтобы данные с выход RegCLK1 дошли до входа RegCLK2 не позже чем внешнее устройство увидит DataRDY.

Тогда все сработает правильно. И вот это время хочется, да более того надо, определить и обконстраинить.

То есть надо определить путь RegCLK1 -> RegCLK2, а для пуще определенности хорошо бы еще DataRDY определить.

 

 

4) Вот тут совсем не поможет

пропустите вы ваши злощастные DataRDY через синхронизаторы на стороне приёмника и будет всё ОК.

 

события

 

RegCLK1 <= .....;

DataRDY <= 1;

 

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

 

кстати про клоки интересно

у меня clk1 описан период 10 нС

а для clk2 описан период 20 нС

для 2 еще заданы сетапы и холды.

Ни какой связи или отсутствия связи явно не описано, неужели синтезатор считает их связанными, и учитывает кратность периода в своих расчетах?

 

[SM 15]

события

 

RegCLK1 <= .....;

DataRDY <= 1;

 

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

Если DataRDY пропущен через два триггера, а RegCLK1 - нет, то, скорее всего, при любых раскладах, когда RDY пройдет через 2 триггера, то все выходы от RegCLK1 уже давно "устаканятся", и их можно будет защелкивать без синхронизаторов во втором домене. Конечно, смотря какой клок у этих 2 триггеров, но, скорее всего, этого хватит на любой, даже самый плохой расклад разводки RegCLK1. Но, можно и обконстрейнить RegCLK1->другой_домен на max_delay на 1 период clk2, если клок clk2 дюже быстр.

 

Ни какой связи или отсутствия связи явно не описано, неужели синтезатор считает их связанными, и учитывает кратность периода в своих расчетах?

Это отчеты STA смотрите. Част сред по умолчанию все клоки считает связанными с начальным сдвогом фаз 0, а часть сред - несвязанными.

[topor_topor 0]

Гораздо важнее что clk2 идет не всегда, а появляется по случаю, когда надо.

 

Чем дальше в лес - тем больше дров...

Оказывается clk2 не бесконечный меандр, а импульс, который гарантировано появляется КОГДА НАДО.

Пусть тогда clk2 появится когда данные с clk1 домена точно дошли :)

 

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

[Golikov 0]

да я уже несколько раз описал.

clk2 не импульс, а клок включаемый когда надо, самый простой пример клок SPI мастера.

 

Пусть тогда clk2 появится когда данные с clk1 домена точно дошли

Пусть, я всеми руками за! И вот тут вопрос когда это пусть наступает? Именно об этом и беседуем.

 

Я себе вижу что без фиксации времени движения сигнала от RegCLK1 до RegCLK2 ничего определенно сказать нельзя.

Так же я себе вижу что без фиксации времени RegCLK2 - до наружной ножки, опять же ничего определенно сказать нельзя

 

 

 

[SM 15]

Я себе вижу что без фиксации времени движения сигнала от RegCLK1 до RegCLK2 ничего определенно сказать нельзя.

Так же я себе вижу что без фиксации времени RegCLK2 - до наружной ножки, опять же ничего определенно сказать нельзя

 

"я себе вижу" - это сильно :)

 

вот конкретный пример, в цифрах:

 

Domain1 - клок 125 МГц (пусть даже останавливающийся, пофигу, сформировал данные и Rdy, и встал)

Domain2 - клок 20 МГц (непрерывный)

 

данные идут Reg(Domain1) -> Domain2, сигнал готовности RegRdy(Domain1)->Sync_FF1(Domain2)->Sync_FF2(Domain2)->Domain2

 

При этом, имеется 100% гарантия, что при любых раскладах разводчика, даже самых шизофренических, к моменту прихода сигнала Rdy в Domain2, данные, без каких либо констрейнов, к этому времени будут стабильны и готовы к приему в Domain2, и никаких констрейнов на этом переходе не надо.

[Golikov 0]

Domain1 - клок 125 МГц

Domain2 - клок 250 МГц

а так?

 

откуда 100% гарантия? просто потому что это пипец долго? Все же хочется в цифрах... Ну главное что уже же определились 100500 раз, надо прописать констрайники 3 штуки и все, к чему экстрим то? пусть железка проконтролирует и скажет, да все ок!

 

выход ноги относительно клока

выход другой ноги относительно клока

время пути от регистра к регистру - вот с этим пока сложности, чет пока не понял как правильно это сделать.

 

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

[SM 15]

откуда 100% гарантия? просто потому что это пипец долго?

Из даташита. Из расчета, что дорожку более, чем один круг вокруг всего кристалла разводчик физически намотать не сможет.

 

А с констрейнами, еще попаритесь не раз, когда set_false_path для интер-клок-домена начнет отменять set_max_delay для этого же пути. Чаще (но не всегда) значительно проще построить схему так, что она будет работать и в худшем случае разводки, и в лучшем, чем воевать с констрейнами на переходе.

[Golikov 0]

блин я в сметенье...

 

у меня сейчас так

клок SPI 50 МГц, основной 100 МГц.

что я даю клок SPI не раньше 2-4 тактов после сигнала. Сбоев нет, все зашибись, но внутренне мне кажется - это какая-то халтура... То есть на то чтобы данные дошли из регистра под 1 клоком до регистра защелкиваемого по 2 клоку, я даю не менее 3 тактов. И так же на то чтобы заметить сигнал схемой и перейти в боевой режим опять же даю ей 3-4 такта... И это наверняка при всех раскладах будет всегда ок.

 

Но не оставляет чувство что это как-то не профессионально... что взрослые дяди так не делают...

 

[SM 15]

Я вообще не понимаю, если Вы сами формируете этот SPI клок (а как иначе понять, что даете 2-4 такта от поступления данных и до SPI клока? Значит он не внешний, раз Вы этим управляете!), то следует просто описать зависимость SPI клока от основного клока, и все констрейны на переходе сами обконстрейнятся.

 

Реально, надобность в констрейне определяется из конкретных условий - скорости ПЛИС, тактовых, задержек, и пр. Если там запас в разы при худшей разводке - то констрейн не нужен. Если нет запаса - то нужен.

[topor_topor 0]

Я себе вижу что без фиксации времени движения сигнала от RegCLK1 до RegCLK2 ничего определенно сказать нельзя.

Так же я себе вижу что без фиксации времени RegCLK2 - до наружной ножки, опять же ничего определенно сказать нельзя

с clk2 ничего не понял, нуда ладно....

 

"фиксации времени движения сигнала от RegCLK1 до RegCLK2 " если это внутри одного FPGA то смотрим тайминг репорт и видим это время

от регистра А к регистру Б и "появляем " clk2 когда надо

"RegCLK2 - до наружной ножки" - set_output_delay, если дефолтное время не устраивает

 

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

все остальные ваши вопросы - это по основам STA (как оно работает)

 

Реально, надобность в констрейне определяется из конкретных условий - скорости ПЛИС, тактовых, задержек, и пр. Если там запас в разы при худшей разводке - то констрейн не нужен. Если нет запаса - то нужен.

Констрейны надо всегда.

Если ничего не задавать, то и выполняться ничего не будет.

Другое дело, что неявно они всётаки заданы и установлены в дефолтные значения.

 

 

[Golikov 0]

Есть синхронизирующие сигналы

ПЛИС готова передать данные, она дает сигнал - данные готовы для внешней схемы

Внешней схеме нужны данные, она дает сигнал - мне нужны данные для ПЛИС

 

После этих сигналов с некоторой задержкой внешняя схема формирует clk2, по которому данные следуют туда или обратно. Задержка нужна для того чтобы ПЛИС успела понять что получила сигнал и успела выставить данные. Весь вопрос величины этой некоторой задержки. Я не могу описать clk2 относительно клока ПЛИС, потому что формируется он внешним устройством, фаза неизвестна ни разу. Могу только делать гарантированную задержку.

 

И меня не оставляет ощущение что надо эту задержку поддержать и со стороны ПЛИС. Я считаю не правильным все время проверять в отчете что получилось, надо чтобы если не получиться чтобы синтезатор-имплементатор-рутер сказали, ай ай ай констраин не вышел!

 

 

[ViKo 0]

Golikov A. - вам нужно обязательно прочитать тот самый "TimeQuest User Guide" от (по версии SM - укуренного индуса) Ryan Scoville.

 

http://www.alterawiki.com/wiki/File:TimeQuest_User_Guide.pdf

жаль, не дописал

[Golikov 0]

Спасибо, попробую....

 

[SM 15]

Другое дело, что неявно они всётаки заданы и установлены в дефолтные значения.

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