Jump to content

    

RoadRunner

Участник
  • Content Count

    191
  • Joined

  • Last visited

Community Reputation

0 Обычный

About RoadRunner

  • Rank
    Частый гость

Recent Profile Visitors

1806 profile views
  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. Подскажите, пожалуйста, в чем может быть проблема? Спасибо.