bogaev_roman

Вы удивитесь, но 13.1. Сейчас на 17.0 перехожу, но буду ли переводить проект на него, не знаю - там многие корки обновлений потребуют.

Перешел недавно на новую версию квартуса, заметил существенное увеличение времени компиляции при наличии временных ошибок. Забыл в проекте прописать новую частоту, подцепил другой sdc или банально вытащил в ST сигнал из другого тактового домена и время компиляции увеличивается до 50%, при этом настройки фиттера стоят по умолчанию, т. е. никакой агрессивной оптимизации. В предыдущих версиях такого вроде бы не было.

Заводил все свои 36 трансиверов на arriaV в следующем режиме - группы по 3/6 в одном логическом канале, native, Bounding mode xN, external pll (number=1, clock network = xN). Частота 1250, все работает как надо. Но два момента: 1. Жрет по мощности это чудо прилично (использовал датчик alt_temp_sense, за пару минут нагревается до 95 градусов, охлаждайзер пришлось ставить). 2. При добавлении других внешних интерфейсов по максимуму (типа DDR3) и логической большой загрузке требует добавление грамотных ограничений (проблемы с клоковыми ресурсами, приходится прибивать гвоздями расположение pll). PS/ Там в документации много неочевидных (с первого взгляда) вещей, например, если использовать два трансивера из одного логического триплета в одном логическом канале, то то оставшийся уже не задействовать ну или один трансивер в некоторых режимах используется под CMU PLL, причем не абы какой, а конкретный - 0 или 4 из банка (вроде), ну это в посте 2 картинка прикреплена.

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

Это и есть структура io буфера, входная часть отображена внизу схемы - входной сигнал через input_buffer и delay_chain поступает на вход D триггеров PRN, никак дополнительных мультиплексоров на этом пути нет - особенности архитектуры. Что за задумка, если не секрет, может есть другие стандартные методы решения на обычной логике?

Нет по идее. Сам DDR регистр (точнее там три триггера) находится во входном буфере, на вход D нижнего триггера сигнал поступает напрямую через цепочку задержек от пина (это хорошо видно из чипланнера).

Direct mode, есть возможность подключить lvds mode. Что это даст?

Я об этом и думаю коэффициент - 10, просто все расчеты велись изначально по этому документу https://www.altera.com/support/support-reso...142011_962.html

Проект не мой, я пока не ковырял подробно, но на сколько я понял там буфер стоит. Тут еще момент появился - все работает со скоростью 600Mb/s в режиме SDR для циклон5, в документации вроде максимальная частота отталкивается от максимально возможной частоты с выход pll, т.е. 550МГц, что меньше требуемой.

Есть проект, в котором используется именно внешняя pll и data_alignment, работоспособность зависит от компиляции к компиляции, т. е. вроде проблемы с таймингами. При попытке посмотреть временные пути столкнулся с проблемой - физика реализована на жестких блоках, анализ закрыт. Как там вообще физика реализована, нужно что-то прописывать во временных ограничениях кроме мультицикла на выходе и частоты на входе pll и ее производных? Временных ошибок нет, анализ unconstraint_patch говорит, что необконстрейненых путей тоже нет. ЗЫ. Кстати, каким образом принудительно задать режим работы DDR - там настройки такой нет, только с помощью настроек pll?

А кто-нибудь знает, в каком документе описаны требования к частотам, являющимся опорными для трансиверов ну и максимальное отклонение в ppm при работе CDR (помимо документа io switching characteristics)?

Да, я к сожалению не могу прикрепить настройки трансивера, попробую так описать главное: .tx_enable (1), .rx_enable (1), .enable_std (1), .data_path_select ("standard"), .channels (6), .bonded_mode ("xN"), .data_rate ("1250 Mbps"), .pma_width (10), .tx_pma_clk_div (1), .pll_reconfig_enable (0), .pll_external_enable (1), .pll_data_rate ("1250 Mbps"), .pll_type ("CMU"), .pma_bonding_mode ("xN"), .plls (1), .pll_select (0), .pll_refclk_cnt (1), .pll_refclk_select ("0"), .pll_refclk_freq ("125.0 MHz"), .pll_feedback_path ("internal"), .cdr_reconfig_enable (0), .cdr_refclk_cnt (1), .cdr_refclk_select (0), .cdr_refclk_freq ("125.0 MHz"), .rx_ppm_detect_threshold ("1000"), .rx_clkslip_enable (0), .std_protocol_hint ("basic"), .std_pcs_pma_width (10), .std_low_latency_bypass_enable (0), .std_tx_pcfifo_mode ("register_fifo"), .std_rx_pcfifo_mode ("register_fifo"), .std_rx_byte_order_enable (0), .std_rx_byte_order_mode ("manual"), .std_rx_byte_order_width (9), .std_rx_byte_order_symbol_count (1), .std_rx_byte_order_pattern ("0"), .std_rx_byte_order_pad ("0"), .std_tx_byte_ser_enable (0), .std_rx_byte_deser_enable (0), .std_tx_8b10b_enable (1), .std_tx_8b10b_disp_ctrl_enable (0), .std_rx_8b10b_enable (1), .std_rx_rmfifo_enable (0), .std_rx_rmfifo_pattern_p ("00000"), .std_rx_rmfifo_pattern_n ("00000"), .std_tx_bitslip_enable (1), .std_rx_word_aligner_mode ("sync_sm"), .std_rx_word_aligner_pattern_len (10), .std_rx_word_aligner_pattern ("17c"), .std_rx_word_aligner_rknumber (3), .std_rx_word_aligner_renumber (1), .std_rx_word_aligner_rgnumber (3), .std_rx_run_length_val (31), .std_tx_bitrev_enable (0), .std_rx_bitrev_enable (0), .std_tx_byterev_enable (0), .std_rx_byterev_enable (0), .std_tx_polinv_enable (0), .std_rx_polinv_enable (0) А у Вас с какими настройками стабильно работало в режиме CDR?

Для этих вроде целей используется кодирование 8b/10b, для определения границ слова используется синхрослово BC, которое кодируется в 17С и последовательно передается по линии.

Да, похоже, мелочь какую-то и упустил. Что за скрамблер?

Стабильно не работает. В случае передачи непрерывной последовательности синхросимволов BC все работает без сбоев, при попытке вставить в передачу обычные данные периодически возникают ошибки - rx_errdetect. Изменение скважности и периодичности синхроимпульсов на ситуацию не влияет - в последнем случае передавал последовательно 32 синхроимпульса и 32 слова данных, после подстройки стабильно вываливается ошибка через 2^20 тактов.

Можно сразу все dac_im* вытащить со всеми fan-in. Чтобы понять откуда разбег в 3нс получается приведите еще и путь для другого выхода (скорее всего пины находятся между банками памяти или dsp-блоками).

Я сигналы сначала в timequest нахожу, потом правой кнопкой locate->chip planner, в окне chipplanner в show physical routing выделяю появившийся объект, слева (типа окна инструментов) можно подключить к этому объекту fan in/fan out, общее масштабирование - ctrl+колесо мыши. Таким образом можно посмотреть необходимые объекты на всей площади fpga.

Эти ограничения из даташита (просто максимальное окно на работу при них получается всего 10-5-3=2нс)? clk_dac - это выход pll (из приведенных ограничений не видно)? Для подробного анализа можете привести схему чипланнера, на которой показаны расположения io-буферов и pll (может они по всему периметру раскиданы, так непонятно)?

Очень интересно. Архитектурная особенность только для cyclone V или для других семейств типа arriaV тоже?

Задайте ограничения, тогда slack уменьшится до -2нс, потом сдвиньте приемную частоту больше, чем на 2нс (300градусов), если hold не вылезет, то по setup должно пройти (в идеальном случае). Но откуда там набегает 3нс при переходе от ddr регистра до обычного в соседней ячейке - загадка.

Временная модель, приведенная Вами - скорее всего для худшего случая (slow - повышенная температура, пониженное напряжение и технологический разброс). Все-таки Вы уверены, что клок идет по глобальной линии клока? Интересно посмотреть запас по холду, если он большой, то можно попробовать фазу подергать. Зы Посмотрел внимательно на последний отчет по времянке, у Вас ограничения не потерялись в sdc (relationship соответствует 1нс, а должен по идее 2.5нс)?

Да я просто документацию, похоже, читать не умею. Как я понял CDR работает сначала с опорной частотой и только потом подстраивается под входной поток данных, после этого сигнал rx_is_lockedtoref становится неактуальным (для контроля работы и перезапуска приемопередатчика я его использовал), а в качестве контрольного сигнала нужно использовать rx_is_lockedtodata. После этапа отладки, если все будет стабильно работать отпишусь.

Все равно на выходе будет обычный дополнительный регистр на рассыпухе. Входной io буфер для данного случая представляет из себя DDIO in из трех регистров и цепочки delay chain, там физически что-то еще дополнительно засунуть нельзя.

Проанализируйте два отличия: 1. Существенно поменялось время IC (хотя Вы написали, что задержка в io-буферах 0). 2. Существенно уменьшился разброс clocks_patch (все-таки убедитесь, что в первом случае клок пошел по глобальной шине клоков и, по возможности, используйте клокконтрол поближе к рабочей логике). ЗЫ. Кроме этой логики в проекте есть еще какая-то другая логика, стоящая после этих регистров (проект посмотреть в данный момент времени возможности нет)? Если есть, попробуйте ее убрать. ЗЫЫ. Ограничения на размещение я обычно прописываю прямо в .qsf- файле. Изначально их можно задавать в assignement editor,.

Два вопроса: 1. Проверьте задержку в IO буфере (delay chain) и приведите цифру. 2. Где расположена pll, от которой питается вся логика - не в другом ли она конце fpga, точно ли этот клок глобальный (пессимизм большой и сам разброс значений для клока)? ЗЫ. Я так понимаю пины у Вас жестко привязаны (между ними банк памяти или умножитель, что не есть хорошо)? Ради интереса попробуйте их отвязать и посмотреть результат.