otv116

Добрый день. Стоит задача реализовать прием данных от CSI-2 сенсора в Cyclone 10LP. Частота клока примерно 350 МГц, 4 линии. Прием HS данных делаю с использованием altlvds_rx. Т.к. частота высокая, то deserialization factor = 2 не годится. Использую = 4. Мегафункция вставляет pll по этому поводу. Из-за этого появляется проблема. Между пакетами данных шина CSI-2 переходит в Low Power, клок останавливается. Перед передачей пакета, она возвращается в High speed, восстанавливая клок. PLL не успевает залочится, из-за чего прием данных невозможен. Можно было бы отключить у сенсора возможность перехода в LP режим. Но надо сделать без этого. Если у кого есть идеи, поделитесь, пожалуйста.

Для интереса поменял CEBA на CEFA, у которого есть HMC. Ничего не изменилось. Кто шел напрямик, тот и идет. Кто через HMCPHY, так и идет через HMCPHY. -> _Anatoliy см. аттач. Using_Cylcone_V_HMCPHY_DQ_pins_as_high_frequency_inputs.pdf

Пробовал бороться с задержкой сигнала от DQ пина до LAB через HMCPHY. Как и автор топика. alt_lvds работает на клоке, сдвинутом относительно ADC_DCO, чтобы защелкивать данные в нужный момент. В лабе защелкиваю вторым клоком, еще немного сдвинутым. Оба эти клока делаются одной и той же pll в режиме source synchronous. Между ними добавил мультицикл. Все как предлагал des00. Ничего толкового не вышло. Из четырех моделей, по которым ведется анализ (комбинации 0С 85С fast slow), всегда какая-то не проходит. Как я понял, из за того, что путь очень длинный, то его вариации от PVT очень велики в абсолютном значении. Поэтому подогнав под одну модель, херим другую. Еще заметил одну вещь. Я работаю с 5CEBA4F23C7. В нем вообще нет hard memory controller. Но 6 пар из 24 LVDS сигналов АЦП, которые я завел на DQ пины (еще не зная о проблеме), пошли в лаб через HMCPHY. Остальные напрямик, с ними проблемы нет. Смотрел это в отчете time quest.

Добрый день. Делаю прошивку под C-III как раз с АЦП AD9634, который тут упоминался. Все работает нормально, но хочу навести порядок в голове с констрейнами по входу. Вопрос возник по примеру sdc, что предоставил des00. Сначала опишу что сделал сам. Решил тоже не юзать виртуальный клок, а описывать непосредственно от DCO. По даташиту фронт DCO запаздывает за данными на Tskew (0.3 : 0.7 нс). Соответственно: set_input_delay -max -clock [get_clocks {ADC1DCO}] -0.3 [get_ports {ADC1Data[*]}] set_input_delay -max -clock [get_clocks {ADC1DCO}] -clock_fall -0.3 [get_ports {ADC1Data[*]}] -add_delay set_input_delay -min -clock [get_clocks {ADC1DCO}] -0.7 [get_ports {ADC1Data[*]}] -add_delay set_input_delay -min -clock [get_clocks {ADC1DCO}] -clock_fall -0.7 [get_ports {ADC1Data[*]}] -add_delay set_false_path -rise_from [get_clocks {ADC1DCO}] -fall_to [get_clocks {adc1pll|altpll_component|auto_generated|pll1|clk[0]}] set_false_path -fall_from [get_clocks {ADC1DCO}] -rise_to [get_clocks {adc1pll|altpll_component|auto_generated|pll1|clk[0]}] Задержки по плате не учитываю, т.к. АЦП близко к FPGA и их вклад несущественен. В FPGA ставлю PLL в режиме source synchronous и ей подкручиваю фазу, чтобы TQ не ругался. С первой потытки выставил так, что слаки по сетапу большие, по холду - на грани: 2.3 нс и 0.2 нс. Залил в плату - все работает. На плате 4 АЦП, со всеми все ок (на каждый свой pll). Подвинул фазу так, чтобы сбалансировать сетап и холд. Стали в районе 1.2 нс. Заливаю - не годится. Получается что я неверно задал констрейны и в первом случае просто пальцем в небо? ок, беру sdc от des00. Когда сетап на грани - не работает. Возможно сказываются задержки на плате. Балансирую сетап и холд. Оба становятся в районе 0.75 нс. Заливаю - порядок. Как говорится, респект des00. des00, подскажите, пожалуйста, как вы получили цифры -max 1.0, -min -0.4. Может подскажете, где я ошибся в своих констрейнах. Спасибо.

Большое спасибо, andrew_b, за эту находку. Который день мучаюсь с подобной проблемой. С одного пина быстро долетает, с другого тупит. Уже голову сломал. Ну и г.. этот CycloneV, столько гадостей в нем, что его достоинства не всегда их могут перебороть.

Перепробовал все, что можно задать с помощью setsockopt, ioctlsocket, WSAIoctl. Сокет и blocking и nonblocking пробовал. Никакого эффекта. Причем, иногда ACK все таки прилетает быстро. В итоге переделал логику общения с девайсом, чтобы частота запрос-ответов не так сказывалась. Все заработало, а осадок остался.

Добрый день. Мое устройство собрано на основе W5300 (хардварный стек). Им управляет ПЛИС. На нем создан сервер, протокол TCP. Прога на компе постоянно опрашивает один из внутренних регистров ПЛИС. Она использует обычный blocking socket. Было замечено, что если одна и та же прога запущена на компах с WinXP x 32 и Win8 x 64, то на XP опросы происходят почти в 2 раза быстрее. Хотя комп с Win8 гораздо производительнее. В обоих случаях плата была подключена непосредственно к Ethernet порту компа, никаких свитчей и т.п. на пути. Никакими жрущими процессами компы не были загружены. Стал смотреть с помощью WireSharc. Оказалось, что дело во времени прихода ACK от платы в комп. На пакет с данными из компа плата отвечает ACK, а потом, если я запросил данные, кидает пакет с данными. По записанным пакетам с помощью WinSharc видно, что сам процесс обмена платы с обоими компами абсолютно одинаковый. Параметр window не падает до малых значений, оставаясь всегда больше 59КВ. Отличия в том, что на XP ACK прилетает через 400-600 мкс, а на Win8 примерно через 1мс. В сети часто обсуждается проблема, когда комп долго ждет с отправкой ACK, а у меня обратная проблема. Я взял обычный старый хаб, подключил в него всех троих и еще один комп, чтобы им поглядеть, что происходит на линии. Так вот, как при обмене Win8-плата, так и при обмене XP-плата, девайс выдает АCK через одно и тоже время - примерно 10 мкс. Т.е. задержка где-то в Win8. 1.Подскажите, пожалуйста, может это регулируется какими-нибудь настройками сокета или параметрами в реестре. 2.Может ли на это влиять то, что материнка с XP имеет 100 MB Ethernet порт, а c Win8 - 1GB? (Порт на девайсе - 100MB). Спасибо.

Разобрался я в чем дело. soldat_shveyk первым же своим ответом в сообщении 33 все верно описал. После перезагрузки винды начинали прилетать прерывания от сетевухи, на которые надо отвечать FALSE. Сбило меня с толку то, что если я все время отвечал FALSE, то винда все равно перегружалась через какое-то время. Оказалось, что это совсем не связано с моим драйвером. На видюхе сдох вентилятор, она перегревалась и все падало. После его ремонта поведение винды стало предсказуемым - примерно раз в секунду валится чужое прерывание и никому особо жить не мешает. Свое прерывание я определяю прочитав один из регистор моей платы. А вот если я все время возвращаю TRUE, то в случае прерывания от сетевухи она продолжает его генерить, отчего винда и перегружается. В общем, теперь все хорошо. Спасибо всем. Следующий шаг - DMA. Так что, до новых встреч :) Но уже, видимо, не в этой теме.

Чтобы отмести возможные глюки моей платы, воткнул в комп с winXP преходник PCIe -> USB3. Поставил для него мой драйвер (в железо не лазит, а только DbgPrint в функции OnInterrupt). Картина та же - сразу после утановки все тихо, а после перезагрузки винды непрерывные вызовы OnInterrupt. Т.е. вроде как моя железяка ни при чем. Поставил переходнику родные дрова - все нормально работает. Значит и на мамку можно не грешить.

Решил поглядеть, что будет на Win8 x64. При загрузке винды тоже есть вызов OnInterrupt, не вызванный моей платой. Но он только один и после того, как я на него верну TRUE, больше не повторяется. Винда нормально грузится и после этого прерывания корректно работают.

С тостером та же фигня. Тупик, блин.

Идея про неправильный ServiceContext себя не подтвердила. Он приходит правильный. Я в ПЛИС завел счетчик, который инкрементирую каждый раз при вызове OnInterrupt. Смотрю за ним с другого компа через SignalTap. Так вот, в определенный момент OnInterrupt начинает непрерывно вызываться. Мой восьмибитный счетчик наматывает пару кругов, после чего комп виснет. Как будто есть еще какой то источник прерывания кроме моего контроллера в ПЛИС, и его то и надо очистить. Не исключаю, что в драйвере что-то кардинально не так. Уже подумываю откатиться назад на уровень примера toaster и заново потихоньку наращивать функционал.

Перешел я на использование IOConnectInterruptEx, FULLY_SPECIFIED (в XP можно только эту версию использовать). В описании на альтеровскую корку написано, что по включению используются legacy (lane-based) и для использования MSI надо ручками менять биты в одном из конфиг регов. До этого я не дошел, так что фактически продолжаю использовать legacy. IOConnectInterruptEx ничего нового не дал. Все осталось как есть. Есть пару подробностей относительно срабатывания OnInterrupt при старте винды. Ранее я писал, что если я верну TRUE, то винда перегрузится. Это не совсем точно. В обработчике прерывания я лезу в плату и проверяю бит, что это мое прерывание. Так вот перезагрузку вызывает именно обращение к моей плате. Если в обработчике я просто буду делать DebugPrint и возвращать TRUE, то винда загрузится. Но обработчик прерывания будет постоянно вызываться и вызываться, точно так же, как и в случае, когда обработчик всегда возвращал FALSE. Я предполагаю, что перезагрузка происходит потому, что ServiceContext, передаваемый обработчику вовсе не содержит адреса на мой DeviceExtension, поля которого я использую при обращении к плате. Надо будет выкинуть в дебаг его значение. Выглядит, как будто это прерывание никак обрабатывается (не сбрасывается источник) и мне его постоянно присылают. Похожее наблюдается, если в девайсе установить прерывание и не чистить - хоть OnInterruptEx будет возвращать TRUE, обработчик прерывания будет постоянно вызываться, пока в девайсе оно не снимется. Я даже подумал, что может корка глючит. После загрузки винды дернул сигнал запроса прерывания вверх-вниз, но это ничего не поменяло. Вот такие новости.

Спасибо. soldat_shveyk, я делал эксперимент с возвращением постоянно FALSE. При загрузке винды этот как раз и соответствует тому что вы пишете -приложения нет, прерывание не мое. Но винда постоянно вызывает обработчик, пока не зависнет. krux, буду пробовать MSI.

Добрый день. У меня тоже возникли проблемы с прерываниями PCIe. Плата - кит от альтеры на C4. Операционка WinXP x32. MSI-X и MSI не использую. Проявляется проблема в том, что при загрузке винды происходит вызов OnInterrupt, который я прикручиваю в вызове IoConnectInterrupt. Плата точно не генерит это прерывание, т.к. все сигналы запросов зажаты в 0. В обработчике (OnInterrupt) я просто пишу в плату определенное число и вторым компом по SignalTap наблюдаю. Такой вот дебаг. Так вот, если обработчик вернет TRUE, то процентов на 95 комп перегрузится. Если вернет FALSE, то обработчик будет вновь и вновь вызываться. Это даст винде загрузиться, но потом она все равно зависнет или перегрузится. С другой стороны, если включить комп с выключенной платой, а потом ее включить (подать питание) и найти поиском в диспетчере устройств, то она будет работать корректно. Если в ней раскоментарить генерацию прерываний, то они будут нормально генериться и обрабатываться драйвером. Если обработчик вообще не прикручивать с помощью IoConnectInterrupt, то все будет хорошо. Драйвер изначально был сделан для PCI устройства. Там такой проблемы не было. Может стоит пользоваться IoConnectInterruptEx? Но я пока не планирую MSI... Подкиньте, пожалуйста, идеи.