Разбираюсь с такой проблемой: нужно вклиниться в линию между хостом и устройством.
Сделал тестовый девайс на плис: два транссивера подключены через плис, один к хосту, другой к девайсу. В ПЛИС идет разбор протокола - анализируется в какую сторону передаются данные и соответствующим образом управляются транссиверы.
В принципе такой бутерброд работает: идентификация проходит успешно, устройство отзывается. Но когда начинается интенсивный обмен все глохнет.
Место сбоя пока никак отловить не могу.

Анализ протокола у меня выполняется следующим образом: по положительнуму перепаду линии DM (хоста или девайса) запускается машина состояний контролирущая появление SE0, а после его появления + 2 такта возврат в ждуший режим.
Транссиверы и машина состояний управляются синхронно (тактовый сигнал подстраивается под сигналы с линий DM, DP), правда максимальная задержка между входом-выходом ~60нс.

В чем может быть проблема? Подстройка тактового сигнала и прием/передача небольших пакетов вроде работает нормально (смотрел логическим анализатором), остается протокол - может я в чем-то ошибся?

А зечем такая система "на проход"? Вы планируете изменять некоторые данные в пакетах? Задержка у вас явно великовата, практически на пределе, если я правильно понял алгоритм работы вашей системы.

Задержка еще не большая - скорее всего будет больше (~100 - 150нс). Данные изменяться не будут - передача должна идти по оптике.
По задержкам понимаю что много, но по другому никак - насколько это критично на практике?

Может быть, вам стоит работать на пакетном уровне? Вроде того, как работает USB хаб, у которого интерфейс к ПК высокоскоростной, а устройтво - полноскоростное. Хаб принимает пакет от ПК на высокой скорости, и транслирует его устройству на низкой, и наоборот, приняв пакет от устройства, он его быстро передает в ПК. Только вот я не помню точно, что он там отсылает ПК, пока устройство не ответило. Только у вас не будет канала высокоскростного, а будет просто задержка на 1 кадр. Не знаю, будет ли это работать, как надо. Прочитал в спецификации USB 1.1 (стр.128-129), максимальная задержка хаба как повторителя (вместе с кабелем) не должна превышать 70 нс, а без кабеля - 44 нс, так что ваши цифры явно выходят за эти пределы, отсюда и проблемы.

Я несколько переработал логику и добился стабильной работы с задержкой порядка 60нс, на больших пока не пробовал.
Насчет максимальной задержки хаба я тоже читал, но тут как раз не она имеет решающее значение, а время реакции устройства на запрос (не нашел в стандарте сколько должно быть). Если суммарная задержка будет больше какой-то определенной величины, то работать не будет - иначе есть шансы

Касательно пакетной обработки - такой вариант тоже обдумываю. Жду транссиверов с ULPI - в некотором смысле это даже проще и лучше (High Speed, синхронная работа на 60МГц), но поскольку ULPI для меня темный лес - не знаю получится ли что-нибудь вообще.