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

[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 нс. Эта величина сохранится?

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

[des00]

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

ну нормальная частота, с бООльшим запасом %)

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

Читайте описание режимов Source-Synchronous Mode и как в этом режиме работает PLL. Вот немного из даташита

If data and clock arrive at the same time at the input pins, the phase relationship between them remains the same at the clock and data ports of any I/O element input register.
Source-synchronous mode compensates for delay of the clock network used plus any difference in the delay between these two paths:
■ Data pin to I/O element register input
■ Clock input pin to the PLL PFD input

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

Ну во первых вы забываете что клок у вас тоже заходит через IO PAD, что в некоторой мере компенсирует задержку на ввод в фпга, а во вторых если у вас клок отцентрирован, то у вас 5нс в каждую сторону от центра данных, для игры задержками времени вагон.

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

даже как то совестно вас направлять Quartus Handbook-> Section II. Timing Analysis -> The Quartus II TimeQuest Timing Analyzer -> I/O Specifications и для систем всех видов.

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

PLL сразу отпадает, нужно делать другими способами %)