spectr

Можно попробовать вывести на пин в топлевел и сделать его виртуальным.

Не-не, это не совсем то. Pre-, Center-, Post- показывает какой участок данных будет записываться сигналтапом при срабатывании триггера. Соответственно, будет записываться: 1. Pre: То что происходило ДО срабатывания триггера. 2. Center: То что происходило до и после срабатывания триггера (поровну - т.е. при длине сигналтапа 1024 сэмпла, будет записано 512 сэмплов до и 512 сэмплов после триггера). 3. Post: То что происходило после срабатывания триггера. Вам же надо настроить условия срабатывания триггера на вкладке Setup, которая рядом с времянкой: Если сигналов по-прежнему нет, то возможно они у вас объявлены как wire - такие и правда не видятся. Можно кинуть на порт или сделать его reg-ом. Если же это reg и он всё равно не видится, тогда добавьте перед его объявлением вот такую магию - она не даст фиттеру убить регистр, если он никуда не подключен: (*preserve, noprune*)reg packet_valid;

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

По поводу добавления сигналов на времянку: ищите с включенным фильтром SignalTap: Pre-sysnthesis (или как-то так), он позволяет вытащить сигналы, которые еще не проварились фиттером в нечто непонятное. По поводу отображения: а у вас триггер-то настроен? А то такое ощущение что сейчас сигналтап работает в свободном режиме и вы конечно же не увидите (не успеете увидеть) транзакцию. Настройте срабатываение по триггеру - например, по перепаду какого-либо управляющего сигнала. Отключается в Assignments--Settings--Compiler settings--Advanced Analysis--NOT Gate Push-Back (выставить в Off).

А DSP Builder установлен? По-моему она сидит в нём.

set qdir $env(QUARTUS_ROOTDIR)

Китайцы, кстати, последнее время держат цены почти вровень с нашими магазинами. С доставкой может получиться и дороже, причем некоторые даже торговаться не хотят. П.С. по Китаю можете писать в личку.

Ситуация разрешилась, всё заработало. У трансивера нужно было настроить следующие параметры: - Data rate = 622.08 (не изменилось) - TX local clock division factor = 2 (раньше было =1) - всё остальное без изменения С толку сбивает следующий пункт, который вычисляется автоматически - TX PLL base data rate, он почему-то равен 1244.16. Что это за параметр? Внятного описания в документации - нет. У меня вообще ощущение что это должен быть результатом деления 622.08 на 2, а не умножения как сейчас. Нет ли тут ошибки?

В результате ряда экспериментов на serial loopback'e выяснилось что на tx_std_clkout выходит частота вдвое большая, чем надо. Ожидается 77.76, а выходит 155.52. Скорость передачи 622.08 Мбит/с, TX FPLL настроена корректно: - частота 311.04, параметры трансивера тоже: - Data rate = 622.08 - TX local clock division factor = 1 - PCS width = 8 bits Что интересно, RX часть трансивера работает отлично - CDR лочится и выдает ожидаемую 77.76 (ширина шины после десереализации - 8 бит). Теперь понятно почему RX не видит TX :)))) Но вот почему частоты приемного и передающего каналов различаются - ума не приложу пока.

Если включить заворот post-CDR, то да, работает. Но в этом случае работает только PMA-часть трансивера, PCS не задействуется. Если же заворот выключить и руками завернуть параллельные шинки rx на tx (ну или просто подать константу), то не работает - на выходе ничего нет. Кстати, а какой частотой (каким значением) должен тактироваться передающий тракт (tx_coreclkin)? Такой же, которую выдает CDR после восстановления? Как-то не очень ясен этот момент. Есть подозрение что проблема в этом.

Снова дошли руки до этого проекта. И возникла очередная заминка. С приёмом данных всё в порядке - поток приходит, разворачивается в байты и всё хорошо. Проблема с передачей - передатчик вообще ничего не передаёт. Совсем. Если включить pre- и post-CDR завороты, то на передающие пины данные выводятся, что говорит о том что уровень PMA работает нормально и проблема где-то выше - в PCS части. Измерительный прибор данные видит и успешно восстанавливает частоту. Но если завернуть поток на уровне PCS - после десериализации (ну например, соединить rx_parallel_data b tx_parallel_data), то на выходных пинах - тишина. TX часть не висит в сбросе - все сигналы индицируют что передатчик откалибровался и готов работать. Я перепробовал, пожалуй, все возможные варианты и ничего пока не помогает: - передавать биты задом наперед - двигать биты сигналом tx_bitslip - инвертировать полярность - крутить настройки TXPLL, integer, fractional режим - тактировать tx разными клоками И всё равно на выходе - 0. У кого это хозяйство работает - что вы делали для передачи?

Вы пришли с утра на работу и, по-хорошему, вам надо запуллиться, дабы иметь актуальные исходники. И тут вдруг выясняется что ваш controller.v ночью подправил Вася Пупкин. Далее есть два варианта: 1. Если у Вас просто система контроля версий и всё. Вы злитесь и идете бить лицо Василию, попутно ломая ноги PM-у. Утрированно, конечно, но смысл в том что вы не будете знать причину изменений в коде и потратите время на пересогласование актуального сорца. Это, хотя и выстреливает очень редко, но методически - крайне плохо. 2. У Вас система контроля версий, которая не дает сделать коммит без подписи (возможно, содержащей определенные теги-метки). Вася Пупкин, после правки вашего controller.v вынужден описать в коммите что он там наделал. Вы получаете уведомляшку, после этого автоматом создается тикет в code-review и команда (Вы в том числе) смотрит чо он там понаписал посреди ночи. И уже после этого PM или тимлид подтверждает коммит, перекидывая его в рабочую ветку. Примерно так. Это, пожалуй, самый корректный вариант. Но он да, требует затрат на обучение всем этим CVS-ным штукам. Зато потом в репе всегда будет гарантированно собирающийся корректный актуальный проект. Итого, у систем контроля версий проблемы конечно есть, но то что описали Вы - имхо, чисто методологическая проблема на уровне организации работы команды.

Вот здесь всё подробно расписано: https://www.altera.com/en_US/pdfs/literatur...ts_qii53009.pdf Вам нужен триггер типа Start/Stop. А Storate Qualifier работает так: по наступлению события запоминает одно состояние всех вытащенных в него сигналов. По следующему наступлению события - снова запоминает. И так, пока не заполнится весь буфер. Самый простой пример - захватить данные с SPI-АЦП, когда событием для захвата данных является сигнал того что сэмпл прочитан. В итоге получите форму АЦПированного сигнала, можно даже график построить там же.

Привет! Такой вопрос - как можно в сигналтапе сделать триггер, который бы срабатывал если сигнал не меняется в течение какого-то времени? Мне надо отловить ситуацию когда сигнал (значение на шине) впервые становится отрицательным в течение, допустим, 5 тактов. Что-то я не нашел возможности проверить средствами сигналтапа значение предыдущего сэмпла (ни в advanced mode, ни в state machine mode). Единственный возможный вариант вижу - использовать конечный автомат с 5-ю состояниями, где в каждом состоянии проверять значение сэмпла и если он подходит условиям триггера - сохранять значения в режиме storage qualifier и переходить в следующее, а в противном случае сбрасывать очередь и уходить в начало автомата. Но получается что-то не то всё равно... Спасибо.

Как раз сегодня ночью меня тоже осенило что возможно нужно питать трансиверные триплеты отдельными PLL-ками. В-общем, после ряда экспериментов оно наконец-то собралось - все 9 трансиверов в дуплексном двухскоростном режиме с поддержкой реконфигурации! То что мне и нужно! Структура проекта получилась следующая: 3 блока, каждый состоящий из: - FPLL с частотой 311.04 - PLL Reconfiguration controller - Трансивер в дуплексном режиме (External PLL - 2 штуки, TXPLL0=622.08, TXPLL1=2488.32, у обоих TXPLL - Bonding x1) 1 общий блок Transceiver Reconfiguration Controller (9 каналов, сгруппированные в 3 группы по 3 канала) FPLL питаются двумя клоками - один питает одну, второй клок питает оставшиеся две FPLL (а каждая FPLL в свою очередь питает по 3 канала каждого трансивера (точнее 6 каналов, т.к. 3 канала по 2 скорости)). Опорный клок для RXCDR - один общий. Клок/ресет для всех реконфигураторов - один общий. Что стоит отметить отдельно: 1. Я сначала пошел по простому пути и просто скопировал (копипастнул) трансивер с FPLL три раза. И оно не собралось. После тушения жопы и подключения мозгов оказалось что ему необходимо иметь не просто разные инстансы трансиверов, а именно разно созданные ядра, пусть и с одинаковыми в моем случае настройками. 2. FPLL тоже нужны в виде именно отдельно созданных IP-ядер. 3. Реконфигуратор трансивера допускается только одним инстансом (но в настройках можно разбить каналы на группы как нужно). Несколько реконфигураторов (например, 3 по 3 канала) - не собирает. 4. Реконфигуратор для FPLL можно использовать в виде одного ядра, просто скопипащенного 3 несколько раз. 5. Запитать 3 FPLL от одного клока не получилось - пришлось задействовать две клоковые ножки. Хочу отдельной строкой сказать спасибо DeadMazay за помощь!

Убрал ресеты, и ресет-контроллер вообще из проекта - ничего не изменилось, ошибки остались те же. Пробовал ставить ALTCLKCTRL перед FPLL - не помогает. После FPLL - не дает, т.к. хочет чтобы клок в трансивер шел с PLL напрямую. Попробовал использовать Transceiver PLL - тоже не помогает, ошибки те же. Есть идеи?

Итак, чего удалось добиться. Проект состоит из: - Ресет-контроллер. - Отдельная FPLL со своим реконфигуратором. - Трансивер в режиме внешней PLL (для двух скоростей использую две TXPLL). - Базовая скорость трансивера 622.08 (и 322.04 у FPLL соответственно). - Реконфигуратор трансивера (количество его каналов тоже меняется в соответствии с трансивером, включен режим MIF). Что получается: При количестве каналов от 1 до 6 - всё собирается отлично. При количестве каналов от 7 до 8 получаю ошибку фиттера: Info (170193): Fitter routing operations beginning Error (170084): Can't route signal "xcvr:inst3|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pma:inst_av_pma|av_tx_pma:av_tx_pma|av_tx_pma_ch:tx_pma_insts[0].av_tx_pma_ch_inst|tx_pma_ch.int_wire_clk[0]" to atom "xcvr:inst3|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[6].gen_bonded_group_native.av_xcvr_native_inst|av_pma:inst_av_pma|av_tx_pma:av_tx_pma|av_tx_pma_ch:tx_pma_insts[0].av_tx_pma_ch_inst|tx_pma_ch.tx_cgb" Error (170084): Can't route signal "xcvr:inst3|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pma:inst_av_pma|av_tx_pma:av_tx_pma|av_tx_pma_ch:tx_pma_insts[0].av_tx_pma_ch_inst|tx_pma_ch.int_wire_clk[0]" to atom "xcvr:inst3|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[6].gen_bonded_group_native.av_xcvr_native_inst|av_pma:inst_av_pma|av_tx_pma:av_tx_pma|av_tx_pma_ch:tx_pma_insts[0].av_tx_pma_ch_inst|tx_pma_ch.tx_cgb" Info (170194): Fitter routing operations ending: elapsed time is 00:00:01 В целом уже лучше ))

DeadMazay, спасибо за советы. Пробую потихонечку различные варианты, пока глухо. Протокол STM-4/16 (622.08/2488.32), соответственно мне нужен режим LTD (LTR и оверсемплинг, получается, что не подходит). От трансивера нужно только принять/передать байты - вся протокольная логика делается дальше за его пределами. Вот такой эксперимент сделал. Один инстанс трансивера, один ресет контроллер, внешняя fpll, реконфигуратор: Попытка 1: - 1..7 каналов - 1 скорость 622.08 - Bonding xN - TX FPLL (311.04) - реконфигуратор (1 интерфейс) Результат: ОК Попытка 2: - 8-9 каналов - 1 скорость 622.08 - Bonding xN - TX FPLL (311.04) - реконфигуратор (1 интерфейс) Результат: ошибка на фиттере Error (14996): The Fitter failed to find a legal placement for all periphery components Info (14987): The following components had the most difficulty being legally placed: Info (175029): auto-promoted clock driver xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pcs:inst_av_pcs|av_pcs_ch:ch[6].inst_av_pcs_ch|av_hssi_tx_pld_pcs_interface_rbc:inst_av_hssi_tx_pld_pcs_interface|pld8gtxclkout~CLKENA0 (13%) Info (175029): auto-promoted clock driver xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pcs:inst_av_pcs|av_pcs_ch:ch[6].inst_av_pcs_ch|av_hssi_rx_pld_pcs_interface_rbc:inst_av_hssi_rx_pld_pcs_interface|pld8grxclkout~CLKENA0 (13%) Info (175029): auto-promoted clock driver xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pcs:inst_av_pcs|av_pcs_ch:ch[5].inst_av_pcs_ch|av_hssi_tx_pld_pcs_interface_rbc:inst_av_hssi_tx_pld_pcs_interface|pld8gtxclkout~CLKENA0 (13%) Info (175029): auto-promoted clock driver xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pcs:inst_av_pcs|av_pcs_ch:ch[5].inst_av_pcs_ch|av_hssi_rx_pld_pcs_interface_rbc:inst_av_hssi_rx_pld_pcs_interface|pld8grxclkout~CLKENA0 (13%) Info (175029): Transmitter channel for I/O xcvr_tx[6] (13%) Info (175029): Transmitter channel for I/O xcvr_tx[5] (9%) Info (175029): Transmitter channel for I/O xcvr_tx[7] (7%) Info (175029): auto-promoted clock driver xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pcs:inst_av_pcs|av_pcs_ch:ch[4].inst_av_pcs_ch|av_hssi_tx_pld_pcs_interface_rbc:inst_av_hssi_tx_pld_pcs_interface|pld8gtxclkout~CLKENA0 (5%) Info (175029): auto-promoted clock driver xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pcs:inst_av_pcs|av_pcs_ch:ch[4].inst_av_pcs_ch|av_hssi_rx_pld_pcs_interface_rbc:inst_av_hssi_rx_pld_pcs_interface|pld8grxclkout~CLKENA0 (5%) Info (175029): Transmitter channel for I/O xcvr_tx[4] (3%) Error (14986): After placing as many components as possible, the following errors remain: Error (175001): Could not place 1 HSSI AVMM Interface, which is within Cyclone V Transceiver Native PHY xcvr Info (14596): Information about the failing component(s): Info (175028): The HSSI AVMM Interface name(s): xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_xcvr_avmm:inst_av_xcvr_avmm|avmm_interface_insts[7].av_hssi_avmm_interface_inst Error (16234): No legal location could be found out of 3 considered location(s). Reasons why each location could not be used are summarized below: Error (178013): Node is not compatible with other nodes placed at the same location either because there are too few available HSSI AVMM Interface locations, or the nodes belong to different transceiver reconfiguration groups, or both. (1 location affected) Info (175029): HSSIAVMMINTERFACE_X0_Y35_N86. Already placed at this location: HSSI AVMM Interface xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_xcvr_avmm:inst_av_xcvr_avmm|avmm_interface_insts[0].av_hssi_avmm_interface_inst Error (175006): Could not find path between the HSSI AVMM Interface and destination HSSI PMA TX Buffer Info (175027): Destination: HSSI PMA TX Buffer xcvr:xcvr|altera_xcvr_native_av:xcvr_inst|av_xcvr_native:gen_native_inst.av_xcvr_native_insts[0].gen_bonded_group_native.av_xcvr_native_inst|av_pma:inst_av_pma|av_tx_pma:av_tx_pma|av_tx_pma_ch:tx_pma_insts[7].av_tx_pma_ch_inst|tx_pma_ch.tx_pma_buf.tx_pma_buf Error (175022): The HSSI AVMM Interface could not be placed in any location to satisfy its connectivity requirements Info (175021): The HSSI PMA TX Buffer was placed in location HSSIPMATXBUF_X0_Y43_N34 Info (175029): 2 locations affected Info (175029): HSSIAVMMINTERFACE_X0_Y11_N86. 3 other HSSI AVMM Interfaces are being routed to this region. Info (175029): HSSIAVMMINTERFACE_X0_Y23_N86. 3 other HSSI AVMM Interfaces are being routed to this region. Картинка с фиттера с удачной компиляции 7 каналов: Как видите, есть полностью свободные два блока. Почему он их не хочет задействовать? Насколько я понимаю из ошибок, он не может подцепить реконфигуратор. Но тогда как? Я вот сейчас попробовал сделать два отдельных 3-канальных инстанса с отдельными реконфигураторами (ну чтобы всё по-честному - один реконфигуратор на один триплет) - так он и их не хочет собирать.

Так удалось кому-нибудь в итоге сделать двухскоростные трансиверы? Да так чтобы все задействовались. Я много чего попробовал, но - безрезультатно. А как-то сообщество молчит. То ли никто этого не делал, то все шифруются )) https://electronix.ru/forum/index.php?showt...=140385&hl= https://www.alteraforum.com/forum/showthrea...&highlight=

Система хорошая, не спорю. Но мне это напоминает схожую ситуацию с Теслой и обычными авто: вот сажусь я в Теслу, и всё в ней действительно круто - динамика, отсутствие топлива, фичи, тачи. Но вот спустя полчаса я еду по трассе 130кмч и мне надо подкрутить радио/кондей. И что я делаю? Правильно - перевожу взгляд на айтач, ищу глазами куда ткнуть, тыкаюсь, возможно не попадаю и тыкаюсь еще раз. А что я сделаю в таком же случае на любой топливной машинке? Правильно - не отводя взгляд и концентрацию от дороги, наощупь теплыми аналоговыми выпирающими крутилочками перенастрою все что мне надо. Также и с выключателем - пришел я с корпоратива в слюни пьяный - стой, блин, шатайся, держи равновесие и тыкайся в эти дисплеи. А с обычным выключателем - херак неглядя! - и включил/выключил свет. Наверное я ретроград, да.

Жорево. Чувствую дикое жорево электроэнергии.... Пожалуй, всё хорошо, если бы не это.

Инкрементная компиляция дает реальный прирост только на больших проектах, где одна партиция занимает под тысячу и более лутов, а проект может компилиться по пол-дня и больше. Вот тогда она выстреливает. На маленьких же проектах смысла в ней нет. И еще надо очень внимательно разбивать на партиции (читайте хендбук, там все хорошо расписано). Например, на границах партиций желательно ставить триггера, чтобы фиттер "по ним" умел их разрезать, не затрагивая внутреннюю логику партиции. То есть, для того чтобы эта фича работала, надо не просто включить волшебный чекбокс, но еще и придерживаться ряда определенных правил построения проекта.

Отличная тема. А вот скажите, удалось ли кому запустить эти с%%ные трансиверы в режиме реконфигурации скорости? Я так и не смог - либо все на одной скорости, либо все на другой. А так, чтобы в процессе работы скорость переключать - не шмогла, даже скомпилить не получается. Такое чувство что ему, если например, используется трансивер в двухскоростном режиме, надо две PLL. Соответственно, т.к. у меня 9 трансиверов должны уметь работать на двух скоростях, то надо иметь 18 PLL. Ну бред же. А использовать внешнюю PLL (fpll, txpll) тоже не получается - не хочет собираться... У меня CV используется, но думаю для Аррии принципы те же.

Используем платку LattePanda и вин10.

На материнке запаян 30-пиновый разъем для подключения дисплея. 30-пинового дисплея с нужным мне размешением нет в природе (максимум 1024х600, а мне надо больше). Но есть куча дисплеев с 34 и 40-пиновыми шлейфами. Вопрос - они все совместимы между собой? Могу ли я сделать микроплатку-переходник с, допустим, 40-ногого в 30-ногий, или же там сам протокол разный? Спасибо.