Входные сигналы ПЛИС и их "времянка", Тема, комплиментарная теме про выходные сигналы. :) Опции

[dxp]

Вопрос про входные сигналы поднимался тут. Теперь про ответную часть.

Вот валится поток - данные (по параллельной шине, хотя это и не важно) и клок. Клок, понятное дело, задержан на какую-то величину. Величина не очень большая, не больше половины периода. Если поток принимает "железяное" устройство, где четко указаны setup/hold времена, то вопросов нет. Но если поток идет в FPGA, то тут возникают вопросы.

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

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

Второй вариант - обконстрейнить. Т.е. и на сигналы входных данных, и их клока наложены констрейны, задающие максимальную и минимальную задержки от входных пинов до входных портов памяти. Этот вариант работает. Вроде. Но почему-то нет уверенности, что это 100%-ный вариант, что это будет всегда и везде работать.

Кто как делается в таких случаях? Какие мнения, опыт?

Спасибо.

[des00]

Кто как делается в таких случаях? Какие мнения, опыт?

многое зависит от того как этот клок заходит и его частота. Вот те варианты которые я делал.

1. Подать клок на dedicated clock pin который предназначен для того IO банка где идет шина данных и использовать триггеры в IOB
2. Подать клок на PLL в режиме компенсации входной задержки и на этом клоке резать данные используя триггеры в IOB
3. Нарезать цифровой поток более ВЧ клоком используя триггеры в IOB и детектор фронта тактовой частоты
4. Если другие варианты не работают, то остается садить клок на глобальную линию и резать на этом клоке триггерами в IOB.

Констрейны нужно прописывать во всех случаях

[dxp]

многое зависит от того как этот клок заходит и его частота. Вот те варианты которые я делал.

Частота порядка 100 МГц.

1. Подать клок на dedicated clock pin который предназначен для того IO банка где идет шина данных и использовать триггеры в IOB

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

2. Подать клок на PLL в режиме компенсации входной задержки и на этом клоке резать данные используя триггеры в IOB

Это что, клок, пропущенный через PLL, окажется на тактовых портах триггеров IO точно в момент, соответствующий исходной задержке между данными и клоком? Так ведь эта задержка порядка 2.5 нс. Неужели прохождение через PLL + трассировка до IOB составят меньшую величину?

3. Нарезать цифровой поток более ВЧ клоком используя триггеры в IOB и детектор фронта тактовой частоты

Тут не сильно разгонишься.

4. Если другие варианты не работают, то остается садить клок на глобальную линию и резать на этом клоке триггерами в IOB.

Так тут все равно пока клок дойдет до глобальной линии, пока по ней добежит до IOB, эти несчастные 2.5 нс уже истекут. Даже если учесть, что от пина до входа данных IO триггера тоже есть задержка - порядка 1.3 нс, все равно мало времени, не успеет он.

Констрейны нужно прописывать во всех случаях

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

Наверное, надо слепить тестовый проектик простой и посмотреть эти времянки на симуляторе после синтеза.

Это почему нельзя. Заводите ваш клок на глобальный, и принимаете ваши данные на входные триггера по этому клоку. А затем подаете их на FIFO. Именно так и нужно делать.

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

Да, еще забыл сразу сказать. Поток данных нерегулярный, в нем есть паузы. Как короткие - один-два такта, так и длинные - десятки микросекунд.

[Михаил_K]

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

Эта информация есть в даташите на плисину. Точнее там приводятся времена ts и th. И приводятся они для случая, когда клок заведен на глобальную клоковый вход. Только опираясь на эти цифры, вы можете гарантировать нормальную работу девайса. И эти времена вы должны выдержать.

Да, еще забыл сразу сказать. Поток данных нерегулярный, в нем есть паузы. Как короткие - один-два такта, так и длинные - десятки микросекунд.

Догадываюсь что вы хотели сказать. У вас видать и клок на это время пропадает? Так делать не надо. Желательно, чтобы клок работал всегда. А данные, раз уж они не регулярные, сопровождать сигналом значимости, который с точки зрения передачи ничем от самих данных не отличается.