Это как я понимаю 1 разряд, а если 12? А потом еще реальные цифры из даташита на setup/hold во временные ограничения добавить.

От 2 до 6 - это такты?
Можно и гигагерц тактовую получить и задержку от входа до выхода 10 нс. Это разные понятия.
А проектик показать можете? Чисто полюбопытствовать. Я с Xilinx ничего не делал, а пора уже.

Обижаете. 12 разрядов. Но пока ножки раскидывает сам софт то количество разрядов мало на что влияет.

Сетап холд не заданы только для входных данных. Но легко подкручиваются на idelay.

Т.е. проект рабочий на 100%. Допиливание и вылизывание времянку не испортят. Если не будет новых вводных.
Увеличить задержку на большее число тактов не проблема.

Минимальная задержка 2 такта. Само собой плюс задержка на выходе и выходе но она маленькая плюс её можно подстроить.

Проект. Да запросто:

 qwqwqw.zip ( 264.94 килобайт ) Кол-во скачиваний: 20

Т.е. анализ идет только от триггера до триггера, если да, то охотно верю? Прикрутите set_input_delay минимальные, если данные идут вместе с клоком - там результаты другие будут, хотя 500МГц вытащить при свободой разводке может и удастся.
ЗЫ. Вспомнил, в прошлом году тестовый проект собирал на кинтекс с 450МГц опорой и 4-разрядными данными в режиме DDR, с идеальными setup/hold растаскивалось с трудом. Но то DDR, так что в режиме SDR вообще должно работать без проблем на 500.

Каюсь одну птичку забыл.
Если выходные и выходные триггеры закинуть в пэды выходит 529.101MHz

Вот как в кристалле это всё выглядит

Уменьшено Р Т‘Р С• 48% 330 x 937 (37.03 килобайт)

Уменьшено Р Т‘Р С• 47% 325 x 770 (22.9 килобайт)

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

Про set_input_delay не очень понял. Это откуда переменная? Но одно я знаю точно если входы по паспорту тянут 700МГц значит эти 700МГц туда могут аехать ибо расстояние от физической ножки до первого триггера который в пэде оно фиксированно и заданно разработчиком кристалла.

Вот например как выглядит выходной путь.



Видно что в кристалле нету других путей от триггера (красный) до выходной физической ножки. И этот путь фиксирован и минимален.

В даташите (АЦП/ЦАП) указаны setup и холд на данные относительно клока - максимальное время распространения до фронта и минимальное время удержания после (своими словами). Это нестабильности и для правильного временного анализа их требуется прописать, если Вы используете ISE и UCF, то там set_input_delay аналогичен OFFSET IN, в вивадо визард автоматически создает ограничения на входные/выходные интерфейсы в .sdc формате согласно той временной диаграмме, которую Вы задаете.

Да, а расстояние от пина клока (клокового буфера, выхода PLL или чего там еще) до тактового входа всех триггеров тоже фиксированное и одинаковое? А если производитель говорит, что skew по всей разрядности данных 1ns, а разработчик ПП еще накинет немного? А еще ради интереса посмотрите время распространения сигнала от пина до первого триггера в fast моделе, результат будет немного отличаться...

Фокус в том что на каждую линию данных есть своя уникальная задержка в кристалле которую можно подкручивать с ps шагом. Это можно сделать автоматически или ручками. И получить нужный сетап и холд.
Иными словами плис способна выдать любую времянку не выходящую за ограничение 741МГц для данного кристалла. С любыми фазовыми отношениями. Т.е. мы имеем 2нс такт. Минус джиттер. Оставшиеся 1 с хвостиком наны могут быть разделены на setup/hold произвольным образом по воле разработчика.

Т.е. согласование с входными и выходными цепями если первый и последний триггер лежит в пэде не является проблемой или ограничением. Проблемы и ограничения они внутри плис от первго триггера до последнего.

Это кстати позволяет компенсировать отсутствие выравнивания при разводке параллельных шин. Что сильно упрощает разводку.

Переписал всё совсем по правилам. Прописал ручками клоковые буферы.
Если распихать входные и выходные триггеры в пэды получаются такие результаты:

Если проект на минимальную задержку 2 такта рабочая частота чуть больше 400. За счёт того что путь от пэда до пэда выходит всё же длинноват В проекте про который я говорил 500+ входной триггер был чёрти где. Но зато ближе к выходному. Это увеличило рабочую частоту но сильно бы усложнило отладку. Либо пришлось бы ручками задавать положения триггеров в кристалле чтобы от раскладки к раскладке ничего не плавало.

Т.е. без проблем 400. С ручной вознёй и прочей оптимизацией 500+. Возможно с более толковой расстановкой ножек ещё выше. Но это уже кусок работы.

Если же мы даём добро на минимальную задержку 3 такта то частота становиться 500+ на автомате. Проект прилагается. (он на 3 такта задержки)

 qwqwqw.zip ( 271.46 килобайт ) Кол-во скачиваний: 17

Т.е. временные ограничения на входные интерфейсы не нужны? Вопрос в лоб - время распространения сигнала от пина клока до тактового входа триггера в io-буфере фиксированное при рассчете setup/hold временного анализатора?

Если мы сами подстраиваем задержку каждого пина то нет.
От специального IOшного клокового пина до триггера фиксированно. НО между пином входным и триггером может стоять а может и не стоять. Дополнительный модуль IDelay. Который позволяет подстроить времянку данных.

Иными словами это две модели проектирования.

1. Мы не применяем входной IDELAY и тогда прописываем все условия в таймспеках и молимся чтобы они сошлись ибо влиять мы таким образом ни на что не можем.
2. Мы применяем IDELAY и сами накручиваем задержки по своим соображениям. Например у меня выходные задержки настраиваются автоматом по тестовой последовательности выдаваемой АЦП и выставляются в середину глаза. Удобно

Вот про автоматическое выравнивание: https://www.xilinx.com/support/documentatio...tes/xapp856.pdf

На самом деле нет. Причина в технологическом разбросе и на временном анализе это учитывается (я умолчу пока про температуру и опорное напряжение). Если глубже копнуть литературу, то при рассчете setup/hold учитывается не просто время распространения сигнала от точки А до Б, а минимальное/максимальное время распространения. И разница эта тем больше, чем больше расстояние от А до Б. Да, для клоковых линий этот разброс меньше, чем для обычных сигнальных, но он есть. Можете сами посмотреть любой путь от триггера до триггера, желательно, чтобы они находились не рядом (разница будет видна лучше).
Кроме того, если поменять временную модель на анализе (это температура и напряжение), то пути для рассчетов только setup (ну или hold) будут существенно отличаться. А теперь вопрос - какое значение программируемой задержки Вы будете выставлять, если абсолютные значения максимальной/минимальной задержки неизвестны, анализатор эти значения не выдаст, они же не заданы?

ЗЫ.. Вообще говоря была тема несколько месяцев назад про задержку внутри FPGA, там я приводил цифры для arriaV не самой жирной. Смысл был примерно такой - сигнал проходит через всю FPGA, на входе/выходе регистр в io буфере, разброс абсолютных задержек - несколько нс в зависимости от типа модели.

Значит прорыв намечается.

А подскажите по FMC модулям. Поиск "FMC" по форуму без результатов. Насколько их можно использовать в конечном устройстве? Т.е. имеет ли смысл строить устройство задержки на материнском FMC + FMC АЦП + FMC ЦАП?
На digikey они только в отладочных средствах. https://www.digikey.com/products/en?keywords=fmc
Словно никто не применяет в конечных устройствах.

Фирма АО "Инструментальные Системы" (АО "ИнСис") это вообще адекватная контора или как Руднев-Шиляев?
http://www.insys.ru/fmc
http://www.insys.ru/doc/price.zip

А на эти стоит смотреть?
http://www.fastwel.ru/company/news/623310.html

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

С фаствеллом, намного сложнее. Никогда не знаешь, покупаешь ли серийное изделие или опытные образцы с переделками на плате. Очень тугие в переговорах, до тех поддержки в итоге не дошло

bogaev_roman
На самом деле для высокоскоростных АЦП редко можно выставить ограничения статически. В связи с разбросом min/max задержек на больших частотах ограничения банально не сходятся. Приходится применять динамическое выставление задержек, например по тренировочной последовательности, либо при помощи фазового детектирования внутри ПЛИС.

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

Я же писал что у себя использую динамическую подстройку по тестовой последовательности. Работает как часы.

Слово ручное применялось для обозначения того что мы сами это настраиваем. Алгоритм настройки само собой я не указывал. И уровень его сложности может быть любым. Верно. По этому стоит внимательно выбирать банки до начала разводки.