BSACPLD

Как раз наоборот. Пока мы в хороших отношениях с Китаем перекрыть их невозможно, т.к. это чисто китайские чипы производимые на чисто китайских заводах. На них даже документации открытой нет, а Fudan это лишь торговая марка. По факту одни те же чипы могут поставляться под кучей торговых марок. Реально же это детище одного из китайских аэрокосмических институтов.

Нам пока приходили рабочие. Внешне все ОК, но есть подозрение, что это отреболленый Б/У - уж больно цена "в обход санкций" низкая...

"Импортозамещение" - переход на китайскую элементную базу. Именно так. Сегодня есть, а завтра может не быть.

Залить могу. Вопрос в лицензии - она предоставляется только после покупки чипов у АО Эпсилон или ООО Феникс Электроникс.

Мы покупали примерно за 10К рублей. Оригинальный сейчас около 100 баксов. Так что примерно одинаково. Что касается трансиверов, у ТС их и в помине не было - там Gowin. Насколько я понимаю, у Pango нет возможности работать из Vivado. А если использовать фирменную среду Fudan (Procise), то и у них нет проблем с трансиверами 🙂

Vivado или Procise на выбор. По поводу поставки обращайтесь в АО "Эпсилон" и ООО "Феникс Электроникс".

Fudan. JFMK50 - почти полный клон Artix-7, отличия минимальны. Как раз 50К.

Речь шла не про полярность, а про реверс. Т.е. 0 <-> 0 1 <-> 1 2 <-> 2 3 <-> 3 или 0 <-> 3 1 <-> 2 2 <-> 1 3 <-> 0

У них ещё и архитектуре "баг". В отличии от FX3 нельзя адресовать приёмный буфер, DMA memory to memory отсутствует, следовательно многоканальный приём довольно трудно реализуем. Я в итоге делаю zero copy подставляя в endpoint нужный указатель. Только вот пока не понятно как быть если понадобится делать очереди пакетов для USB3.0...

Я в ПЛИС loopback делал. И смотрел что принимается и что отправляется обратно. "Прием" я имел ввиду со стороны ПЛИС/ILA. Я смог убрать только передавая данные вообще без пауз и на клоке от CH569. Просто затактировал передатчик и выходной клок (через ODDR) от клока с CH569.

На прием у меня тоже нормально принималось. Была проблема именно с передачей. Пробовал, но лог. анализатором не смотрел - проверял косвенно по порче данных при совпадении фронтов переключения и выборки. Я у себя со стороны ПЛИС сделал выбор фронта через Virtual I/O. У Вас Xilinx? Там в IDDR есть параметр который задаёт в каком такте выдавать данные. Может быть в этом дело? До лог. анализатора только завтра смогу добраться.

Коллеги, вопрос кто уже разводил PCIE на Fudan. Вы делали line reverse при разводке? На первой версии платы под m.2 у меня было без line reverse и все прекрасно работало. Хотя по спецификации PCIE line reverse нужен. Вот я и не пойму, то ли у меня компьютер сделал line reverse при установке линка, то ли у Fudan он уже сделан на уровне распиновки. В примерах схем у Fudan, которые я получил уже после разработки и изготовления своей платы, PCIE тоже без line reverse. Сейчас просто сделал новую версию платы уже под обычный PCIe x4 слот и думаю, оставить как есть или сделать line reverse...

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

Не совсем так. При нулевом идёт прием в RB_HSPI_RX_ADDR0, но при входе в прерывание этот бит уже установлен в 1. Т.е. при обработке в прерывании если данный бит 1, нужно брать данные из RB_HSPI_RX_ADDR0.

UPD. Похоже в Dual DMA режиме бит RB_HSPI_RX_TOG в регистре R8_HSPI_RX_SC "инверсный"... Во всяком случае хотя бы получилось сделать loopback по маршруту USB3.0->CH569->FPGA->CH569->USB3.0. Теперь осталось разобраться с Flow-Control для USB3.0/HSPI...

Перед первым. Остальные варианты не проверял - сделал буферизацию на пакет и непрерывную передачу. Попробую при случае, но не раньше чем разберусь с более критичными багами. На той же что и прием - loopback клока через BUFG/ODDR. 100 МГц

Действительно баг в кремнии. В общем на диаграмме в datasheet есть кусок где HTVLD падает на некоторое время, когда данные ещё не готовы к отправке. Так вот если он упадет прямо перед передачей CRC, контроллер корректно примет первый пакет, а остальные будут вызывать ошибку RB_HSPI_NUM_MIS. Также столкнулся ещё с парой багов: 1. При сброшенном RB_HSPI_TX_TOG_EN второй пакет содержит какие-то левые данные. Нужно обязательно использовать Dual Buffer режим для передачи, тогда передача работает корректно. 2. С Dual Buffer режимом на прием есть баг - при приеме самого первого пакета некорректно выставляется бит отвечающий за выбор буфера. При приеме последующих пакетов такого бага нет - там уже корректно переключается. Возможно, что эти баги также связаны с "таймингами" подачи сигналов на CH569W.

Пока нет. Вторая плата у моего коллеги - завтра возьму попробовать.

Оригинальный Кит от WCH + плата Wukong Board с Artix-7. Очень сомневаюсь в проблемах с таймингами, т.к. клок, данные и управляющие сигналы размещены в I/O и работают через ODDR/IDDR - Tco, Tsetup/Thold одинаковые и я могу спокойно менять фазу на 180 градусов со стороны ПЛИС. Плюс нет ошибок CRC - значит данные в CH569W защёлкиваются корректно. И если и в ПЛИС и в CH569W поменять фазу на 180 градусов поведение не должно меняться т.к. временные соотношения должны оставаться плюс/минус такие же, а оно меняется.

Нет. Но сейчас словил другой "прикол". Поменял фазу клока HRCLK - ожидаемо появились ошибки CRC. Поменял момент семплирования через бит RB_HSPI_RCK_MOD - ошибки CRC ожидаемо исчезли и также исчезли ошибки RB_HSPI_NUM_MIS при приеме последующих пакетов. Но при этом данные в приемном буфере стабильно смещены на размер заголовка (4 байта). До этого заголовок удалялся в самом первом пакете, а в последующих был мусор. P.S. Капец он глючный... А я ещё в свое время ругался на то, что FX3 глючный 🙂 P.P.S. Ошибки с RB_HSPI_NUM_MIS все же есть - просто не сразу появляются... Но при этом в приемном буфере не мусор, а заголовок + пакет.

Последним - подсмотрел через ILA при передаче из CH569W в ПЛИС. Я там loopback сейчас реализовал - все пришедшие байты кладутся в FIFO и отправляются обратно без изменений. И я проверял и через ILA и через регистры - инкрементируются. А через кого общались с техподдержкой WCH? Запросы на официальную почту с сайта просто игнорируются.

Не понимаю в чем проблема с флагом RB_HSPI_NUM_MIS... В ILA вижу что пакеты отправляются корректно, но в CH569W выставляется данный флаг при приёме всех пакетов кроме самого первого и принятые данные смещены по адресам ровно на 4 байта (размер User Header). У Вас нет рабочего примера приёма пакетов по HSPI? Примеры от WCH судя по всему не рабочие... Во всяком случае для USB3.0 в них была куча ошибок и пришлось переписывать довольно большой кусок кода...

В общем пока результат следующий. Сделал loopback через FPGA, содержимое пакетов проверяю через ILA. 1. CH569W->FPGA все ОК. 2. FPGA->CH569W пакеты отсылаются корректно, но CH569W принимает только первый пакет, при приеме следующего пакета выставляется флаг ошибки RB_HSPI_NUM_MIS. Не совсем понимаю, что это за не совпадение sequence number - делал распечатку через PRINT, после приема RB_HSPI_RX_NUM увеличивается на 1 как и должен... И ещё один момент. Мне нужно пробрасывать пакеты с HSPI в два различных Endpoint USB3.0. В какой Endpoint кидать пакет можно определить только после приема пакета по его заголовку. Можно ли указать адрес приемного буфера HSPI для DMA USB3.0 непосредственно перед отправкой пакета в Endpoint чтобы не тратить время на копирование данных из буфера HSPI в буфер Endpoint, или адреса буферов Endpoint можно настраивать только во время начальной инициализации? Как при этом корректно организовать Flow-Control чтобы не пытаться отправить в Endpoint новый пакет пока старый ещё не успел отправиться?

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

Я имел ввиду, что slave не может мгновенно опустить HTRDY в 0 после того как HTREQ и HTVLD перйдут в 0, если до того как slave успеет опустить HTRDY в 0 master снова выставит HTREQ получится неоднозначная ситуация с готовностью slave к приёму - либо он готов, либо просто не успел убрать HTRDY.