Перейти к содержанию
    

RoadRunner

Участник
  • Постов

    191
  • Зарегистрирован

  • Посещение

Весь контент RoadRunner


  1. А на счет 1923ВС025/1923ВС015 НТЦ "Модуль" что-нибудь известно? Или это все одно и то же с 1923КХ028?
  2. Всем доброго времени суток! Новую тему решил не создавать, т.к. вопрос в продолжение старой проблемы. Вопрос следующий: нужно ли после отправленного в трансивер ПЛИС кадра данных менять код IDLE2 на IDLE1 в зависимости от значения disparity в конце кадра? По идее, disparity считается в кодировщике 8b/10b, т.е. на уровне PCS. Но он уже в ПЛИС находится, а IDLE2 или IDLE1 вставлять после пакета, нужно решить еще до этого. Читал, что в некоторых трансиверах поэтому замена IDLE2 на IDLE1 выполняется внутри кодировщика 8b/10b, чтобы отправителю, т.е. MAC-уровню, этим повторно не заниматься. Но имеется ли такая функция в трансиверах Cyclone 10 GX, я не нашел. Подскажите, кто знает. Благодарю.
  3. Благодарю! С материалом по первой ссылке знаком, даже пробовал повторить, но того ядра флеш-контроллера в Квартусе 19.2 для CYclone 10 уже нет. А вот вторую посмотрю, спасибо! Но меня больше сейчас волнует, загрузится ли ПЛИС с моей флешки с зашитым туда rbf-файлом? Зашить флешку то, я уже так смотрю, можно на худой конец и на другой, уже работающей плате с процессором, и перепаяв ее потом на плату с ПЛИС. Криво, конечно, но зато быстро и понятно. А вот загрузится ли?
  4. Всем доброго времени суток! Подскажите, можно ли Cyclone 10 CX загрузить с флешки AT45DB641E в режиме Active Serial? Можно ли для прошивки такой флеш использовать уже имеющиеся в Квартусе мегафункции Serial Flash Loader, или придется городить свой переходник JTAG-SPI? А когда удастся флешку тем или иным способом прошить, загрузится ли с нее ПЛИС? Буду признателен за советы.
  5. Все оказалось весьма загадочно: затыкание phy наблюдается только при почти непрерывной отправке пакета длиной 81 байт (без контрольной суммы). При этом каждая такая посылка приводит к сбросу конфигурации, возобновлению автопереговоров phy. Байтом больше, байтом меньше и все уже начинает работать - ничего не сбрасывается, phy начинает передавать эти пакеты и принимать приемные. Если уменьшить периодичность посылки пакета, скажем до секунды, то и этот "несчастливый" пакет длиной 81 байт начинает проходить. Что это - аномалия, или все-таки проблемы с цепями питания/тактовой частоты, вызывающие нестабильность и затыки в работе микросхемы phy, мне сказать трудно. Хотелось бы конечно, чтобы такой магический в плохом смысле пакет был единственным. Но что-то мне подсказывает, что я не просто по чистой случайности наткнулся на этот единственный пакет: скорее всего, тут дело в сочетании периодичности отправки и длины отправляемого пакета, и тогда таких ситуаций может быть много. В любом случае, всем большое спасибо за советы! Буду благодарен, если поделитесь соображениями по поводу того, что у меня получилось: может быть, кто-то встречался с таким, наблюдал подобное поведение на этом или других phy.
  6. С автопереговорами я, кажется, разобрался: они такие же как на 1000BASE-X, только сам регистр конфигурации phy другой - биты другие. Это объясняет, почему по моему мнению там шла белиберда - я биты интерпретировал не по той доке, надо было так, как sorok-odin написал постом выше. Но Acknowledge бит там на том же месте, поэтому, учитывая что я его посылаю по стандарту, автопереговоры проходят и так. Но самое интересное в другом. Как только проходят автопереговоры, я на автомате начинаю непрерывно передавать пакеты, т.е. на максимальной скорости. Это прокатывало у меня, когда я работал с SFP-модулем: если все было исправно, сразу после прохождения автопереговоров свич начинал непрерывно моргать. А с этим phy, как писал выше, ничего не моргает - не проходит передача и прием при этом тоже не проходит. Так вот, я ради эксперимента отрубил непрерывную передачу после конфигурации, и приемные пакеты начали проходить! Короче, выглядит так, как будто я phy засыпаю передающими пакетами, и он отказывается как их передавать, так и принимать входящие. Сейчас буду прореживать передачу, посмотрим, в этом дело или нет..
  7. Хм.. А я ориентируюсь на стандарт IEEE Std 802.3 clause 37 - глава про 1000BASE-X auto-negotiation. В доке на phy вроде написано, что в соответствии с ним сделано. Может, тут собака зарыта.. Как-то путано в доке на phy написано: с одной стороны пишут, что кодировка автопереговоров 1000BASE-T такая же как в 1000BASE-X, а с другой - что автопереговоры 1000BASE-T основаны на clause 28 и 40, а это вообще автопереговоры для 100Мбитного ethernet.. Тот регистр, который Вы привели, это из еще какого-то вида автопереговоров - SGMII Auto-Negotiation. Короче, у меня пока в голове каша.. Буду разбираться. Если кто может разложить, что тут где и для чего, буду очень благодарен.
  8. Развязывающие конденсаторы не помогли.. Интересно, что phy по SGMII выдает значения конфигурационного регистра 0x9801 при воткнутом ethernet-кабеле и 0x0801 при выдернутом ethernet-кабеле. Если им верить, то при воткнутом ethernet-кабеле имеет место Link_Failure. Но судя по индикации светодиодов на ПК и на phy, линк вроде есть. И непонятно, как это интерпретировать..
  9. Такой вопрос еще возник: а что этому phy отправлять по SGMII во время автопереговоров, кофигурирования? Я отправляю Config_reg = 0x0402, т.е. полный дуплекс и выставляю acknolegment bit. Может быть, ему что-то другое надо отправлять?
  10. sorok-odin, да.. видимо дело в чем-то другом: исправил все Ваши замечания (кроме первого про резистор с допуском). Даже перепаял на внутреннее питание SGMII - не помогает. Мистика какая-то.. В любом случае, большое спасибо Вам за советы, буду дальше пробовать.
  11. Что значит "не толерантны"? Не совсем понял. Вот это уже интересно. Я как-то по описанию решил, что это точно выход - детектирует какой-то там сигнал. А он - действительно вход! Только я из даташита так и не понял, что он все-таки делает. Можете объяснить?
  12. Не совсем понял.. Я осциллографом вижу, что на ножке S_VTT один вольт то есть точно. Правда, размах дифференциального сигнала S_OUT при этом раза в полтора-два меньше, чем размах на S_IN, т.е. трансивер ПЛИС из этого напряжения питания 1.03В делает большую амплитуду сигнала - около вольта, чем 88E1112 - около полувольта. Но опять же даже при этих уровнях конфигурационный обмен байтами проходит успешно, т.е. уровни распознаются, их хватает.
  13. Да, я сейчас пытаюсь провести такой эксперимент.. Но больше от безысходности. Потому что логики в этом не вижу: конфигурация то по этому же SGMII между ПЛИС и 88E1112 проходит, значит достаточно питания, уровни распознаются. Да и по документации там диапазон напряжений от 0.95В до 1.5В можно подавать.
  14. Схема по идее уже рабочая, т.е. опробована и успешно работает, но без ПЛИС, а с другим 88E1112, когда выход SGMII от одного подается на вход другого. К сожалению, той рабочей платы у меня на руках нет, и поэкспериментировать с ней, сравнить уровни сигналов я не могу. Из различий только уровень питающего напряжения на SGMII: на работающей он - 1,2В, на этой он - 1,03В. Ну и Config[4] на работающей был запаян на землю, а тут он выведен на Status[1]. Но Config[4] уже вручную перепаяли обратно на землю, так что этого различия уже нет.
  15. Всем доброго времени суток. Вопрос по микросхеме трансивера Marvell 88E1112. Использую ее в режиме 1000BASE-T, на MAC-уровне соединяю ее по SGMII с ПЛИС Cyclone 10 GX (через встроенный трансивер). Успешно проходит конфигурация между внутренним трансивером ПЛИС и 88E1112 - 88E1112 начинает слать IDLE-последовательность (BCh 50h). Линк между 88E1112 и Ethernet-линией (физический MDI-уровень) устанавливается. Но на этом все: приемные пакеты из линии не доходят до SGMII (я вижу это на осциллографе). В ПЛИС при этом как шла IDLE-последовательность на приеме, так и идет. Пробую передавать из ПЛИС наружу - то же самое: на линии SGMII видно, что ПЛИС пытается передавать пакеты, но на выходе 88E1112, в линии Ethernet все тихо. Выглядит так, как будто 88E1112 не пропускает пакеты между MDI и SGMII. Подскажите, пожалуйста, в чем может быть проблема? Спасибо.
  16. Да, все так: 8 и 64 бита. Исправил глупую ошибку: пока возился с двумя трансиверами, затактировал сигналтап со считыванием данных из одного трансивера, клоком от другого трансивера. Короче, поменял клок - стало вроде все правильно считывать. Насколько я глазом вижу.. Наверняка можно будет утверждать только после подсчета и сравнения контрольной суммы пакетов. Отпишусь по результатам. new123, еще раз спасибо за помощь! Особенно, что надоумили на счет покупки б/у на авито: оперативно удалось и карту, и sfp-модули нужные приобрести для экспериментов за приемлемые деньги =)
  17. Есть rx_enh_data_valid - я так понимаю, о нем речь. Он вообще постоянно в единице, что тоже как-то странно. Еще сигнал rx_enh_blk_lock постоянно в единице. Не знаю пока, что он означает - буду сейчас разбираться. У меня еще несколько времянок сигналтапа стабильно не проходят (я на сигналтапе все это смотрю), но не могу понять приемные данные это или нет. Поставлю доп. регистры, посмотрю, может в этом дело.
  18. Я по ходу облажался с sfp-модулем и сетевой картой. Сказывается мое дилетанство в этой теме: у меня какой-то хитрый sfp - с одним оптическим выходом, где совмещены tx и rx, прием и передача на разных длинах волн. Я думал, что это стандарт такой на 10G по одному оптоволокну полный дуплекс гнать. А на карте соответственно два выхода под оптику означает два таких полнодуплексных канала. Но в общем это хрень полная: пришлось заменять sfp-модули на нормальные, где два выхода под оптику, один под прием, другой под передачу. При подключении к карте пошли 07070707 и поднялся rx_ready и rx_locktodata. Беда теперь только в том, что пакеты, насколько я могу судить, принимаются неправильно. Т.е. я вижу, что отправляется по сети из сетевой карты, но на выходе трансивера эти данные распознать не могу. Что-то он принимает, но явно не то, что было послано. Теперь вот вопрос: это дело в том самом ограничении по скорости на Циклон 10 и поэтому данные битые идут, или дело в чем-то другом. Непонятно еще, в чем именно выражается это ограничение. Как он вообще определяет SR у него линк или LR? В любом же случае на sfp-модуль работает. Это уже от sfp-модуля зависит, на какое расстояние он добьет..
  19. Падает. Он по идее и не может быть поднят, пока резет в единице. Так что я его даже не смотрю пока. Периодически падает/поднимается: как резет поднимается, rx_ready падает, и наоборот. Такое наблюдается даже при не подключенном входе. Видимо, наводку ловит и кратковременно лочится, потом опять слетает. оба в единице, т.е. "full bandwidth" вроде по доке, как надо
  20. rx_locktoref, как выяснилось, не поднимался из-за того, что cdr reference clock в настройках был 644МГц, а подавал я на него 156МГц (по аналогии с 1G конфигурацией). В общем поменял настройку на 156МГц, и эта проблема решилась. Два трансивера теперь нормально работают друг на друга, лочатся по данным, передают и принимают 0707070707070707. Странность возникает при работе на 10GBASE-R сетевую карту: лок по данным исчезает, и соответственно поднимается rx_digitalreset. При этом линк на карте горит зеленым, т.е. прием 0707070707070707 картой проходит, судя по всему, успешно, а вот трансивер от карты не принимает ничего, получается. Тут еще такая неприятность выяснилась: как пишут, циклон 10 оказывается 10G по бэкплейну не поддерживает - только до 6,6G. 10G - это только для chip-to-chip communication. Я пока пытаюсь все запустить на 10G. При этом трансиверы друг на друга лочатся и все вроде нормально принимают через sfp-модули и внешнюю оптику, т.е. вряд ли с картой не заводится из-за этого ограничения - я же просто один конец оптического кабеля перетыкаю из sfp-модуля трансивера в карту.. Кто-нибудь знает, в чем конкретно это ограничение выражается?
  21. Да я вот и чувствую, что мне третий вариант светит, ибо loopbackа у Циклона по ходу нет (я не нашел во всяком случае). И если не найду по-быстрому какой-нибудь рабочий интерфейс на 10G.. Не посоветуете, кстати, какой-нибудь свич или карту на 10GBASE-R за приемлемую цену?
  22. Хреново то, что того конца пока нет: трансивер пока в воздухе висит. Как он что-то там принимает, я не понимаю. rx_digitalreset пока в единице, видимо, потому что и lock_to_ref, и lock_to_data пока не поднялись. lock_to_data то понятно - данных еще нет. А вот lock_to_ref то вроде от внутреннего клока должен завестись.. но тоже почему то не заводится.. Я было к сетевухе хотел подключить, а она по ходу только 10GBASE-X поддерживает. Получается, что только два трансивера друг на друга. С одной стороны хорошо - стандарт с точностью до буквы не надо поддерживать. С другой стороны, можно такого самопала наворотить.. от стандарта то все-таки легче отталкиваться.
  23. Пока использую tx_pma_div_clk_out с делителем 33 - там как раз генерятся нужные 156,25МГц. Я так понял, он для этого и задуман. Им тактирую и tx_coreclkin, и rx_coreclkin; трансивер вроде ожил. Только принимает постоянно 9С00000001 даже при висящем в воздухе rx_serial_data.. надо разбираться. В общем пока выводы делать рано. По ходу дела отпишусь, как такая схема тактирования работает. new123, большое спасибо за помощь!
  24. Странно только, что на картинке tx_clkout = 257.8125 MHz, но по факту там 322.25 шурует. Я так понимаю, потому что битность PCS-PMA не 40, а 32 в настройках. При этом это стандартные настройки пресета 10GBASE-R. Либо не имеет значения 32 или 40, либо тут ошибка какая-то
×
×
  • Создать...