Jump to content

    

RobFPGA

Свой
  • Content Count

    2823
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About RobFPGA

  • Rank
    Гуру

Контакты

  • ICQ
    Array

Recent Profile Visitors

13868 profile views
  1. Ну так это определяется в основном в выравнивании по bitslip (если считать фазу в TX и задержки в каналах одинаковыми). А если без синхронизации между каналами то тогда вообще не понятно как TC мог работать с таким тактированием. Ну а если сделать начальную синхронизацию между каналами то фазу RX (на низкой частоте) между ними можно можно подстроить опять же с точностью до бита. P.S. Вот кстати интересная презентация от CERN по похожему поводу, правда для Virtex5
  2. В этом проекте основные частоты 322 и 250 MHz, Speed Grade 2 У меня тоже не сразу получатся стало. Тут важно прочувствовать что и как надо делать, но в любом случае, нужно несколько итераций DP или AREA_GROUP пока не получится удачная конфигурация. Увы тут нет четких правил которые гарантируют 100% результат.
  3. Я говорю о разной фазе RX клока на высокой частоте. 360 градусов это 1 битовый интервал. Это и есть та недетерминированная задержка которая обычно не контролируется в GTX. И эта неопределенность потому что, на сколько знаю, CDR у Xilinx выполнен по схеме интерполяции фазы, а не аналоговой PLL. По сути это цифровой DDS который дополнительно крутит в определённом диапазоне фазу восстановленного клока относительно фазы референтного клока. Выравниванием по bitslip мы синхронизируем фазу клока RX на низкой стороне c точностью до бита. Поэтому и получается детерминированная задержка (равная аппаратным задержкам реализации входных цепей RX, CDR и десериализатора) и недетерминированная в пределах 1 битового интервала. Если взять 2 таких канала, и предположить что на передающей стороне TX работает строго синхронно то на приемной мы получим после CDR 2 восстановленных RX клока одинаковой частоты с неопределенностью фазы в 1 бит из за CDR. А вот фаза клоков RX на низкой частоте (после выравнивания слов по bitslip) будет отличатся еще и на разницу задержек в каналах. И на низкой частоте 360 градусов это будет задержка в Nбит где N это размер слова.
  4. Два отдельных потока могут разойтись как раз и за недетерминированности фазы CDR на 1 бит. И естественно разных задержек в физике. Тут уж никуда не деться. Но после выравнивания слова bitslip-ом выглядеть это должно как разная фаза восстановленного RX клока на низкой частоте. Но если на стороне передачи TX клок общий и фазированный то и разница фаз RX на приемной стороне тоже должна быть постоянной. Опять же тут важен и TX канал. Так как в TX есть возможность крутить фазу передатчика (TX Phase Interpolator PPM). Причем динамически. На чем собственно и пытаются делать DPLL для синхронизации частоты и фазы TX по восстановленному клоку RX. Увы у меня не было практической задачи выравнивания и синхронизации нескольких каналов. А вот задач по минимальной и детерминированной latency по пути RX - TX полно
  5. Как так? - Как раз bitslip и призван выровнять начало десериализации на первый бит слова. Поэтому на входе RX каждый такт будет правильное выровненное слово. В TX тот же процесс но в противоположную сторону - каждое новое слово на низкой частоте TX (которое в фазе c RX) запускает сериализацию. Получается чисто синхронная схема без недетерминированных задержек. Разбежка на задержки в 1 бит в RX остается но эта недетерминированность чисто за счет неопределённости фазы восстановленного клока в CDR. Недетерминированность в слово тут может быть если bitslip делается не честно, пропуском бит (изменением фазы начала десериализации), а методом переключения битов с выхода широкого (2x выходной разрядности) сдвигового регистра. Но на сколько я помню это не так.
  6. Вот именно bitslib. Но в этом случае синхронизация выходного слова после десериализации должна быть с точность до бита, а ни как не слова. Но это если делать честный ручной bitslib На TX стороне фаза передачи "привязана" к фазе TX клока, и если этот клок с фазирован с RX то опять же разбежки более чем на бит получится не должно.
  7. Как раз чем плотнее и напряженнее дизайн, тем больше профита можно получить от LL и DP технологий. Именно за счет повторяемости результатов при сборке.
  8. Приветствую! 1 бит разбежки при десериализации это понятно. Но откуда берутся остальные 40-60ns у TC? В синхронном режиме при ручном управлении выравниванием в RX можно добиться словной синхронизации без доп. задержек. И если весь функционал внутри GTX выключен это будет фактичекски только сдвиговый регистр фазу десериализации которого подстроили на границу слова. Задержка в таком режиме минимальна и детерминирована. И если обработка данных в FPGA и передача ведется на едином клоке ( восстановленном из RX) то тоже неоткуда взяться недетерминированной задержке. Удачи! Rob.
  9. Приветствую! А какой функционал у вас включен в GTX? Если нужна детерминированная задержка нужно выключать все внутри (для начала хотя бы elastic buffer) и делать требуемый функционал снаружи, в обычной логике. Причем и на передающей и на приемной стороне. Удачи! Rob.
  10. Блин да что у вас за страхи такие "тренд, промыть мозги, ..." Меньше обращайте на это внимание, а то похоже на то что мозги у вас уже этим "промыты" Реклама, маркетинг, впаривание ненужного, было всегда, еще со времен древнего Рима. Это главный принцип торговли. Ну а старшее поколения по своей сути всегда в большинстве консервативно. Ему и так нелегко живется, а тут еще тянутся за все ускоряющимся прогрессом.
  11. Приветствую! Тут надо уточнить что значит (для чего) "... определить с какого"? Получить бинарный код? Ну и доп. условие - могут ли быть одновременно несколько ready? Если да то каков приоритет выбора? Если одновременно может быть только один ready и бинарный код не нужен то объединять шины можно через простой AND-OR мукс. Удачи! Rob.
  12. Приветствую! Обе эти технологии что Logic Lock (LL) что Design Partitions (DP) имея в основе общее решение - ограничение зоны размещение и роутинга элементов на кристалле, в тоже время служат разным целям. Logic lock лишь гарантирует размещение блоков дизайна в определенных местах, что упрощает (в теории ) FIT. Но что и куда фиксировать надо понимать разработчику и часто это сильно итерационный процесс. И к тому же обязательно учитывать физ. особенности целевой FPGA. С одной стороны фиксация может давать выигрыш по времени FIT за счет ограничения числа вариантов размещения элементов, с другой неудачная фиксация сильно усложнят и удлиняет сам FIT. Design Partitions служит немного другому, в первую очередь для возможности пере-использовании результатов FIT отдельных блоков в одном или разных дизайнах. И опять же, что бы эта "серебряная пуля" работала "волк" дизайна должен быть действительно монстром. То есть сам дизайн должен быть подготовлен для использования с DP . Должен быть разбит на функциональные блоки, желательно компактные, слабо связанные между собой, имеющие регистровую развязку на входах и выходах. В таком случае использования DP может существенно выиграть время но опять же не даром, а за счет % использования кристалла. Ну и при сборка с использованием DP тоже может быть не простой процесс. Особенно если не возможно весь дизайн распихать по DP и часть логики остается в "свободном полете". В таком случае можно собирать дизайн итеративно по отдельным или (группам) DP фиксируя удачные или пере-разводя неудачные с ошибками времянки. Для дизайнов монстров это действительно существенно экономит время. Внизу пример такой сборки Stratix V. Без разбития на DP собиралось за 9-15 часов и то - чаще не собиралось . С DP гарантированную сборку делало за ~3 часа. Алгоритм сборки примерно таков - сначала DP собирались и фиксировались по отдельности начиная от периферии. Потом делался анализ ошибок времянки связей между DP и те в которых были ошибки по новой пере разводились совместно. Удачи! Rob.
  13. Ага, не получается - на max_depth = 16384 Qu пишет в логах source assignments - "max_depth 16384 Invalid assignment name", И судя по доками на память в S10 (после внимательного повторного чтения) не зря так пишет - Вот те и "M20K"
  14. Они то синтезируются, но как то странно, выход из памяти идет на вход умножителя напрямую, без регистра, а на выходе умножителя стоят толпой 3 регистра один за другим. Поэтому времянка и сходится.
  15. Естественно я это помню. И часа не прошло как прочитал талмуд про DSP в Stratix 10. Еще не успел забыть Но сначала я пошел ленивому по пути просто сгенерил IP корку cmul. Хоть тогда уже знал (по приключениям с StratixV) что эта корка у Intel на самом деле обычный RTL, даже без всяких атрибутов. При этом корка генерирует только структуру на 3 умножителях, а классическую на 4-х для S10 отказывается делать. Потом посмотрев на кошмар после FIT. Нарисовал RTL на 4 умножителях, с учетом внутренней структуры DSP. Бардак после FIT остался но стало чуть лучше по частоте. Потом решил сделать на примитивах и тут напоролся на эти финты с портами