[dxp 34]

17 часов назад, RobFPGA сказал:

Это цифры можно считать идеальными. Пустой vu09p-2 чип, только синхронизаторы.  Но вот зависят они как видно от реальных задержек в цепочке синхронизации. 

А как MTBF зависит от заполненности ПЛИС? Там же только от соотношения частот зависит, как часто будут фронты сигналов (клок и данные) пересекаться.

[RobFPGA 27]

3 hours ago, dxp said:

А как MTBF зависит от заполненности ПЛИС? Там же только от соотношения частот зависит, как часто будут фронты сигналов (клок и данные) пересекаться.

Судя по данным также зависит и от реальных задержек. А при заполненном кристалле бывает что из 3-10 ns периода клока остается сотни ps из за плотного роутинга.
Ну и зависит так же  от общего количества линий CDC в дизайне.  Опять же  для больших кристаллов легко можно получить 1-10 тыс. линий с CDC.   

[blackfin 16]

17 minutes ago, RobFPGA said:

А при заполненном кристалле бывает что из 3-10 ns периода клока остается сотни ps из за плотного роутинга.

UG912:

[RobFPGA 27]

4 minutes ago, blackfin said:

UG912:

Это  понятно,  но задержки все равно гуляют,  матрица роутинга не резиновая  

[blackfin 16]

Just now, RobFPGA said:

Это  понятно,  но задержки все равно гуляют,  матрица роутинга не резиновая  

Хм.. Я всегда считал, что роутинг реализован между SLICE'ами. Внутри SLICE/CLB всё жестко соединено проводами и задержки внутри одного SLICE/CLB не больше сотни пс.

[dxp 34]

Я всё равно не догоняю роль задержек, когда речь идёт об асинхронных клоках. Там при любых задержках будет "наползание" одного клока на другой даже если они одинаковой частоты. Т.е. всегда будет возникать момент, когда данные из одного домена будут попадать на фронт клока другого домена. А вот сам этот момент (его появление на временнОй оси) будет зависеть в том числе и от задержек. Но частота "пересечения" данных и клоков зависит от величин самих клоков, от логики, которая определяет частоту переключения данных (не на каждый период клока данные могут меняться), но от задержке в путях данных. И именно эта частота "пересечения" данных и клоков на входах флопов и влияет на вероятность сбоя.

[Nick_K 0]

2 hours ago, blackfin said:

Внутри SLICE/CLB всё жестко соединено проводами и задержки внутри одного SLICE/CLB не больше сотни пс.

Всё верно. Чисто внутри Слайсов (за Альтеровское не ручаюсь) задержки по разным путям отличаются незначительно (у меня было до 25-50 ps). Проблема вылазит позже, так как разные выходы/входы Слайса подключены к матрице интерконнекта по разному и там задержки могут быть и по 100-200 ps запросто.

[blackfin 16]

34 minutes ago, Nick_K said:

Проблема вылазит позже, так как разные выходы/входы Слайса подключены к матрице интерконнекта по разному и там задержки могут быть и по 100-200 ps запросто.

Задержки на выходе цепочки ASYNC регистров к CDC отношения уже не имеют, а потому на величину MTBF никак не влияют.

А разговор сейчас именно про влияние задержки между регистрами в схеме CDC на величину MTBF.  

 

Вот схема:

 

А вот диаграмма:

 

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

При этом, вероятность того, что триггер B2 тоже окажется в метастабильном состоянии увеличится, так как на входе d триггера B2 будет нестабильное значение.

[TRILLER 0]

4 hours ago, blackfin said:

Хм.. Я всегда считал, что роутинг реализован между SLICE'ами. Внутри SLICE/CLB всё жестко соединено проводами и задержки внутри одного SLICE/CLB не больше сотни пс.

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

Альтера же имеет внутренние линии в некоторых семействах?

 

 

[RobFPGA 27]

3 hours ago, dxp said:

Я всё равно не догоняю роль задержек, когда речь идёт об асинхронных клоках

2 hours ago, blackfin said:

Задержки на выходе цепочки ASYNC регистров к CDC отношения уже не имеют, а потому на величину MTBF никак не влияют.

Я  не зря привел результат для нескольких одинаковых цепочек

600 -> 700 MHz
+----------+----------------+------------------------+-----------------------+-------------------------+----------------+------------------+---------------+----------------+
| CDC Path |    MTBF        | Data Toggle Rate(Mtrs) | Data Sample Rate(Mhz) | Total Settling Time(ns) | Sending Domain | Receiving Domain | Number Stages | CDC Net Name   |
+----------+----------------+------------------------+-----------------------+-------------------------+----------------+------------------+---------------+----------------+
| 5        | 5.96e+10 years | 31.2                   | 699                   | 2.21                    | CLK1           | CLK2             | 2             | g_bit[4].din_r |
| 6        | 5.89e+07 years | 31.2                   | 699                   | 1.88                    | CLK1           | CLK2             | 2             | g_bit[5].din_r |
| 7        | 1.31e+10 years | 31.2                   | 699                   | 2.14                    | CLK1           | CLK2             | 2             | g_bit[6].din_r |

Заметьте -   для цепочки длиной 2 триггера  и частотой клока 700 MHz (период T=1.428 ns) суммарная задержка (Total Settling Time) участвующая в расчете MBTF больше 1T, но  меньше чем 2T (2.856 ns).  А в худшем случае меньше на целую  ~1 ns. Получается в расчет идет не только время  между первым и вторым триггером, но также и время между 2 вторым триггером в цепочке и остальной схемой.   

И это  повторюсь для пустого чипа vu09p-2.  

[blackfin 16]

1 hour ago, TRILLER said:

Надеюсь, что Вы по большей части работали не с xilinx.

Зря надеетесь.. :)

 

1 hour ago, TRILLER said:

На моей памяти никогда не было "внутреннего" интерконнекта между триггерами у них.

Да, всё так. Хотя на мой взгляд, логичнее было бы сделать на SRLC32E:

 

Но Виваде, конечно, виднее.. :)

 

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

 

Посмотрел в рабочем проекте как соединены триггера с атрибутом ASYNC_REG:

 

Да, регистры соединены через интерконнект:

 

Но задержка всего 286 ps:

[RobFPGA 27]

25 minutes ago, blackfin said:

Да, всё так. Хотя на мой взгляд, логичнее было бы сделать на SRLC32E:

Как раз делать CDC на SRL категорически на рекомендуют.  Судя по всему структура  SRL этому не способствует  :(

 

Сделал еще  один тест.  В этот раз специально констрейном задал  минимальную задержку (0.5 ns) с выхода второго триггера цепочки синхронизации к остальной части схемы.
С эмитировал так сказать реальную ситуацию в плотном дизайне. При этом времянки в дизайне соблюдаются с минимальным слаком 0.08 ns.  

600 -> 700 MHz  
+----------+-------------+------------------------+-----------------------+-------------------------+----------------+------------------+---------------+--------------+
| CDC Path |    MTBF     | Data Toggle Rate(Mtrs) | Data Sample Rate(Mhz) | Total Settling Time(ns) | Sending Domain | Receiving Domain | Number Stages | CDC Net Name |
+----------+-------------+------------------------+-----------------------+-------------------------+----------------+------------------+---------------+--------------+
| 1        | 119 years   | 31.2                   | 699                   | 1.35                    | CLK1           | CLK2             | 2             | din_r[0]     |
| 2        | 4.95 years  | 31.2                   | 699                   | 1.23                    | CLK1           | CLK2             | 2             | din_r[1]     |
| 3        | 15.9 years  | 31.2                   | 699                   | 1.26                    | CLK1           | CLK2             | 2             | din_r[2]     |
| 4        | 18.4 years  | 31.2                   | 699                   | 1.28                    | CLK1           | CLK2             | 2             | din_r[3]     |
| 5        | 2.52 years  | 31.2                   | 699                   | 1.19                    | CLK1           | CLK2             | 2             | din_r[4]     |
| 6        | 10.8 years  | 31.2                   | 699                   | 1.26                    | CLK1           | CLK2             | 2             | din_r[5]     |
| 7        | 9.44 months | 31.2                   | 699                   | 1.13                    | CLK1           | CLK2             | 2             | din_r[6]     |
| 8        | 19.8 years  | 31.2                   | 699                   | 1.27                    | CLK1           | CLK2             | 2             | din_r[7]     |
| 9        | 4.38 months | 31.2                   | 699                   | 1.11                    | CLK1           | CLK2             | 2             | din_r[8]     |
| 10       | 12.8 years  | 31.2                   | 699                   | 1.26                    | CLK1           | CLK2             | 2             | din_r[9]     |
+----------+-------------+------------------------+-----------------------+-------------------------+----------------+------------------+---------------+--------------+
* Summary: Overall Synchronizer MTBF:2.43 months

  Результат  очень красноречивый  

 

[blackfin 16]

7 minutes ago, RobFPGA said:

Результат  очень красноречивый

OK.

 

Вот MTBF в пустом проекте на K3UP-2-i:

+----------------+-----------------+----------------+
| Structure Type | Total in Design | MTBF           |
+----------------+-----------------+----------------+
| Synchronizers  | 16              | 2.96e+03 years |
| FIFOs          | 0               |  ---           |
| Overall        | 16              |  ---           |
+----------------+-----------------+----------------+
+----------+----------------+------------------------+-----------------------+-------------------------+----------------+------------------+---------------+-------------------+
| CDC Path |    MTBF        | Data Toggle Rate(Mtrs) | Data Sample Rate(Mhz) | Total Settling Time(ns) | Sending Domain | Receiving Domain | Number Stages | CDC Net Name      |
+----------+----------------+------------------------+-----------------------+-------------------------+----------------+------------------+---------------+-------------------+
| 1        | 1.65e+08 years | 3.36                   | 690                   | 1.81                    | s_axis_aclk    | m_axis_aclk      | 2             | p_0_in1_in__0[0]  |
| 2        | 7.55e+03 years | 3.4                    | 690                   | 1.38                    | s_axis_aclk    | m_axis_aclk      | 2             | p_0_in1_in__2[0]  |
| 3        | 4.01e+04 years | 3.64                   | 690                   | 1.46                    | s_axis_aclk    | m_axis_aclk      | 2             | p_0_in1_in__4[0]  |
| 4        | 1.55e+06 years | 2.84                   | 690                   | 1.57                    | s_axis_aclk    | m_axis_aclk      | 2             | p_0_in1_in__6[0]  |
| 5        | 3.9e+04 years  | 2.45                   | 690                   | 1.46                    | s_axis_aclk    | m_axis_aclk      | 2             | p_0_in1_in__8[0]  |
| 6        | 1.51e+06 years | 2.54                   | 690                   | 1.55                    | s_axis_aclk    | m_axis_aclk      | 2             | p_0_in1_in__10[0] |
| 7        | 2.01e+08 years | 3.64                   | 690                   | 1.79                    | s_axis_aclk    | m_axis_aclk      | 2             | p_0_in1_in__12[0] |
| 8        | 6.5e+03 years  | 3.81                   | 690                   | 1.34                    | s_axis_aclk    | m_axis_aclk      | 2             | p_0_in1_in__14[0] |
| 9        | UNDEFINED      | ZERO*                  | 714                   | 1.54                    | m_axis_aclk    | s_axis_aclk      | 2             | p_0_in1_in__15[0] |
| 10       | UNDEFINED      | ZERO*                  | 714                   | 1.76                    | m_axis_aclk    | s_axis_aclk      | 2             | p_0_in1_in__1[0]  |
| 11       | UNDEFINED      | ZERO*                  | 714                   | 1.63                    | m_axis_aclk    | s_axis_aclk      | 2             | p_0_in1_in__3[0]  |
| 12       | UNDEFINED      | ZERO*                  | 714                   | 1.63                    | m_axis_aclk    | s_axis_aclk      | 2             | p_0_in1_in__5[0]  |
| 13       | UNDEFINED      | ZERO*                  | 714                   | 1.62                    | m_axis_aclk    | s_axis_aclk      | 2             | p_0_in1_in__7[0]  |
| 14       | UNDEFINED      | ZERO*                  | 714                   | 1.79                    | m_axis_aclk    | s_axis_aclk      | 2             | p_0_in1_in__9[0]  |
| 15       | UNDEFINED      | ZERO*                  | 714                   | 1.75                    | m_axis_aclk    | s_axis_aclk      | 2             | p_0_in1_in__11[0] |
| 16       | UNDEFINED      | ZERO*                  | 714                   | 1.61                    | m_axis_aclk    | s_axis_aclk      | 2             | p_0_in1_in__13[0] |
+----------+----------------+------------------------+-----------------------+-------------------------+----------------+------------------+---------------+-------------------+
* Summary: Overall Synchronizer MTBF:2.96e+03 years

Только не понял, почему для m_axis_* -> s_axis_* Toggle Rate равны ZERO*.

[RobFPGA 27]

9 minutes ago, blackfin said:

Только не понял, почему для m_axis_* -> s_axis_* Toggle Rate равны ZERO*.

Наверное  Vv не может понять из каких то внутренних проблем какое значение применить.  Это значение можно задавать командой set_switching_activity  

[Nick_K 0]

2 hours ago, TRILLER said:

На моей памяти никогда не было "внутреннего" интерконнекта между триггерами у них.

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