Перейти к содержанию
    

Схемотехнические трюки для ПЛИСоводов

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 hours ago, dxp said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

17 minutes ago, RobFPGA said:

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

UG912:

ASYNC_REG.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 minutes ago, blackfin said:

UG912:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, RobFPGA said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, blackfin said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

34 minutes ago, Nick_K said:

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

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

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

 

Вот схема:

contenteetimes-images-01mdunn-ic-synctechf1.png

 

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

contenteetimes-images-01mdunn-ic-synctechf2.png

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 hours ago, blackfin said:

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

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

1.thumb.png.914c257b6f6f2a0896adf3ba858d4481.png

2.thumb.png.593ea8799196e73753b69722f1b4a527.png

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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.  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, TRILLER said:

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

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

 

1 hour ago, TRILLER said:

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

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

SRLC32E.jpg

 

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

 

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

 

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

CDC_FF.jpg

 

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

CDC_Net.jpg

 

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

CDC_Delay.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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*.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 minutes ago, blackfin said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, TRILLER said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...