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

Jackov

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

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

  • Посещение

Репутация

1 Обычный

Информация о Jackov

  • Звание
    Местный
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

3 286 просмотров профиля
  1. 1986BE3T и Ethernet

    Да читал конечно. Вот только где же взять такой девайс чтобы кадр выдавал строго по команде с чёткозаданной задержкой? А роутеры, насколько знаю, кадры не выдают, они их коммутируют. Да я бы там тоже, как в смайлике, постучал бы кому-нибудь по голове, только всё бесполезно. Изначально ПО писал не я, мне поручили его довести до ума. В вопросы какие там стоят делители частоты и режимы работы я ещё пока не углублялся, в ближайшее время конечно же всё перепроверю. Но в роутере ничего поменять нельзя, остаётся только менять на самих устройствах. Ну автоопределение, не цепляйтесь к словам.
  2. 1986BE3T и Ethernet

    ETH_BRG не вижу, а вот ETH_CLK и ETH2_CLK таки есть. У этого микроконтроллера два Eth, можно попробовать с одного на другой передать и одновременно во встреч пустить. Но скорее всего и так не получится, пока во второй Eth будешь загружать кадр, первый уже передаст. У нас самый простой коммутатор, не факт что настраиваемый, а если да то я не знаю как, но скорее всего нет. Т.е. хотите сказать, что в процессе работы слетает автоподстройка? Интересно, нужно проверить.
  3. 1986BE3T и Ethernet

    Есть теория, что проблема возникает во время одновременного приёма и передачи кадра. А что бы это воспроизвести, это надо по какому-то общему сигналу запускать передачу и на внешнем устройстве и на этом. Как такое провернуть пока непонятно. И ещё что интересно, кадры гоняем через обычный китайский ширпотребовский коммутатор, какой-то D-link, так вот через коммутатор сбоев больше чем без него. С коммутатором сбои как-то волнами идут, вроде нормально, потом пошла волна частых сбоев, потом опять нормально. Напрямую сбои тоже есть, но заметно меньше, может 1, 2 в минуту. А разве MAC не частотой ядра тактируется?
  4. 1986BE3T и Ethernet

    Используется РК486-8ДС-25000К. И если я правильно понимаю от резонатора тактируется только блок PHY. Сбоит же приёмник в МАС. Ещё раз акцентирую внимание, по отдельности и приёмник и передатчик работают нормально. Но когда начинается совместная работа иногда, видимо при наступлении каких-то условий, в приёмнике возникают сбои.
  5. 1986BE3T и Ethernet

    Есть errata от 21 года, но там про такие проблемы не упомянуто. Искал, ничего интересного не нашёл.
  6. 1986BE3T и Ethernet

    Есть кто работал с указанным микроконтроллером изделием? Что-то не удаётся добиться устойчивой работы ethernet-а, есть не иллюзорное подозрение, что проблема в самом изделии. Работаю в линейном режиме, если запустить только приёмник и посылать на него кадры в хаотическом порядке то всё более менее нормально, но если параллельно с этим запустить передатчик то приёмник начинает сбоить, не всегда и не часто, но сбоить. Выражается это в следующем: 1. иногда не врабатывается прерывание по приходу кадра; 2. иногда не записывается слово статуса перед кадром, например оно может быть нулевым, из-за чего становится невозможным определить размер принятого кадра, а значит и начало следующего, а значит дальнейшее считывание кадров не имеет смысла и приходится сбрасывать приёмник; 3. иногда бывает так что указатели чтения (регистр R_Head) и записи (регистр R_Tail) не равны друг другу, что говорит о том что в буфере приёмника есть принятый кадр, но счётчик принятых кадров (разряды R_COUNT регистра STAT) при этом равен 0, чего в теории быть не может; 4. регистр Dilimiter пришлось поставить в значение 0х1Е00 это, наверно, единственное значение при котором приёмник нормально работает, проверял меняя предпоследнюю цифру. Кроме того, обнаружил что на некоторых экземплярах сброс приёмника через бит RRST регистра G_CFGh не сбрасывает R_Tail, R_Head сбрасывает, а R_Tail - нет, т.о. получается так что, после сброса приёмник содержит несчитанные кадры. И ещё, заметил, что прерывание от приёмника не всегда запрещаются с первого раза, т.е. я сбрасываю 26-ой бит регистра ICER находящегося по адресу 0хE000E180, читаю его, а он не сброшен. Приходится сбрасывать в цикле до тех пор пока не прочитаю оттуда ноль. В общем что со всем этим делать непонятно, формируется устойчивое мнение, что ethernet на данном изделии вообще не удастся нормально запустить.
  7. Всё сильно зависит от техпроцесса производства полупроводников, те самые нанометры, т.е. надо по конкретным микросхемам смотреть. Кроме того, если правильно помню, буферы с третьим состоянием работают как раз медленнее чем простые логические элементы. Не помню с чем это связано, но сигналу тяжелее выйти из высокоимпедансного состояния в логический уровень чем просто переключаться из 1 в 0 и обратно.
  8. Сейчас ни чего такого не решаю, просто ударила мысль в голову вот и спросил.
  9. Они все санкции поддерживают, деваться некуда. Когда начинал, был опыт только с Альтерой, да и как по мне альтеровский САПР дружелюбнее чем у Зайлинкса, начинающим начинать легче. Нет, не решена. Вопрос звучал так: Как уже было сказано ранее буферов с Z-состоянием внутри ПЛИС нету. Так что либо элемент ИЛИ, либо в общем случае, как было предложено, мультиплексор. И да, прочитав 3 страницы я так и не понял, если есть возможность взять пиратский ISE, то в чём проблема взять пиратскую Винду?
  10. А если сделать финт ушами и пустить сигнал с ноги на ногу?
  11. Не совсем понял что требуется, но похоже здесь поможет элемент ИЛИ. А вот так лучше не делать. Есть определённые правила синхронного проектирования. Строго рекомендуется их придерживаться:
  12. Ещё раз посоветую канал посвящённый разработке под ПЛИС https://www.youtube.com/@Jack0v/playlists
  13. Для первоначального погружения в тему предлагаю ознакомиться вот с этим каналом https://www.youtube.com/@Jack0v/playlists
  14. Угу. Ну сложно сказать как будет на самом деле, возможно зависит от внутренней схемотехники триггера, но если метастабильное состояние и возникнет, то на очень короткий момент времени. Т.е. такой переход скорее всего надо рассматривать не как 1 -> метастабильное состояние -> 0, а как просто не очень резкий переход 1 -> 0. По большому счёту не важно как схема войдёт в сброс, важно сколько она в нём пробудет и как из него выйдет. И да, малость неправильно сказал Надо не за входом D следить, хотя и так тоже можно. Но лучше следить за тем чтобы момент снятия асинхронного сброса не совпал с активным фронтом тактового сигнала с запасом в обе стороны.
  15. Тут получается так что в один момент времени и reg0 сбрасывается (меняет состояние) и на out приходит активный фронт тактового сигнала по которому он запоминает состояние reg0, которое как раз меняется в этот момент. На лицо вероятность возникновения метастабильного состояния. Нет, не возникнет, но триггер который всегда установлен в 0 на практике никому не нужен. Просто нужно во время активного уровня сигнала асинхронного сброса, с запасом до и после, обеспечить на входе D гарантированный 0. Могу посоветовать посмотреть эти видео, думаю многие вопросы отпадут сами собой: FPGA (ПЛИС) - 1000 правил синхронного проектирования FPGA (ПЛИС) - Особенности синхронизации FPGA (ПЛИС) - Вопросы общего сброса
×
×
  • Создать...