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

MAC controller для Nexys 3 на Spartan 6

Отсутствуют клоки из трансивера. Причем проверил питающие, ресет...

 

1. На Вашей схеме ресет - инверсный. Вы это учли?

2. Вы попробовали на плате запустить существующий проект с Ethernet? Или хотя бы поразбираться с его исходниками?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. На Вашей схеме ресет - инверсный. Вы это учли?

2. Вы попробовали на плате запустить существующий проект с Ethernet? Или хотя бы поразбираться с его исходниками?

 

Запустил трансивер с помощью готового блока с Microblaze. По работе проблем нет. С исходниками проекта (сокет Беркли) более менее понятно.

Подскажите пожалуйста, если chipscope'ом снять данные с пинов ПЛИС - трансивер, и по аналогии сделать свой HDL модуль, возможно ли запустить Ethernet?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Запустил трансивер с помощью готового блока с Microblaze. По работе проблем нет. С исходниками проекта (сокет Беркли) более менее понятно.

Я бы на Вашем месте для начала попытался разобраться ПОЧЕМУ <блок с Microblaze - трансивер> - работает, а <Ваш блок - трансивер> - нет.

 

Подскажите пожалуйста, если chipscope'ом снять данные с пинов ПЛИС - трансивер, и по аналогии сделать свой HDL модуль, возможно ли запустить Ethernet?

Конечно возможно. При этом:

- приемную часть все равно придется делать самому;

- передающую часть Вы сделаете ту, аналогию которой снимете анализатором (т.е. частично теряется универсальность передающего узла).

Поэтому думаю что все таки надо добиться чтобы трансивер выдавал такты в Вашем проекте, и тогда Вы сможете реализовать все свои фантазии...

Изменено пользователем olegras

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Конечно возможно. Но думаю, что все таки надо добиться чтобы трансивер выдавал такты в Вашем проекте, и тогда Вы сможете реализовать все свои фантазии...

А зачем снимать пины чипскопом, если Вам с исходниками все понятно?

 

Под исходниками я понимаю собранную систему софт-контроллер плюс блок MAC controller. И написанный Си шный код для работы этого контроллера. В Сишном коде реализован сокет Беркли.

У меня получилось соединение на другой плате Altera со Stratix II. Там я разобрался как реализован стек на Ниосе и по аналогии поднял Микроблейз в Xilinx.

Проблема в Алтере была в том, что там стек реализован на RTOS, а это в свою очередь накладывает ограничения по скорости обмена PC - FPGA (может я ошибаюсь?).

Ограничения вызваны, на мой взгляд тем, что контроллеру необходимо время для чтения/записи данных во внутренние буферы. Даже если контроллер тактируется 100 МГц, скорость формирования пакетов все равно низкая.

Самый простой пример. Записываю во внутренний регистр в контроллере 0 и единицу. Вывожу содержимое регистра на оссцилограф. Наблюдаю меандр 11 МГц. (около 10 тактов для записи/чтения регистра, при тактировании контроллера 100МГц).

 

Так возникла необходимость написать свой MAC Controller. Под рукой оказался Spartan 6.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В Сишном коде реализован сокет Беркли.

Это я уже понял после того как спросил :laughing:

 

Так возникла необходимость написать свой MAC Controller.

Свой МАС - это правильно.

 

 

Включите питание Вашего Нексиса, замерьте уровни на ногах трансивера MODE [2:0] (15, 10, 11). Может по умолчанию он стоит в Power Down (110)? Хотя по схеме вроде не так, но все-таки...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

чет я не понял как медленность ядра проца приводит к необходимости написания своего внешнего блока от проца не зависящего?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

чет я не понял как медленность ядра проца приводит к необходимости написания своего внешнего блока от проца не зависящего?

совершенно верно, другого варианта я просто не вижу

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

нет...

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

 

Берем микроблайз, к нему есть 3 вида МАК контроллеров, готовых, писанных ксалинксом. Бесплатный считает контрольные суммы в проце, и работает медленно для случая TCP, но более старшие и платные работают до гигабита и считают контрольные суммы пакетов внутри. При этом они подключаются по MII к физике, и имеют возможности ее конфигурить и прочее..

 

Использование данных маков позволяет вам напрямую пихать данные в них из микроблайза, и данные прямок лезут в сеть. И в этой ситуации я не понимаю как то что микроблайз медленно работает с шиной, заставляет вас переписывать эти маки? Даже если вы это сделаете, проц то от этого не начнет быстрее шиной шевелить? И в нем не начнет быстрее крутиться ТСР стэк от того что вы перепишите Мак...

 

Вот желание сделать железный стэк я еще могу понять для ускорения процесса, но опять же в этом случае не надо переписывать МАК! надо делать доп надстройку...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Использование данных маков позволяет вам напрямую пихать данные в них из микроблайза, и данные прямок лезут в сеть. И в этой ситуации я не понимаю как то что микроблайз медленно работает с шиной, заставляет вас переписывать эти маки? Даже если вы это сделаете, проц то от этого не начнет быстрее шиной шевелить?

 

благодарю за ответ, я не совсем точно выразился. речь идет не о доработке готового проекта с процессором, а о написании своего mac controller чтобы вообще уйти от работы с медленным процессором

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

благодарю за ответ, я не совсем точно выразился. речь идет не о доработке готового проекта с процессором, а о написании своего mac controller чтобы вообще уйти от работы с медленным процессором

Неправильно формулируете...

При чем тут МАС? МАС вообще вещь тупая, что положили, то и передает. А вот контроллер UDP или IP, который будет передавать свои пакеты в МАС - вот он и может конкурировать с процессором.

Но и то...

Кто Вам мешает сделать аппаратные формирователи заголовков? Вот их и прицепите к процессору, как порты. А всю логику обмена делать на процессоре куда как удобнее...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При чем тут МАС? МАС вообще вещь тупая

Правильно. Вот ТС и пытается реализовать этот тупой МАС.

 

А всю логику обмена делать на процессоре куда как удобнее...

Ну если не хочет человек процессор...

Как я понял, ему сейчас нужна помощь для начала запустить трансивер.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Неправильно формулируете...

При чем тут МАС? МАС вообще вещь тупая, что положили, то и передает. А вот контроллер UDP или IP, который будет передавать свои пакеты в МАС - вот он и может конкурировать с процессором.

Но и то...

Кто Вам мешает сделать аппаратные формирователи заголовков? Вот их и прицепите к процессору, как порты. А всю логику обмена делать на процессоре куда как удобнее...

Mac я рассматриваю как аппаратно реализованый HDL модуль для формирования пакетов по UDP протоколу например.

реализация на базе автомата, когда последовательно на ноги трансивера подается сформированныи Ethernet кадр для передачи по UDP. это случай передачи.

 

Правильно. Вот ТС и пытается реализовать этот тупой МАС.

 

 

Ну если не хочет человек процессор...

Как я понял, ему сейчас нужна помощь для начала запустить трансивер.

совершенно верно. если я правильно понял медленная скорость работы процессора с шиной не позволяет разогнать Ethernet. если не прав буду рад любому объяснению.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Mac я рассматриваю как аппаратно реализованый HDL модуль для формирования пакетов по UDP протоколу например.

реализация на базе автомата, когда последовательно на ноги трансивера подается сформированныи Ethernet кадр для передачи по UDP. это случай передачи.

Это на бумаге красиво. А в жизни, когда нарисуете блок-схему станет все несколько по-другому.

ну, для начала пакет не влезает в память на кристалле. (это в общем случае широковещательный пакет, а он может быть 1,5 К) А места для пакетов надо 4... " на передаче и 2 или более на прием... Значит начинаем делить внешнюю память, настраивать ДМА...

Потом не всегда бывает дуплекс и свитч напрямую, а если пакет побился и надо заново его передавать? Что тогда? Опять автомат?

А если начали прием пакета в память и получили ошибку по приему. Кто будет перенастраивать ДМА?

 

Вы для начала нарисуйте блок-схему и только потом говорите, что процессор не нужен.

Что касается терминологии, то рекомендую придерживаться общепринятой. МАС - это только уровень пакетов Ethernet и не более. А то, что Вы еще "намечтали", это уже не МАС, это другой уровень. Так и называйте его соответственно. Тогда Вас будет легче понять...

Удачи!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Правильно. Вот ТС и пытается реализовать этот тупой МАС.

 

 

Ну если не хочет человек процессор...

Как я понял, ему сейчас нужна помощь для начала запустить трансивер.

совершенно верно. если я правильно понял медленная скорость работы процессора с шиной не позволяет разогнать Ethernet. если не прав буду рад любому объяснению.

 

 

не влезает в память на кристалле. (это в общем случае широковещательный пакет, а он может быть 1,5 К) А места для пакетов надо 4... " на передаче и 2 или более на прием... Значит начинаем делить внешнюю память, настраивать ДМА...

Потом не всегда бывает дуплекс и свитч напрямую, а если пакет побился и надо заново его передавать? Что тогда? Опять автомат?

внутренней памяти должно хватить, в том же Spartan 6 18 килобайт аппаратно реализованных блоков ram, пакеты рассматриваю только по 1.5 кб

 

режим работы трансивера задается автоматически на плате.

 

задачу вижу следующим образом: на начальном этапе сформировать кадр и отдать на ноги трансивера по его же клокам, кадр считывать с буфера, потом двигаться дальше

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

неправильно вы мыслите, вы попробовали одну конкретную систему и сделали вывод.

 

Правильно так:

езернет физика - мак - ДМА - память - ДМА - мак - езернет физика.

В таком варианте вы вообще не зависите от процессора, и скорость передачи зависит фактически только от железа.

При этом мак может посчитать контрольную сумму пакетов, может даже сделать первичную фильтрацию данных по мак адресу.

 

Сейчас такую систему можно собрать из готовых чужих блоков, и с ней я бы соревноваться не стал. Дальнейший уровень разбора данных по ТСР это уже другой разговор, и как вам правильно сказали поддержать полный стэк в железе - мрак! Там ведь и DHCP, и ARP запросы, и пинги, и фрагментирование пакетов, и сборка, и оконный режим приема...

 

 

В железе можно сделать формирователь UDP пакетов, но не более... ну вернее сделать можно все, но стоит делать не более...

 

 

задачу вижу следующим образом: на начальном этапе сформировать кадр и отдать на ноги трансивера по его же клокам, кадр считывать с буфера, потом двигаться дальше

 

а если с вами это сделает кто-то еще на другом конце езернета че будет? Вы учитываете что на МАК уровне решаются конфликты и арбитраж сети?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...