spbroma

А как тогда следует подключать? Всё, что попадалось мне на глаза -- через PHY, но пока будет разводиться плата я буду разбираться с изернетом через SFP и хотелось бы максимально безболезненно переехать потом на новое железо. Трансформатор ведь и так обеспечивает гальваническую развязку с кабелем, как еще защититься можно? Единственно, что тогда надо будет ПЛИС располагать максимально близко к разъему, тогда как PHY можно откинуть на разумное расстояние по плате.

Здравствуйте! У меня есть отладочная плата от Xilinx с ПЛИС, которая соединена гигабитным трансивером с SFP-разъёмом, куда устанавливается SFP-RJ45 трансивер и начинает дыщать Ethernet. Далее, собираюсь разработать плату, на которой ПЛИС поднимет через RJ45 1G Ethernet напрямую, без SFP. Как понимаю, есть два варианта: 1. Установка между ПЛИС и RJ45 микросхемы PHY, при этом ПЛИС-PHY связаны ( R )GMII, а PHY-RJ45 уже дифпарами 2. Из гигабитного трансивера в ПЛИСе с помощью корки выходит уже дифпара, но для подключения её к RJ45, нужно пропустить сигнал через трансформатор для гальванической развязки. Верно ли я всё понимаю и каких граблей не учёл?

Если добавить 1 бит, можно будет левыми 6 бит кодировать строку, а правыми - столбец.

Можешь еще здесь что-нибудь полезное найдете (стр 74): http://www.xilinx.com/support/documentatio...es_SelectIO.pdf

Спасибо :) Надо будет, все-таки собраться духом. Сейчас я вообще временно на другую задачу переключился. Но, я так понимаю, что вы говорите об обработке прерываний драйвером. А это меньшая из зол, как создавать эти прерывания - вот где проблема.

Добрый вечер, добро пожаловать в наше уютное обсуждение:) Во-первых, да, именно этот проект я и зашил. Сперва я запустил тестовый драйвер от виндрайвера, убедился, что устройство определяется в системе, что в память можно записывать и считывать. То есть, работающая болванка есть. На этом этапе я решил отложить часть ПЛИС и заняться драйвером. Как можно заметить по другим моим топикам на этом форуме, я пошел против системы и SM-а :) и соблазнился на рекламируемые прелести WDF. На данный момент это закончилось тем, что отладчик подключается к рабочему компьютеру только когда моё устройство не подключено, что странно и бесполезно. На этой ноте я отчаялся и решил посмотреть и вовсе в сторону Виндрайвера и разобраться в том, что же такого удобного и классного у них есть. Судя по описанию API действительно, всё радужно и хорошо. Тем более, что пример собирается и работает, а код его не выглядит пугающе. Как я понимаю работу дальше, необходимо научиться создавать на плате прерывания и тут мы погружаемся в пучину корки. Тестбенч, о котором вы говорите, как-то не попадался мне на глаза, так что ничего прокомментировать не могу. Пока с трудом понимаю, как можно использовать готовый пример для создания собственного проекта. Однако обрабатывать и генерить все сигналы вручную представляется ещё большим мраком и я немного в растерянности. Еще хотелось бы отойти от AXI, а то разбираться ещё и в нём надо. Вообще, мне достаточно научиться выкидывать прерывания, по которым драйвер читал бы определенную область памяти и всё. А переход от PIO к DMA, видимо, возможен не скоро, так как вообще не понимаю, как сейчас его реализовать.

Мне кажется, он уже как-то измеряет и ему нужно отличать реальный источник сигнала от мнимого. А здесь без второй такой "камеры" как минимум не обойтись, я думаю.

То есть у вас какая-то акустическая фазированная решетка есть? Хотя бы из двух микрофонов, или как? В общем, думаю, эта ссылка вам поможет немного: http://www.labbookpages.co.uk/audio/beamfo...g/delaySum.html Как я понимаю, вы хотите сделать аналог подобного устройства? http://vpk.name/news/81413_sistema_tochnog...protivnika.html

Хотя в то же время в незапамятные времена я пробовал установить какой-то базовый драйвер виндрайвера, которые он автоматически сгенерил, для общения с устройством, как с контроллером памяти, и он прекрасно записывал-читал данные с платы.

Похоже, действительно, проблема в конфигурации PCI на плате. Если она выключена, отладчик прекрасно цепляется к ядру, даже после перезагрузок и проч. Стоит загрузиться с включенной платой, отладчик не цепляется. Выключаем комп, отключаем плату, загружаемся - отладчик снова в деле. При этом устройство без установленного драйвера, определяется просто как "такое-то устройство без драйвера". Однако драйвер на него ставится без проблем. Бррр...

То есть, сценарий следующий? 0. Тестовый компьютер выключен. Рабочий пытается подключиться отладчиком. 1. Включение тестового компьютера. 2. На каком-то этапе отладчик подключается. 3. После того как устройство инициализировано в системе, можно запускать установку драйвера.

А чем вы определяете расположение мнимого источника звука?

Изменил тип на мультимедийное устройство, пока что ведет себя так же: устройство определяется, драйвер устанавливается, отладчик не подключается

Во время загрузки не успеваю за списком уследить :) Есть ли более гуманные методы? Хм. Сейчас попробую сконфигурить его как мультимедийное устройство. Просто "контроллер памяти" предлагался коркой по умолчанию и я решил не трогать это.

Да, если нет в диспетчере устройств, виндрайвер тоже не видит. Да я тоже, это в рамках поиска и проб.

Я сам удивился этому,но при включении устройства при запущенной винде она прекрасно его находит и при обновлении устройств в диспетчере задач появляется либо как прописано в драйвере, либо как неизвестное устройство - PCI-контроллер памяти, как и указано в корке на ПЛИС. Но не всегда. Иногда не появляется даже если включено до запуска винды. (И именно тогда срабатывает подключение отладчика к тестовому компу) Да, выглядит как-то бредово :) А о каком драйвер-визарде вы говорите? Кстати, если в inf-е прописать id оборудования как Root\Test, то наличие/отсутствие соединения всё равно каким-то образом связано с тем, определяется устройство на тестовом компьютере (в данном случае как раз как неопознанный контроллер памяти) или нет.

В том-то и странность. Когда соединение устанавливается, устройство не определяется в системе :) (неужто это клятый kmdf) Включаю-выключаю его, диспетчер устройств молчит, в консоли отладчика тишина. Стоит перезагрузиться так, чтобы соединение пропало, устройство благополучно подключается и инициализируется. Не уверен насчёт причинно-следственной связью между соединением и инициализацией. Но корреляция очевидна. UPD: Когда соединение происходит, а устройство, соответственно, не цепляется -- драйвер, естественно, не устанавливается Когда устройство находится в системе, к системе не получается подключиться отладчиком.

Попробовал и заметил вот что: Если на тестовом компьютере выполнить bcdedit -debug on и перезагрузить, то отладчик подключится, а устройство также пропадёт. После очередной перезагрузки устройство появляется, а подключение не выполняется.

Здравствуйте, Вопрос относительно подключения отладчика к тестовой машине. Вот я из студии развернул драйвер на тестовой машине, т.е. компьютеры общаются и хорошо друг друга понимают. Теперь запускаю Windbg, ввожу порт, ключ (у меня они общаются по ethernet) и... Using NET for debugging Opened WinSock 2.0 Waiting to reconnect... Через студию (Driver -> Test -> Configure computers) меняю параметры подключения (порт и/или шину), применяю их на тестовом компьютере, и после некоторых шаманств с этими параметрами отладчик успешно подключается. Однако, на тестовом компьютере из диспетчера пропадает моё устройство. После перезагрузки тестового компьютера устройство появляется, отладчик вновь не может подключиться. Как показало гугление, не я один сталкиваюсь с подобным и каждый находит какое-то свое магическое решение данной проблемы. Была ли у кого-нибудь подобная проблема и в чем вообще тут может быть дело?

Да, ей я проверял. Просто в самом начале, когда я не понимал совсем ничего, я городил в инф-е какие-то чудовищные конструкции (и тогда я его ещё не проверял) и после шаманств и удалением драйвера, перезагрузкой, повторной попыткой установки и прочего безобразия в различных комбинациях, худо-бедно драйвера в системе устанавливались и устройство определялось ими. И, похоже, что-то где-то в реестре, связанное с данным id записалось не так и все стало ставиться криво. Поменял ID, накатил такой же свежий драйвер и вуаля.

Проблема решена! Перед этим я совершал какие-то хаотичные действия с параметрами inf-файла и установкой/удаления драйвера на тестовом компьютере, в результате чего драйвера вставали черт знает как. Сейчас перепрошил плату другим device id и все починилось. Драйвер встал без проблем, теперь можно со спокойной душой разбираться дальше. PS: Не зря в последний день перед праздниками на работу пришёл :)

Оффтоп: Частично от таких проблем может предохранить использование нормальных текстовых редакторов с автодополнениями. Я вот работаю на Vivado, а код пишу в Sublime Text. Перепробовал разные редакторы, в т.ч. "заточенные" под верилог, но удобнее и быстрее ST(+2 верилоговских дополнения) всё равно не нашёл.

Если отличаются результаты симуляций, это может быть результатом внезапных для тебя оптимизаций. Советую посмотреть на схему в синтезе и имплементации, попробовать понять что пропало и кто виноват. Если найти виновника удастся, можно вбить костыль в нужную строчку: (* dont_touch = "true" *) Подробнее: http://www.xilinx.com/support/documentatio...o-synthesis.pdf Но лучше разобраться в причинах и сделать как надо.

Ясно :)

Что-то мне подсказывает, что я еще не продвинулся так далеко, где были бы видны различия :) Быть может, вы всё ее можете подсказать? В шаблоне для KMDF драйвера есть заполненный inf-file с указанным ID устройства Root\"DriverName" Когда я поменял его на ID своей платы (PCI\VEN_10EE&DEV_7083) разворачивание намертво повисло на этапе DefaultDriverPackageInstallationTask. Подождав минут 10, прервал отладку, студия вылетела и перезапустилась, тестовый компьютер я ресетнул. После загрузки, я обнаружил, что драйвер встал-таки на моё устройство. Но при повторной попытки развертывания драйвера он проходит все этапы, заканчивая DriverRemoval с ошибкой. А дальше начинается чехарда. Логика подсказывает, что он не может удалить драйвер. Очевидно, потому что он криво встал.