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

[Boris_TS]

Тему создал в этой ветке конференции, ибо надо заменить старое ПЛИС решение на новое или на что-то вообще другое.

Как лучше модифицировать имеющееся решение:

Имеется система сбора данных - ящик 19 дюймовый 4U. Внутри ящика самопальный cross на 10 плат расширения и 1 плата управления. От платы управления шел самопальный канал связи (6 диф. пар по 50МГц) к PCI плате (32бита 5V), втыкаемой в обычный компьютер.

Назрела необходимость изменить ввод данных в компьютер (отказаться от самопальной PCI платы, да и аналогичного канала передачи данных).

Cross и пачки различных плат расширения переделывать ой как неохота, а поэтому имеем такое схемно-убогое решение: от каждой платы расширения (ввода и обработки данных) к
блоку управления тянется по 6 LVPECL пар (если быть более точным, то Xilinx LVPECL аля Virtex-E/Spartan-2E) - по 4 к плате расширения и по 2 к блоку управления, итого 60 пар.

Груды LVPECL пар, заходящих на блок управления, подаются на 2 XCV50E-7PQ240, каждый Virtex-E занимался работой со своей половиной шины. Первый мультиплексировал поточные данные от плат расширения и заливал эти данные в PC (по однонаправленной шине). Второй обрабатывал запросы от PC (записать конфигурационную информацию/считать оную из плат расширения). При таком построении системы получалось 2 независимых шины, простое решение в ПЛИС (почти что одни мультиплексоры и коммутаторы). Особенностью аппарата является то, сбор данных необходимо производить с привязкой к пространственной координате, т.е. весьма шустро реагировать на изменения скорости подвижного объекта, в котором собран измерительный комплекс - в том числе и из-за этой особенности стандартные платы ввода данных в PC не использовались (может быть зря ?).

Конструктивно блок управления может быть полноразмерной ISA (PCI) платой – с местом проблем нет – задняя планка ISA (KHPC) Bracket.

Поток (по, как я это безобразие назвал, «Control Bus») данных управления в обе стороны не превышает 1 Мбит/с.
Поток данных (по, как я это безобразие назвал, «Data Bus») от плат расширения к PC пока не превышает 16 Мбит/с, но хочется развивать (потихонечку) одну из модификаций плат расширения... и раздуть поток до 105 Мбит/с, а затем и до 210 Мбит/с (из-за возрастающих пожеланий заказчика).

Думаю надо бы переделать передачу данных на Ethernet (а лучше бы с полной поддержкой TCP/IP). А вот тут и возникают вопросы как бы это получше сделать... Т.к. изделия не серийные, то можно использовать компоненты (в т.ч. ПЛИС) ценой в несколько тысяч рублей.
1. Может собрать почти как и было: поставить 2 Startan-3AN TQ144 (теоретически запаять BGA корпуса можно у соседей, но разводкой печатной платы под BGA пока не занимался, а чувствую, что это не делается с наскоку)... и приторочить к каждому Spartan’у по некоей фиговине (у которой с одной стороны какая-то шина, а с другой Ethernet (а лучше сразу TCP/IP) - знать бы еще как оные зовутся ?) ?
2. А может быть поставить одну ПЛИС и собрать там могучий мультиплексор, разгребающий данные к/от Ethernet ?
3. Может есть другие варианты - получше гигабитного Ethernet ???

P.S. работаю только с ПЛИС Xilinx. С EDK пока еще не работал...

[rezident]

После прочтения "много слов" у меня возник вопрос: а зачем там вообще PC? Дополнить систему DSP, который будет выполнять основную рутину, а PC использовать в качестве терминала и системы хранения данных, связав его с DSP любым удобным низкоскоростным интерфейсом.

[Boris_TS]

После прочтения "много слов" у меня возник вопрос: а зачем там вообще PC? Дополнить систему DSP, который будет выполнять основную рутину, а PC использовать в качестве терминала и системы хранения данных, связав его с DSP любым удобным низкоскоростным интерфейсом.

А PC как раз для хранения и отображения записываемых данных (а грамотный опператор по отображаемой картинке может на ходу поменять усиления и т.п. параметры системы сбора данных). Собственно говоря DSP не нужен - нет обработки данных в блоке управления, да и не встречал я DSP с таким количеством последовательных входов/выходов (к каждой плате хотя бы по 2 двунаправленных SPI порта, а плат 10)...

А вот по поводу "любым удобным низкоскоростным интерфейсом" - об этом и вопрос - чем соединить с PC и как попроще (удобней для разработчика) прицепить это что-нибудь ?

[murmel1]

Рекомендую задуматся о USB - сложность на порядок меньше, чем у Ethernet, море примеров. Скорость можно получить 20 Мбайт/сек.

[Boris_TS]

Рекомендую задуматься о USB - сложность на порядок меньше, чем у Ethernet, море примеров. Скорость можно получить 20 Мбайт/сек.

Направление интересное...
Но как с этим USB 2.0 работает PC ?.. Что-то мне подсказывает, что интенсивная работа с USB сопряжена с периодическими замираниями компьютера. А мне необходимо непрерывное гладкое графическое полноэкранное отображение вводимых данных (ну где-то 1280x1024 @ 100Гц - картинка весьма нагруженная). С PCI всё работает нормально... благо Bus mastering помогает.
Насколько будет мешать USB 2.0 с потоком 15МБайт/с работать WindowsXP (пока программа написана под эту ОС) ? (Вопрос родился не на пустом месте: у соседей не получилось нормально связать Cypris и PC по USB... периодически подзамирает машина, а в TaskManager'е это ну никак не отображается,.. правда достаточно хорошо отражается в помощи NuMega True Time. Может, конечно, у моих знакомых ребят руки кривые - поэтому так и работает. А поэтому мне и интересно на что именно стоит тратить время - с каким стандартным интерфейсом разбираться ?)

[rezident]

Собственно говоря DSP не нужен - нет обработки данных в блоке управления

Вот потому и говорю, что надо в самом блоке данные обрабатывать и не тащить наружу столько линий с чудовищным траффиком. В PC пускай уже готовые скриншоты пересылаются. А обратно только команды, где чего переключить и подстроить. Интерфейс лучше Ethernet. Если основная обработка данных будет в самом блоке, то возможно, что даже и 10Мбитного хватит. Ну или 100Мб уж точно с головой. С USB под Windows не нужно связываться.

[SM]

Может, конечно, у моих знакомых ребят руки кривые - поэтому так и работает.

Во-во. Потому как передача по протоколу USB Mass Storage Device (девайс "прикидывается" внешним накопителем, из которого читают данные) при потоке 54 Мбит/с совершенно не заметна на компе с виндой. А использовать как мост между компом и ФПГА при таких потоках как раз Cypress и очень удобно с его 48-мегагерцовой 16-битной шиной (на СY7C68013) и возможностью "завести с пол-оборота" в режим Slave FIFO используя экзамплы.

[zltigo]

Рекомендую задуматся о USB - сложность на порядок меньше, чем у Ethernet, море примеров. Скорость можно получить 20 Мбайт/сек.

Все с точностью ДО НАОБОРОТ кривизна и сложность на порядок больше, нежели у классического и простого, как лом Ethernet.

[des00]

Груды LVPECL пар, заходящих на блок управления, подаются на 2 XCV50E-7PQ240, каждый Virtex-E занимался работой со своей половиной шины. Первый мультиплексировал поточные данные от плат расширения и заливал эти данные в PC (по однонаправленной шине). Второй обрабатывал запросы от PC (записать конфигурационную информацию/считать оную из плат расширения). При таком построении системы получалось 2 независимых шины, простое решение в ПЛИС (почти что одни мультиплексоры и коммутаторы). Особенностью аппарата является то, сбор данных необходимо производить с привязкой к пространственной координате, т.е. весьма шустро реагировать на изменения скорости подвижного объекта, в котором собран измерительный комплекс - в том числе и из-за этой особенности стандартные платы ввода данных в PC не использовались (может быть зря ?).

эти 60 пар завести на фпга, взять арм9 с 100/10000 эзернетом и внешней шиной, подцепить к этой фпга. А там уже что душа пожелает.

[SM]

Все с точностью ДО НАОБОРОТ кривизна и сложность на порядок больше, нежели у классического и простого, как лом Ethernet.

Тогда уж посоветуйте нам, темным, такое же простое решение для Eth, сравнимое по цене и пропускной, как CY7C68013 для USB. Wiznet? Когда я ним имел дело, он по производительности далек был от CY.

[Boris_TS]

На всякий случай опишу чуть подробнее работу имеющихся шин.
От блока управления (так я прозвал большую интерфейсную плату) к каждой плате расшинения через Cross идут следующие LVPECL пары:
Clock - 50 или 100 МГц,
dFrame - синхроимпульс для начала очередного цикла сбора данных и отгрузки данных с предыдущего цикла,
dData - данные от платы сбора данных.
cFrame - синхроимпульс, обозначающий начало переда данных по шине управления,
cFData - данные шины управления к плате сбора данных,
cBData - данные шины управления от платы сбора данных.
Так сказать подобие 2 SPI портов.

В настоящее время данные dData от 10 плат сбора данных, мультиплексируются в блока управления и отгружаются потоком по 3 парам (Clock, dFrame и dData) в PCI плату компьютера.
Шина управления работает аналогичным образом, только инициатором является компьютер.
Вышеприведенные потоки (текущий - 16 Мбит/с, желаемый для сладкого будущего - 105 Мбит/с и для очень сладкого будущего - 210 Мбит/с) - это предельные суммарные потоки от всех плат сбора данных.
В принципе, пока достаточно сделать аналог 16 Мбит/с передачи данных, но по какому-либо стандартному интерфейсу. А т.к. не хочется переделывать интерфейсную плату при развитии датчикового хозяйства, то были указанны у предельные цифры потоков более которых не понадобиться даже при самых больших хотелках заказчика.

Вот потому и говорю, что надо в самом блоке данные обрабатывать и не тащить наружу столько линий с чудовищным траффиком. В PC пускай уже готовые скриншоты пересылаются. А обратно только команды, где чего переключить и подстроить. Интерфейс лучше Ethernet. Если основная обработка данных будет в самом блоке, то возможно, что даже и 10Мбитного хватит. Ну или 100Мб уж точно с головой.

К сожалению PC используется не только для отображения данных, но и для накопления оных. Поэтому не удается на него сгрузить только задачи отображения данных / управления системой сбора данных. Поток управления действительно смешной от силы 1Мбит/с.
Пытаюсь немного отбрыкаться от DSP не потому, что он мне не нравиться, а потому, что хочу более точно представлять как его лучше использовать, а я пока еще не смог представить как его органично вписать в систему.

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

Для имеющегося вида данных есть простенький алгоритм компрессии - сжимающий их в 15-20 раз. К своему стыду признаю, что у меня не дошли руки встроить целиком данный алгоритм в систему сбора данных, т.к. достаточно быстро выяснилось, что для улучшения работы комплекса в целом необходимо менять принцип сбора данных, а при новом подходе требуется и другая компрессия потока.

эти 60 пар завести на фпга, взять арм9 с 100/10000 Ethernet’ом и внешней шиной, подцепить к этой фпга. А там уже что душа пожелает.

Звучит достаточно заманчиво, но т.к. с ARM еще ни разу не приходилось сталкиваться, прошу дать ссылки на то откуда лучше начинать знакомство с этим вариантом.
Если у кого есть опыт работы с MicroBlase и Ethernet на базе встроенного MAC ядра Virtex-4, поделитесь своими соображениями чего лучше: MicroBlase + V4 Gigabit Ethernet или вышепредложенный ARM9 ?

Все с точностью ДО НАОБОРОТ кривизна и сложность на порядок больше, нежели у классического и простого, как лом Ethernet.

Замечание интересное, но вот вопрос заключается именно в том при помощи каких микросхем (или даже сборок) заменить текущее корявинькое решение. Может посоветуете чего ?

P.S. извиняюсь за "очень много слов", но вот никак не удаётся в 2 словах выразить свою большую округлую мыслю.
Как говорил выше, цена микросхем/сборок в несколько тысяч рублей за штуку не отпугивает... (для сравнения, себестоимость PCI платы до кризиса составляла более 5 килорублей - их (или даже большую сумму) можно смело потратить на любой чип/модуль)

[zltigo]

CY7C68013 ... Wiznet....

Да, как все запущено. Оказывется Вы на самом не имеете представления не только об Ethernet, но и о USB , поскольку оперируете на уровне внешних приблуд к микроконтроллерам содержащих некие дополнительные микроконтроллеры и "готовые" стеки. По нынешим временам вполне приличное железо, как USB, так и Ehernet MAC несут на себе даже микроконтроллеры стоимостью в единицы баксов. Про старшие модели микроконтроллеров и говорить нечего. Сравнивать и делать "выводы" о сложности из сравнения помянутых Вами костылей для не желающих ничего знать о USB/Ethernet просто неразумно.

[murmel1]

помянутых Вами костылей для не желающих ничего знать о USB/Ethernet просто неразумно.

Имя, сестра, имя !

Вопрос без обид и наездов - расскажите, как по вашему сделать несложный Ethernet. Хотя бы в двух словах о том, на чем делали.
Я в свое время сделал USB на CY78000. Весь логический протокол USB (пакеты, handshake и т.д.) реализовавыл самостоятельно в ПЛИС. На CY78013 все делается на порядок проще. Есть способ реализовать еще проще? А про Ethernet что можно сказать ?

Спасибо !

[SM]

Оказывется Вы на самом не имеете представления не только об Ethernet, но и о USB
...
Сравнивать и делать "выводы" о сложности из сравнения помянутых Вами костылей для не желающих ничего знать о USB/Ethernet просто неразумно.

Не делайте тупых ложных выводов на пустом месте. Я реализовал и УСБ high speed в ASIC, и Ethernet MAC делал, но правда до серии второе не дошло. И я отлично знаю, что такое УСБ, и что такое Ethernet до самого нижнего уровня вплоть до схемы трансивера на транзисторном уровне. Точно также как и знаю, что засовывать маки и УСБы в ПЛИС нет никакого смысла (за редким исключением, как например отсутствие места на плате под мост), когда есть внешние решения, удешевляющие систему и упрощающие разработку.

Повторяю вопрос еще раз, причем уже расширено. Назовите теперь не только мост Ethernet<=>ПЛИС, но и мост USB<=>ПЛИС, хоть как то сравнимые по цене при пропускной способности не меньше, чем у CY7C68013 и не требующие написания дополнительного софта (изменение VID/PID у CY в готовом софте я за написание софта не считаю).

P.S. И я не думаю, что несмотря на Ваш статус в форуме, Вы имеете право на клевету. А утверждение (не предположение, а утверждение) о том, что я знаю, а что нет, при том ложное, я расцениваю именно так.

На CY78013 все делается на порядок проще. Есть способ реализовать еще проще?

Сложно сказать проще ли (на мой взгляд проще, чем 68013 нет ничего), но есть вариант использования мостов USB-IDE/ATA, навроде TUSB6250.
И не слушайте тех, кто скажет, что запихать все УСБ (кроме трансивера) в ПЛИС проще, чем использовать готовый мост. Это провокация! Это гораздо сложнее, особенно когда дойдет до сертификации в USB-IF....

[RobFPGA]

Приветствую!

На USB в таких системах лутше не закладыватся. USB - это для быта.

Я бы взял все таки одну FPGA. можно и Spartan3 , но лутше Virtex4 FX серии, +SDRAM +внешний PHY.
Ethernet в такой конфигурации поднимается не сложно - все зависит что вы хотите получить
-полный TCP/IP стек это Microblaze или PowerPC + lwIP.
- или некое его подмножество - PicoBlaze или совсем без проца, чисто апаратно.
Я например в свое время делал обработку данных радара на Spartan3s400 со 100Mb Ethernet каналом.

Если ставить внешний ARM и делать Ethernet через него то проблемой может быть перекачка потока из FPGA->ARM (в очень сладком будущем)

Успехов! Rob.

[rsv]

проще, по моему, все таки ethernet сделать через жирную плисину. сейчас делаем плату обработки на virtex5 lx50t, так вот, пока железо еще не готово, мучаю отладку ml505. на ней, после некоторого бодания с софтом от xilinx вообще, и с ЕДК в частности удалось поднять web-сервер на микроблейзе со скоростью в 5 мегабайт в секунду (т е 10 мегабайт передавал за 2 с), и по моим прикидкам это пока еще не предел.
правда, конечно, возникает вопрос цены: около 1K$ за виртекс и печатная плата под bga слоев на 12-14

[Михаил_K]

Здравствуйте!
Добавлю своего мнения

Когда-то, очень давно я разрабатывал канал связи с похожим девайсом по USB. Разработку вели на вышеупомянутом CY7C68013. Как было справедливо замечено, очень удобная вещь. Проводили измерения скорости записи, которая (это наверное не вызовет сомнений) была ограничена сверху именно РСком. Так вот - получили 40 МБ/с. И это при использовании bulk точки.
Не забывайте о том, что существуют изохронные передачи, которые как раз и предназначены для создания канала с гарантированной пропускной способностью.
Вопрос о замирании машины, при записи непрерывного потока существует. Но элементарно решается с помощью FIFO.

Так вот.
Канал получился очень удобным, быстрым, надежным.

Не так давно, при разработки нового изделия мои коллеги перешли на гигабитный ethernet. С протоколом tcp/ip. Мало того, что по сложности реализации это оказалось гораздо сложнее, так и менее устойчиво. Хотя скорость смогли увеличить раза в два.

ИМХО. Для ваших задач проще, лучше, дешевле использовать USB. И не забывайте и о том, что когда вы сделаете ethernet устройство, вам придется еще и решать проблему множественного доступа (с разных компов).
И не слушайте тех, кто говорит что USB это для быта.

[SM]

И не слушайте тех, кто говорит что USB это для быта.

+Много. Системы сбора, обработки и документирования данных с USB-интерфейсом успешно работают и в авиации, и в экстренных службах, и еще много где.

[zltigo]

не требующие написания дополнительного софта....

Эквивалентно - скажите, как сделать так, что-бы ничего не делать? Дайте мне мои любимые протезы . Ну не нужны они. В данном случае для Ethеrnet, который Вы судя по Вашей реакции не отличаете от TCP/IP на самом деле даже UDP/TCP/IP не нужны - голые фреймы, максимум с чем-нибудь типа IEEE 802.3 в заголовке. Со стороны PC RAW Socket и вперед.

И не слушайте тех, кто скажет, что запихать все УСБ (кроме трансивера) в ПЛИС проще, чем использовать готовый мост. Это провокация! Это гораздо сложнее, особенно когда дойдет до сертификации в USB-IF....

1. USB в даном случае нужно пихать не в FPGA а куда подальше...
2. Реализация MAC Ethernet вполне обыденное дело, да и из внешние навешивать никто не мешает, не говоря уже о том, что просто берется любой 32битник по вкусу с MAC на борту.
3. И никаих проблем с совершенно ненужными USB наворотами, "сертификациями", "драйверами" и их конфликтами.

И не забывайте и о том, что когда вы сделаете ethernet устройство, вам придется еще и решать проблему множественного доступа (с разных компов).

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

+Много. Системы сбора, обработки и документирования данных с USB-интерфейсом успешно работают и в авиации, и в экстренных службах, и еще много где.

А Ethernet, типа, нигде не работает и вообще "покойник"

[SM]

В данном случае для Ethеrnet, который Вы судя по Вашей реакции не отличаете от TCP/IP на самом деле даже UDP/TCP/IP не нужны - голые фреймы, максимум с чем-нибудь типа IEEE 802.3 в заголовке. Со стороны PC RAW Socket и вперед.

Почему это я вдруг не отличаю? Я Wiznet лишь как пример привел, и ни разу не говорил, что обязательно используется TCP/IP, это лишь очередная Ваша фантазия. В нем удобные RAW-сокеты, он недорог, и он с PHY.

А Ethernet, типа, нигде не работает и вообще "покойник"

А я и нигде не говорил, что он не работает, или плох. Он просто сложнее в реализации. Если линк на УСБ мегабайт так 10-20 в секунду поднимается одним мизинцем левой руки с имеющимися красивыми и удобными мостами за час работы, то аналогичное с ethernet - повозиться придется с недельку. А чтобы было как с УСБ - "воткнул и работает везде и сразу без ручных настроек" - так и все пару недель.

не говоря уже о том, что просто берется любой 32битник по вкусу с MAC на борту.

Вот, наконец-то, чего я от Вас и добиваюсь. А теперь подробнее - какой именно, для примера. Чтобы был с PHY, чтобы прокачал 20 Мбайт/с в ФПГА, и чтобы стоил $5..6, как имеющиеся аналогичные по пропускной USB-мосты, и чтобы работы по поднятию этой связки было сравнимо с поднятием линка на USB.

[RobFPGA]

Приветствую!

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

С моей точки зрения Ethernet более универсальное решение. При сопоставимых с USB затратах на реализацию - возможностей значительно больше. Реализовать в FPGA MAC и заставить его слать пакеты на конкретную машину не сложнее чем через USB CY7C68013. Для этого стек TCP/IP не нужен.

Я не умаляю достоинств USB он имеет свои преимущества, НО это только ЛОКАЛЬНЫЙ интерфейс периферии компьютера, с небольшим расстоянием и отсутствием гальванической развязки.

Ethernet - СЕТЕВОЙ интерфейс не привязанным к конкретному компьютеру, система с Ethernet будет работать и на столе с рядом стоящим буком, и в 200 метрах, и в 20 км если надо БЕЗ изменения самой системы!

Писать же софт придется в любом случае.

Успехов! Rob.

[SM]

Реализовать в FPGA MAC и заставить его слать пакеты на конкретную машину не сложнее чем через USB CY7C68013.

Не согласен. Вот реализовать в FPGA MAC (с внешним PHY) не сложнее, чем реализовать в FPGA USB Device (с внешним ULPI-трансивером). Если есть в наличии готовая УСБ-корка и готовая МАК-корка разумеется. А вот погнать поток в 68013 - это автомат о 10-ти строчек.

Про софт - речь шла о embedded-софте и его количестве, PC-софт разумеется писать надо, и там согласен, совершенно фиолетово, eth, usb или незаслуженно тут забытый IEEE1394, как и SAS, SATA и старый добрый параллельный SCSI (который кстати физически простой LVDS). А вот про удаление куда-то от компа вопроса не стояло вообще.

[zltigo]

аналогичное с ethernet - повозиться придется с недельку.

Физика Ethernet, поднимается тем-же мизинцем ровно за такое-же время, причем жто время сопоставимо со временем поднятия физики и любого другого пакетного интерфейса. Стек протоколов не нужен, Все точно так-же, только нет жесткой завязки на конкретного производителя, его стеки, его драйвера....

А чтобы было как с УСБ - "воткнул и работает везде и сразу без ручных настроек"

Если-бы я НЕ БЫЛ ПОЛЬЗОВАТЕЛЕМ множества разных USB устройств, то я, возможно, и мог-бы отнестись к Вашми утверждениям с большим доверием

Вот, наконец-то, чего я от Вас и добиваюсь. А теперь подробнее - какой именно, для примера. Чтобы был с PHY, чтобы прокачал 20 Мбайт/с в ФПГА, и чтобы стоил $5..6,

А без PHY, типа уже совсем не годятся? Или за 6 долларов 50 центов тоже? Ой! А у Ethernet еще и "трансформатор"....Мы о чем разговариваем? Об штучной разработке, которая должна жить и развиваться и не умереть, напиример, по причине того, что фирма производящая "красивые USB мосты" не обеспечила совместимость с какой-нибудь операционкой, или о массовом бытовом устройстве со сроком морального старения в пару лет? "20 мегабайт с FPGA" красивые слова - конкретно глянул CYPRESS - восьмибитовая шина, 4-6 тактов на запись, 48 тактовая... 20 мегабайт говорите . Это только ограничение на стыке с FPGA. Дальше еще вмешивается собственно контроллер и все USBишное хозяйство на на стороне PC. Да тупо, но быстро гнать поток, если никто не мешает, у USB получается хорошо, но забывать, что USB периферийное устройство есть сугубо подчиненное и неравноправное .
P.S.
Ну а за 9-12-14 баксов, это уже какой-нибудь ARM9 c Ethernet (впрочем и USB ) на борту и 8-16-32bit шиной.

[Михаил_K]

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

Конечно понял. Вставка отдельной сетевухи, и РАЗРАБОТКА ПРАВИЛ ПОДКЛЮЧЕНИЯ, в которых пользователю будет сказано, не тыкай наш дивайс в коммутатор - один из путей решения этой проблемы.

Физика Ethernet, поднимается тем-же мизинцем ровно за такое-же время, причем жто время сопоставимо со временем поднятия физики и любого другого пакетного интерфейса. Стек протоколов не нужен, Все точно так-же, только нет жесткой завязки на конкретного производителя, его стеки, его драйвера....

Любительство в самом что ни наесть ярком своем представлении. Стек протоколов придуман людьми не от скуки, а чтобы придать каналу связи определенные характеристики. Не говоря уже о том, что для того, чтобы сделать на писюке ПО, работающее с МАС уровнем ethernet - задача ой как не тривиальная. И лишь использование стандартных протоколов упрощает программирование.

Если-бы я НЕ БЫЛ ПОЛЬЗОВАТЕЛЕМ множества разных USB устройств, то я, возможно, и мог-бы отнестись к Вашми утверждениям с большим доверием

Если кто-то не смог сделать нормальный USB дивайс, то это не значит что у всех разработчиков руки кривые

"20 мегабайт с FPGA" красивые слова - конкретно глянул CYPRESS - восьмибитовая шина, 4-6 тактов на запись, 48 тактовая... 20 мегабайт говорите . Это только ограничение на стыке с FPGA.

Нет, я говорю - 40 мегабайт .

Я не умаляю достоинств USB он имеет свои преимущества, НО это только ЛОКАЛЬНЫЙ интерфейс периферии компьютера, с небольшим расстоянием и отсутствием гальванической развязки.

Ethernet - СЕТЕВОЙ интерфейс не привязанным к конкретному компьютеру, система с Ethernet будет работать и на столе с рядом стоящим буком, и в 200 метрах, и в 20 км если надо БЕЗ изменения самой системы!

Это несомненно преимущество Ethernet. И если предполагается что устройство будет таким образом эксплуатироваться, или такое свойство будет хорошей рекламой - берите ethernet. Только не забывайте, что как только вы отказываетесь от стека протоколов, вы сразу же получаете такое-же локальное устройство, у которого разве что кабель длиннее. А все преимущества перед USB сразу теряются.

[zltigo]

Конечно понял. Вставка отдельной сетевухи, и РАЗРАБОТКА ПРАВИЛ ПОДКЛЮЧЕНИЯ, в которых пользователю будет сказано, не тыкай наш дивайс в коммутатор - один из путей решения этой проблемы.

Этой проблемы НЕ существует и при одной карте, но если Вам хочется "решить" ее так сказать, аппаратно, то можете заниматься созданием "инструкций". Отдельную карту можно и нужно ставить, если надо выжимать производительность.

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

IP стек? Одругих слышать не приходилось? А в пределах локальной сети используется масса других, и стандарты существуют. Я например, опираюсь на IEEE 802.3 IEEE 802.2.

Не говоря уже о том, что для того, чтобы сделать на писюке ПО, работающее с МАС уровнем ethernet - задача ой как не тривиальная.

Ну тогда я Вас сейчас осчастливлю несколькими десятками строчек "для писюка". Вырезал из собственно проектика под Linux.

CODE

char *device = "eth0";

int interface_init(void)
{
struct ifreq ifr;
int fd, flags = 0;
if( ( fd = socket( PF_INET, SOCK_PACKET, htons(ETH_P_802_2) ) ) < 0 )
{
printf( "Cannot open RAW/SAP device socket\n" );
return( -1 );
}

strcpy( ifr.ifr_name, device );

if( ioctl( fd, SIOCGIFFLAGS, &ifr ) < 0 )
{ printf( "Cannot get RAW/SAP interface flags\n" );
return( -1 );
}
ifr.ifr_flags |= IFF_BROADCAST;
if( ( flags = ioctl( fd, SIOCSIFFLAGS, &ifr ) ) < 0 )
{ printf( "Cannot set RAW/SAP interface flags\n" );
return( -3 );
}

if( ioctl( fd, SIOCGIFHWADDR, &ifr ) < 0 )
{ printf( "Cannot get MAC Address\n" );
return( -4 );
}
.....

return( fd );
}

int eth_send( uchar *buff, int len )
{
........
memcpy( eth_outbuff.body, buff, len );
mac_flush();
return( 0 );
}

uchar *readinterface( int fd, int *plen )
{
int cc = 0, from_len, readmore = 1;
struct sockaddr from;
while( readmore )
{ from_len = sizeof(from);
if( ( cc = recvfrom( fd, (uchar *)&eth_inpbuff, PKT_MAX, 0, &from, &from_len ) ) < 0 )
{
if( errno != EWOULDBLOCK )
return( NULL );
}
if( strcmp( device, from.sa_data ) == 0 )
readmore = 0;
}
*plen = cc;
return( (uchar *)&eth_inpbuff );
}

int mac_flush(void)
{
int retvalue = 0;
struct sockaddr to;
errno = 0;
int plen = ntohs( eth_outbuff.mac.len ) + sizeof(MAC_addr)*2 + sizeof(ushort);
int to_len = sizeof(to);

strcpy( to.sa_data, device );

if( (retvalue = sendto( rawsock, (uchar *)&eth_outbuff, plen, 0, (struct sockaddr *)&to, to_len )) < 0 )
{
printf( "RAW Sendto:%s\n", strerror(errno));
}
return( retvalue );
}

Вот и вся премудрость доступа к фрейму. Для Windows придется, запихтвать еще драйвера cтронних производителей, ибо RAW там поддерживаются условно, но написать в результате, придется примерно то-же самое.

И лишь использование стандартных протоколов упрощает программирование.

Не использование стандарнных, а использование стандарных КЕМ-ТО УЖЕ НАПИСАННЫХ протоколов. Да это упрощает, ибо делать ничего собственно и не надо . Поэтому я вполне понимаю и разделяю Вашу радость от того, что повесив CYPRESS и Вам удалось решить Вашу задачу левым мизинцем.

Если кто-то не смог сделать нормальный USB дивайс, то это не значит что у всех разработчиков руки кривые

Может и кривые, может у CYPRESS и самые прямые руки, но проблема в том, что жить на USB вы будете все вместе и с разработчиками кривых девайсов, с разработчиками кривых драйверов и с разработчиками разных операционок.

Нет, я говорю - 40 мегабайт .

Говорть Вы можете что угодно, но если кроме русского языка владеете и арифметикой, то советую произвести пару операций деления над цифирями приведенными в мануале производителем для параллельного интерфейса и оценить результат.

[SM]

Если-бы я НЕ БЫЛ ПОЛЬЗОВАТЕЛЕМ множества разных USB устройств, то я, возможно, и мог-бы отнестись к Вашми утверждениям с большим доверием

Кривых разработок много, поэтому пользователи так к УСБ и относятся.

А без PHY, типа уже совсем не годятся? Или за 6 долларов 50 центов тоже? Ой! А у Ethernet еще и "трансформатор"....Мы о чем разговариваем?

Мы разговариваем о мосте, хоть чуть чуть приближающемся по параметрам к 68013. Но Eth. По этому не дороже 6$, это оптовая цена 68013. И с PHY, потому что 68013 содержит в себе PHY (трансивер точнее). А трансформатор можно выкинуть, если речь о линке PC-девайс (именно контроллер-в-PC-девайс), без него все будет работать не хуже, чем с ним, если соблюсти согласование.

Об штучной разработке, которая должна жить и развиваться и не умереть, напиример, по причине того, что фирма производящая "красивые USB мосты" не обеспечила совместимость с какой-нибудь операционкой?

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

"20 мегабайт с FPGA" красивые слова - конкретно глянул CYPRESS - восьмибитовая шина, 4-6 тактов на запись, 48 тактовая... 20 мегабайт говорите .

Вы опять занимаетесь целенаправленной дезинформацией, что не есть хорошо для человека, занимающего достаточно высокую "должность" в форуме. У всех CY7C68013, даже в 56-пин корпусе, шина 16 битная (Slave FIFO), синхронная, 48-мегагерцовая, что перекрывает пропускную самой шины УСБ почти в два раза. И передача данных УСБ-ПЛИС идет никак не касаясь его набортного процессора, суть которого - лишь выдавать дескрипторы, короче обслуживать control transfer.

Ну а за 9-12-14 баксов, это уже какой-нибудь ARM9 c Ethernet (впрочем и USB ) на борту и 8-16-32bit шиной.

За 9-12-14 я и сам знаю. Но 1) Это дорого. 2) Софта в него писать придется не чета 68013-му, где VID-PID на свой поправить, и все. 3) вряд ли найдется решение в одном корпусе размером 5х5 милиметров (суффикс BAX у 68013).

Может и кривые, может у CYPRESS и самые прямые руки, но проблема в том, что жить на USB вы будете все вместе и с разработчиками кривых девайсов, с разработчиками кривых драйверов и с разработчиками разных операционок.

Во первых - руки Cypress не причем. Они сделали "как бы MAC" только УСБ. Вроде как вполне безглючный. А остальная глюкавость зависит лишь от того, кто этот мост использует.
Во вторых - не нравится жить совместно с другими глючными девайсами - повесить на отдельный контроллер, как Вы предлагаете поступить с Eth. Причем с той же целью - гарантии пропускной со стороны PC и невмешательства в поток других девайсов.

Говорть Вы можете что угодно, но если кроме русского языка владеете и арифметикой, то советую произвести пару операций деления над цифирями приведенными в мануале производителем для параллельного интерфейса и оценить результат

Лехко. Имеем 16 бит и 48 мегагерц. На пересылку пакета в 512 байт затраты таковы - 1 такт - обнаружение флага наличия данных в FIFO и RD в ноль, второй такт - получение данного после RD, третий....258-й - считывание 256 слов. Добавлю еще два такта на возможные задержки из-за неуспевания выходов фпга и сетапов CY. Итого 260 тактов на 512 байт при 48 МГц, итого 5.42 мкс, итого 94 МБайт/с. При том, что USB (bulk) может обеспечить физически лишь 53 МБайт/с.

[zltigo]

Вы опять занимаетесь целенаправленной дезинформацией....

Так уж и целенаправленной . Мануал смотрел мельком не заметил, что интерфейсов несколько. Виноват .

Мы разговариваем о мосте...

Простите, но это Вы упорно разговариваете о мосте, экономии 5 баксов и теперь еще о размерах 5x5 мм, а в теме речь идет о комплексном решении некой проблемы. Перечитайте первый пост.

[SM]

Простите, но это Вы упорно разговариваете о мосте, экономии 5 баксов и теперь еще о размерах 5x5 мм, а в теме речь идет о комплексном решении некой проблемы. Перечитайте первый пост.

Я разговариваю как раз о решении вопроса в целом. Что сводится к двум пунктам. 1) Обеспечить соответствие ТЗ (в данном случае пропускную). 2) Минимизировать затраты, а именно 2А - на разработку, 2Б - на себестоимость, ну и 2В) занять минимум лишнего места на плате. На мой взгляд использование моста оптимально решает первые два вопроса (2А, Б), минимально затрагивая третий (В), полностью решая пункт 1. Именно по этому я предлагаю найти другие варианты, которые позволят решить эту же задачу, но менее затратно (включая разработку и площадь места на плате). Пока предложений не было.

[zltigo]

Делаете свой девайс например с протоколом "Mass Storage Device" - и оно...

А кто тут утверждал, что достаточно только " где VID-PID на свой поправить, и все" а тут еще и делать что-то надо. Так надо или не надо используя "тупой мост" что-то делать?

как Вы предлагаете поступить с Eth. Причем с той же целью - гарантии пропускной со стороны PC и невмешательства в поток других девайсов.

Я этого НЕ предлагаю, это просто ответ на утверждение Вашего соратника на поминание "проблемы Ethernet" в работу которого могут вмешиваться другие компьютеры. Для решения поставленной автором топика задачи не имею нималейших возражений ни против использования отдельных контроллеров для чего-либо.

[SM]

А кто тут утверждал, что достаточно только " где VID-PID на свой поправить, и все" а тут еще и делать что-то надо. Так надо или не надо используя "тупой мост" что-то делать?

В софте для моста - именно поправить VID-PID-дескрипторы. Этого достаточно. После этого мост будет представляться девайсом с нужным VID-PID и гнать через FIFO данные по нужным bulk-трубам. Больше ничего в софте для моста делать не нужно. Ну в крайнем случае еще подкрутить полярности сигналов управления FIFO, если это важно.
А для соответствие дальнейшим стандартам, чтобы "во всех операционках вообще", разумеется придется еще поформатировать свои данные. Но это уже опция суперсовместимости, привязываясь к ОС - в любой винде можно ограничиться либо цайпресовским драйвером, либо микрософтовским bulkusb.sys, а в линуксе все проще, там хватит встроенного в линукс на все случаи жизни. И при этом гнать данные без какого либо дополнительного форматирования в ПЛИС.

[zltigo]

1) Обеспечить соответствие ТЗ (в данном случае пропускную).

Пропускная способность на первом этапе не ограничивает ничего, на последующих этапах USB по сравнению с гигабитным Ethernet проигрывает.

2) Минимизировать затраты, а именно 2А - на разработку, 2Б - на себестоимость, ну и

На разработку - бабущка надвое сказала - Вы утверждаете, что с помощью моста и "VID-PID на свой поправить, и все" решили проблемы, я смею утверждать, что не имею нималейщих проблем в написании считанных десятков строчек для поддержки физического уровня Ethernet. На себестоимость - слово Автору топика "Т.к. изделия не серийные, то можно использовать компоненты (в т.ч. ПЛИС) ценой в несколько тысяч рублей."

2В) занять минимум лишнего места на плате.

Опять Автор - "с местом проблем нет"

Пока предложений не было.

Ну если хотите считать, что "не было", считайте,что не было.

[SM]

То, что нет проблем с местом на плате, и то, что можно использовать компоненты в тыщи баксов совсем не означает того, что 5 долларов с девайса в карман это плохо и не нужно, и то, что (грубо) замена компонента за 1000 на компонент за 900 это лишнее. Имхо минимизация затрат - непременный атрибут любой разработки, и не серийной тоже.

[zltigo]

В софте....

В общем ситуация с софтом для "просто гнать данные" совершенно одного уровня сложности, что для USB, что для ETH. Только для Ethernet при этом еще и нет завязки на конкретного производителя моста и его софт - полная свобода выбора и действий

P.S.
Тем не менее "мост" иметь ввиду - случаи в жизни они разные бывают.

[SM]

В общем ситуация с софтом для "просто гнать данные" совершенно одного уровня сложности, что для USB, что для ETH.

Причем я об этом сказал значительно раньше http://electronix.ru/forum/index.php?showt...st&p=562417

нет завязки на конкретного производителя моста и его софт - полная свобода выбора и действий

Что касается завязки на софт производителя моста - этого на самом деле нет. Производитель дает лишь примеры софта, и никто не заставляет завязываться на них, а не например на софт для УСБ от микрософта (bulkusb), который точно так же, как и ezusb.sys, позволяет тупо гнать данные. Про линукс я уже сказал - там все еще проще - там драйвер контроллера USB сразу предоставляет необходимый доступ к любому девайсу через /proc/bus/usb/.... И никаких лишних драйверов не нужно вообще, открывай и юзай.

Завязка на железо - все равно есть - либо завязка на конкретного производителя внешнего MAC, либо PHY. ТОЧНО также, как либо на производителя моста УСБ, или УСБ-трансивера (если УСБ-контроллер пихать в ПЛИС, что околоодинаково и по ресурсам ПЛИС, и по затратам времени с MAC в ПЛИС).

ЗЫ. Я вот сейчас как раз занимаюсь УСБ high speed в ПЛИС без моста. Так как на мост к сожалению не хватило ни места, ни питания, а трансивер с размером корпуса 3.5х3.5 мм влез. Поэтому и знаю про затраты....

[zltigo]

Причем я об этом сказал значительно раньше...

Не вижу, на что конкретно ссылаететесь.... Но о том, что работа с Ethernet, причем с любым ГОЛЫМ MAC контроллером проста как лом, написал в первом-же своем посте. В ответ услышал от некоторых участников:

ПО, работающее с МАС уровнем ethernet - задача ой как не тривиальная.

Работать с мостом от CYPRESS слегка правя имеющийся софт от CYPRESS тоже просто - очень рад. Взял на заметку, хотя с вероянностью 99% у это будет делаться на встроенном в какой-нибудь 32битник USB контроллер, нежели прицепленный к его параллельной шине 51 с USB и сторонним софтом на борту.

[SM]

Не вижу, на что конкретно ссылаететесь....

На "Сообщение #22", вторая его половина.

хотя с вероянностью 99% у это будет делаться на встроенном в какой-нибудь 32битник USB контроллер, нежели прицепленный к его параллельной шине 51 с USB и сторонним софтом на борту.

Ну разумеется, если уже есть 32-битник, то лучше взять его сразу с УСБ, чем цеплять к нему что-то снаружи. Речь-то все таки о FPGA, а не о 32-битнике, а это совсем другая тема.

[Михаил_K]

IP стек? Одругих слышать не приходилось? А в пределах локальной сети используется масса других, и стандарты существуют.

Ну вы нас в натуре за лохов-то не держите

Ну тогда я Вас сейчас осчастливлю несколькими десятками строчек "для писюка". Вырезал из собственно проектика под Linux.

CODE

char *device = "eth0";

int interface_init(void)
{
struct ifreq ifr;
int fd, flags = 0;
if( ( fd = socket( PF_INET, SOCK_PACKET, htons(ETH_P_802_2) ) ) < 0 )
{
printf( "Cannot open RAW/SAP device socket\n" );
return( -1 );
}

strcpy( ifr.ifr_name, device );

if( ioctl( fd, SIOCGIFFLAGS, &ifr ) < 0 )
{ printf( "Cannot get RAW/SAP interface flags\n" );
return( -1 );
}
ifr.ifr_flags |= IFF_BROADCAST;
if( ( flags = ioctl( fd, SIOCSIFFLAGS, &ifr ) ) < 0 )
{ printf( "Cannot set RAW/SAP interface flags\n" );
return( -3 );
}

if( ioctl( fd, SIOCGIFHWADDR, &ifr ) < 0 )
{ printf( "Cannot get MAC Address\n" );
return( -4 );
}
.....

return( fd );
}

int eth_send( uchar *buff, int len )
{
........
memcpy( eth_outbuff.body, buff, len );
mac_flush();
return( 0 );
}

uchar *readinterface( int fd, int *plen )
{
int cc = 0, from_len, readmore = 1;
struct sockaddr from;
while( readmore )
{ from_len = sizeof(from);
if( ( cc = recvfrom( fd, (uchar *)&eth_inpbuff, PKT_MAX, 0, &from, &from_len ) ) < 0 )
{
if( errno != EWOULDBLOCK )
return( NULL );
}
if( strcmp( device, from.sa_data ) == 0 )
readmore = 0;
}
*plen = cc;
return( (uchar *)&eth_inpbuff );
}

int mac_flush(void)
{
int retvalue = 0;
struct sockaddr to;
errno = 0;
int plen = ntohs( eth_outbuff.mac.len ) + sizeof(MAC_addr)*2 + sizeof(ushort);
int to_len = sizeof(to);

strcpy( to.sa_data, device );

if( (retvalue = sendto( rawsock, (uchar *)&eth_outbuff, plen, 0, (struct sockaddr *)&to, to_len )) < 0 )
{
printf( "RAW Sendto:%s\n", strerror(errno));
}
return( retvalue );
}

Вот и вся премудрость доступа к фрейму. Для Windows придется, запихтвать еще драйвера cтронних производителей, ибо RAW там поддерживаются условно, но написать в результате, придется примерно то-же самое.

Этого недостаточно. А где механизм обеспечения целостности передачи?

Не использование стандарнных, а использование стандарных КЕМ-ТО УЖЕ НАПИСАННЫХ протоколов. Да это упрощает, ибо делать ничего собственно и не надо . Поэтому я вполне понимаю и разделяю Вашу радость от того, что повесив CYPRESS и Вам удалось решить Вашу задачу левым мизинцем.

Несомненно. У нас есть один специалист, который все делает сам. Типа у всех руки кривые. Вот я с ним уже шесть лет работаю. Ни одного законченного продукта.
Хотя специалист сильный.



Честно говоря, не вижу смысла дальше спорить. Я не ярый сторонник USB или Ethernet.
Просто, как я уже сказал, у нас в организации было разработано и то, и то.
И все сходятся во мнении, что для подобных задач реализация на USB - лучше. Даже те, кто разрабатывал Ethernet интерфейс.
И я, как пользователь этих каналов. Человек, которому этими интерфейсами приходится пользоваться постоянно.

А на вкус и цвет, товарищей нет

[zltigo]

Этого недостаточно. А где механизм обеспечения целостности передачи?

Это Вы писали:

Не говоря уже о том, что для того, чтобы сделать на писюке ПО, работающее с МАС уровнем ethernet - задача ой как не тривиальная.

То, что Вы назвали нетривиальной задачей, то и выложил.
Следующий уровень с возможностью включения квитирования, перепередачи (ксати, а где это все у USB моста? ) при этом нумерация принятых переданных и контроль факта пропадания есть само-собой всегда. Вcе это, кстати, за счет реального времени и пропускной способности. Представляет собой вариации на тему IEEE 802.2, писалось лет так 12 назад, работает у меня далеко не только через Ethernet и содержит ровно 378 строчек на C. Вот такая нетривиальная задача.

Этого недостаточно. А где механизм обеспечения целостности передачи?

Это Вы писали:

Не говоря уже о том, что для того, чтобы сделать на писюке ПО, работающее с МАС уровнем ethernet - задача ой как не тривиальная.

То, что Вы назвали нетривиальной задачей, то и выложил.
Следующий уровень с возможностью включения квитирования, перепередачи (ксати, а где это все у USB моста? ) при этом нумерация принятых переданных и контроль факта пропадания есть само-собой всегда. Вcе это, кстати, за счет реального времени и пропускной способности. Представляет собой вариации на тему IEEE 802.2, писалось лет так 12 назад, работает у меня далеко не только через Ethernet и содержит ровно 378 строчек на C. Вот такая нетривиальная задача.

Ну разумеется, если уже есть 32-битник, то лучше взять его сразу с УСБ, чем цеплять к нему что-то снаружи. Речь-то все таки о FPGA, а не о 32-битнике, а это совсем другая тема.

Вы же сами сказали, что MAC уровни, тем более, что брать готовые корки в FPGA одинаковы по трудоемкости, софт, для тупой передачи потока, как выяснилось, - тоже одного порядка. Дальше что? На моей стороне равноправные партнеры, а не опрашивемое переферийное устройство, удаление на сотни метров, гальваническая развязка, возможность гигабита. На ваше стороне, "5 баксов" и "5x5 миллиметров", да и то только в случае выбора между мостом USB и контроллером MAC. Есть выбор. Я ничего не упустил?

[Михаил_K]

Следующий уровень с возможностью включения квитирования, перепередачи (ксати, а где это все у USB моста?

у USB моста это все встроено, и работает. Достаточно лишь выбрать вид передачи BULK
А чтобы уместить все это в 378 строчек, нужно быть хорошим программистом.

[SM]

Следующий уровень с возможностью включения квитирования, перепередачи (ксати, а где это все у USB моста? )

Как где? В спецификации УСБ, главы 8.5...8.7. Любой УСБ девайс, коим является и мост, обязан это обеспечивать.

Вы же сами сказали, что MAC уровни, тем более, что брать готовые корки в FPGA одинаковы по трудоемкости, софт, для тупой передачи потока, как выяснилось, - тоже одного порядка. Дальше что? На моей стороне равноправные партнеры, а не опрашивемое переферийное устройство, удаление на сотни метров, гальваническая развязка, возможность гигабита. На ваше стороне, "5 баксов" и "5x5 миллиметров", да и то только в случае выбора между мостом USB и контроллером MAC. Есть выбор. Я ничего не упустил?

Упустили главное. Засовывание и отладка корки, что УСБ, что МАК, одинаковый геморрой недели на две, особенно если впервые, а поднятие передачи с мостом - вопрос получаса. Плюс, если впервые, еще работа по откручиванию всяких там вишбонов, ahb, amba и прочего нахрен не нужного хлама, пока до локальной шины не доберешься. Выигрышь в стоимости разработки при применении моста виден сразу.

Осталось взять все доступные мосты, а именно MACи внешние и УСБ-мосты, и сравнить их по параметрам, как то цена, занимаемое место, жрачка. Ну и сравнить их же с решением вкрячивания корки в ПЛИС с использованием внешнего PHY, предполагая, что она займет для УСБ ~2800 LE / 8 M4K (можно обкастрировать где-то до 2100) и для Eth 10/100 3800 LE / 9 M4K (можно обкастрировать где то до 1500, но потом за счет контроля целостности и ретрансмитов оно разростется обратно думаю до объема как раз USB). Объемы приведены примеро для корок от CAST под FPGA Cyclone-II.

Если свести все в единую таблицу, где учесть время на разработку, учесть стоимость компонентов, учесть площадь платы, переведя все эти составляющие в деньги, то решения с USB-мостами окажутся порядочно впереди Eth-решений с внешними макамию, а решения с УСБ-корками незначительно дешевле, чем с МАК-корками (при условии, что трансформатор можно по ТЗ выкинуть, разница за счет цен на PHY и занимаемой площади ими на плате). По крайней мере так было полтора года назад, когда я эту работу проводил. Из чего напрямую следует, что если применим по ТЗ и тот, и этот интерфейсы, то наиболее быстро реализуемое решение, при этом самое дешовое - будет именно USB мост.

Что касается 5х5 мм - то найдите хотя бы Eth PHY такой При том, что USB PHY имеют размер 3.5х3.5 мм

[zltigo]

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

Понял, добавляем очень очень очень быстрый старт. Я правда предпочитаю быстрому старту долгую жизнь и возможности развития. Осталось после всего этого выслушать Автора топика.
P.S.
Все, я уезжаю на недельку по делам, наверное будет не до electronix

[a123-flex]

Понял, добавляем очень очень очень быстрый старт. Я правда предпочитаю быстрому старту долгую жизнь и возможности развития. Осталось после всего этого выслушать Автора топика.
P.S.
Все, я уезжаю на недельку по делам, наверное будет не до electronix

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

[Alex11]

Тут уже много чего сказано, но можно добавить, что USB вполне применим при условии, что достаточно потока 40 КБайт/сек. Выше практически не реализуемо. Я не работал с предлагаемым CY кристаллом, но на других (филипс) потоки порядка 30-35 КБайт/сек вполне получались даже при медленном контроллере в управлении. И еще. Для сбора данных не нужно использовать изохронную передачу. По двум причинам. Во-первых, это негарантированная доставка, а во-вторых - скорость меньше, особенно если посмотреть на ошибки микрософта в реализации hub-драйвера в этом режиме. Что касается замираний, то они есть, но небольшие. Проблема вполне решается установкой буфера размером 2-10 КБ для этих скоростей.

[SM]

но можно добавить, что USB вполне применим при условии, что достаточно потока 40 КБайт/сек.

Только не КБайт, а МБайт! А выше действительно сложно и не на каждой машине (физический предел 53-54 МБайт/с)

[Boris_TS]

Фуххх... Вернулся из 2 дневной командировки.

Осталось после всего этого выслушать Автора топика.

После предварительного согласования параметров системы сбора данных с соратниками, выяснилось, что необходима длина кабеля для передачи данных до 30-40 метров с обязательным наличием гальванической (или оптической) развязки, предельный поток данных получается около 15 MByte/s (или 120 MBit/s - так точнее) (к сожалению "сладкое будущее" стало тоскливой реальностью). Поэтому USB отпадает, насколько мне известно он не работает на такое расстояние и не имеет развязки. А жаль, первоначально предполагалось (мною), что удастся ограничиться один метром интерфейсного кабеля.

Естественно с таким потоком Ethernet-100 не справиться, соответственно прийдется использовать Gigabit Ethernet.
Теперь вопросы:
1. С чего лучше начать знакомство с Ethernet ?
2. Что лучше использовать чистый Ethernet или еще реализовывать и TCP/IP (в чем достоинства/недостатки обоих решений) ?
3. Исходя из 2, какие микросхемы/сборки лучше использовать ?

Еще раз повторю особенности этой разработки:
1. Данные необходимо гарантированно доставлять (т.к. у меня - система сбора данных).
2. Необходимо иметь возможность в будущем увеличить поток в 2 (или 2.5) раза, т.е. до 240Mbit/s (или 300Mbit/s - это крайняя цифра, выше неё прыгать не собираемся).
3. Очень важно минимизировать время разработки.
4. Место для аппаратного решения - 1дм2, можно и 1.5дм2 (да, так спроектировал систему - место есть).
5. Желательно чтобы суммарная цена копонентов не превышала десятка киборублей (не килодолларов !).
6. Программа приема данных на компьютере будет работать под Windows XP 32bit (тоже желательно позаботиться о программисте - дабы не сильно пух от проблем с голым Ethernet, или проблем как раз с Windows XP нет ?).

Пока видел 2 предложеных решения:
1. FPGA + ARM9 (как я понял, поддержку TCP/IP в ARM9 прийдётся делать самому, али есть готовое и доступное решение ?).
2. V4 Ethernet MAC (+ MicroBlase with LwIP - для поддержки TCP/IP).
Может еще какие предложения есть ?

Пока, второе предложение кажется более близким т.к. работаю с ISE давно и очень плотно (есть надежда, что и с EDK очень долго разбираться не прийдется), а вот про ARM только приходилось иногда слышать...

[blackfin]

Может еще какие предложения есть ?

Купить готовое: PCI/PCIe Expansion System
PicoDev: Область применения..

[DmitryR]

1. FPGA + ARM9 (как я понял, поддержку TCP/IP в ARM9 прийдётся делать самому, али есть готовое и доступное решение ?).
2. V4 Ethernet MAC (+ MicroBlase with LwIP - для поддержки TCP/IP).
Может еще какие предложения есть ?

Пока, второе предложение кажется более близким т.к. работаю с ISE давно и очень плотно (есть надежда, что и с EDK очень долго разбираться не прийдется), а вот про ARM только приходилось иногда слышать...

Мне кажется, что именно второй вариант вам подойдет - вы в один Virtex-4 все затолкаете вместе со сбором данных. Причем делать Microblaze не придется, так как в тех Virtex-4, где есть MAC - есть и PPC405. Можно также посмотреть на Virtex-5 (ведь с анонсом Virtex-6 четвертое семейство становится уже позапрошлым) - там есть MAC без процессора, а где есть процессор - он уже PPC440.

[SM]

IMHO тогда так:

внешний PHY, например RTL8211.
ПЛИСина - навроде Cyclone-II или III, только ксилинкс, сорри, не знаю, кто там аналогичен.
МАК-корка - навроде CAST Gigabit Lite , в альтере займет ~2К лутов, значит в ксиле примерно 1.5К слайсов.

Ну и остальное - как zltigo советовал, передача голыми ethernet пакетами, контроль целостности и повторы передачи прикрутить самому.

Никаких ембеддед-процессоров, ни хард, ни софт, ну и соотв. никакого ембеддед-софта.

К сожалению удобных мостов 1G Eth -> локальная шина я не знаю. Но если такой есть - то разумеется найти и применить

[DmitryR]

Ну и остальное - как zltigo советовал, передача голыми ethernet пакетами, контроль целостности и повторы передачи прикрутить самому.

Никаких ембеддед-процессоров, ни хард, ни софт, ну и соотв. никакого ембеддед-софта.

Я вот только думаю, что нормальная реализация контроля целостности и повтора передачи займет столько усилий, что отсутствие ембеддед-процессоров будет очень быстро проклято. А в EDK все готовое: проц, MAC, Linux. Остается написать драйвер устройства сбора данных для Linux - и все.

[jojo]

Внешний PHY 10/100/1000
Древний, зато купить легко

http://www.national.com/mpf/DP/DP83865.html

к нему ядро вроде IFI GMAC 1.7 или ещё какое есть под выбранное семество ПЛИС.

[Михаил_K]

Наши делали так. Интеловский сетевой процессор. На нем раскручивается линух, который и реализует стандартные протоколы, в том числе и TCP/IP.

[SM]

Остается написать драйвер устройства сбора данных для Linux - и все.

Для специалиста по ФПГА только слово "линукс" может показаться концом света, а не то, что "драйвер". При том, что контролировать передачу пакета и перепосылать, если не было подтверждения за определенное время, это достаточно просто в RTL-реализации. Что займет какое то время - это факт, но сильно сомнительно, что будет дольше, чем поднятия линукса на софт-проце.

[DmitryR]

В этом проекте без программиста все равно вряд ли обойдется дело. Даже делая простое подтверждение пакетов с перепосылкой надо написать некий софт на РС, чтобы это тестировать.

[Михаил_K]

Для специалиста по ФПГА только слово "линукс" может показаться концом света, а не то, что "драйвер". При том, что контролировать передачу пакета и перепосылать, если не было подтверждения за определенное время, это достаточно просто в RTL-реализации. Что займет какое то время - это факт, но сильно сомнительно, что будет дольше, чем поднятия линукса на софт-проце.

Это все так, но использование стандартной ОС очень соблазнительно, т.к. она позволит не только организовать TCP стек, но и предоставит базу для возможной последующей модернизации. ИМХО - новую программу написать легче, чем изготовить новое железо.

[SM]

ИМХО - новую программу написать легче, чем изготовить новое железо.

Но не легче, чем просто поправить RTL, внеся в него новую функциональность. Если, конечно, в ПЛИС влезет.

В этом проекте без программиста все равно вряд ли обойдется дело. Даже делая простое подтверждение пакетов с перепосылкой надо написать некий софт на РС, чтобы это тестировать.

Ну PC-программист (он наверное и так есть, так как проект-то не новый, а модернизация) это одно, а программист, способный поднять что-то на софт-проце в фпга это совсем другое.

[islavv]

Эквивалентно - скажите, как сделать так, что-бы ничего не делать? Дайте мне мои любимые протезы . Ну не нужны они. В данном случае для Ethеrnet, который Вы судя по Вашей реакции не отличаете от TCP/IP на самом деле даже UDP/TCP/IP не нужны - голые фреймы, максимум с чем-нибудь типа IEEE 802.3 в заголовке. Со стороны PC RAW Socket и вперед.

1. USB в даном случае нужно пихать не в FPGA а куда подальше...
2. Реализация MAC Ethernet вполне обыденное дело, да и из внешние навешивать никто не мешает, не говоря уже о том, что просто берется любой 32битник по вкусу с MAC на борту.
3. И никаих проблем с совершенно ненужными USB наворотами, "сертификациями", "драйверами" и их конфликтами.

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

Тема очень интересная - мне кажется что быстродействие отнюдь не самая большая ценоость в решении на USB или Ethernet
Кроме того я видел и уже что для простых плат используют переходники с USB на Ethernet
Я согласен также что многие не понимают назначения TCP/IP стека и пытаются использовать болшую чем нужно функциональность для своих приложений
Если интересно давайте четко соберем требования и я как бывший технический редактор сформулирую и оформлю их - и уже тогда все будет ясно = можно даже статью будет написать

Эквивалентно - скажите, как сделать так, что-бы ничего не делать? Дайте мне мои любимые протезы . Ну не нужны они. В данном случае для Ethеrnet, который Вы судя по Вашей реакции не отличаете от TCP/IP на самом деле даже UDP/TCP/IP не нужны - голые фреймы, максимум с чем-нибудь типа IEEE 802.3 в заголовке. Со стороны PC RAW Socket и вперед.

1. USB в даном случае нужно пихать не в FPGA а куда подальше...
2. Реализация MAC Ethernet вполне обыденное дело, да и из внешние навешивать никто не мешает, не говоря уже о том, что просто берется любой 32битник по вкусу с MAC на борту.
3. И никаих проблем с совершенно ненужными USB наворотами, "сертификациями", "драйверами" и их конфликтами.

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

Тема очень интересная - мне кажется что быстродействие отнюдь не самая большая ценоость в решении на USB или Ethernet
Кроме того я видел и уже что для простых плат используют переходники с USB на Ethernet
Я согласен также что многие не понимают назначения TCP/IP стека и пытаются использовать болшую чем нужно функциональность для своих приложений
Если интересно давайте четко соберем требования и я как бывший технический редактор сформулирую и оформлю их - и уже тогда все будет ясно = можно даже статью будет написать

Естественно с таким потоком Ethernet-100 не справиться, соответственно прийдется использовать Gigabit Ethernet.
2. Необходимо иметь возможность в будущем увеличить поток в 2 (или 2.5) раза, т.е. до 240Mbit/s (или 300Mbit/s - это крайняя цифра, выше неё прыгать не собираемся).

Вот мне кажется многие не знают что проще использовать 2 Ethernet порта и Ethernet коммутатор 4x 100 и 1x 1000 на выходе чем разбираться с Gigabit Ethernet
посмотрите что за потоки данных вы создаете и создавайте их на разных портах

[Boris_TS]

Подведу очередные итоги обсуждения:

Теперь вопросы:
1. С чего лучше начать знакомство с Ethernet ?
2. Что лучше использовать чистый Ethernet или еще реализовывать и TCP/IP (в чем достоинства/недостатки обоих решений) ?
3. Исходя из 2, какие микросхемы/сборки лучше использовать ?

К сожалению, вынужден констатировать, что:
Вопрос 1 - остался без ответа (а сейчас для меня он архиважный),
Вопрос 2 - освещён только со стороны трудоёмкости разработки решения (сторона очень важная, я бы даже сказал ключевая), но необходимо всё-таки ответить на вопрос "А нужен ли вообще TCP/IP ??! И чего полезного он действительно может дать ?", т.к. если особой пользы от TCP/IP нет (а пока я склоняюсь к этой мысли), то при обсужденных трудозатратах на его освоение/поддержку тратиться жалко.
Вопрос 3 - можно считать более или менее хорошо обсужденным.

Пока думаю, что воспользуюсь Virtex5 Gigabit Ethernet MAC (по сравнению с Virtex4 у Virtex5 немного дешевле встроенная блочная память). Использовать PowerPC не хочу, может и ошибаюсь, конечно, но думаю, что проще набросать несколько несложных FSM. чем разбираться с EDK... В крайнем случае, если появиться ощущение, что я заблуждался, то воспользуюсь MicroBlase; конечно такое решение хуже встроенного PowerPC с прямым интерфейсом к Ethernet MAC.

Соединения пока планирую делать точка-точка (т.е. от моего комплекса в специально зарезервированную сетевуху).

Поэтому сейчас стоит проблема выбора конкретной микросхемы, сейчас в возможных вариантах стоят XC5VSX35T-1FF665C и XC5VLX20T-1FF323C (на случай использования PowerPC XC5VFX30T-1FF665C).
SX35T - привлекает неплохим количеством встроенной блочной памяти (заметно более дешёвой, чем у всех остальных представителей VIrtex5), цена в 20 килорублей (практически максимальная розничная цена) несколько омрачает прелести применения этого кристалла - но т.к. оная ПЛИС требуется только одна на весь комплекс, то терпимо.
LX20T - привлекает минимальной ценой среди Virtex4/5 с Ethernet MAC (такая ПЛИС стоит в 2 раза меньше, чем SX30, но и ОЗУ в ней в 3.2 раза меньше), а т.к. встроенной блочной памяти мало, то необходимо цеплять что-то внешнее.

Теперь новая пачка вопросов (в добавление к неотвеченному вопрос 1 из предыдущей пачки):
1. Применение SX35T позволит хранить данные на 25мс (при 15МБайтном потоке). Достаточно ли этого времени, чтобы гарантировать устойчивую передачу данных в Windows XP ?
2. Какой должен быть размер буфера (в мс), чтобы гарантировать устойчивую передачу данных в Windows XP (и где это можно прочесть) ?
3. Если использовать внешную память, то что лучше использовать ? (с динамической памятью пока не работал, да и что-то не тянет,.. а может зря ?)
4. Какие "неочень дорогие" микросхемы двухпортовой памяти (али даже готового FIFO) можете посоветовать. От двухпортовой памяти требуется иметь один порт для записи, второй - для чтения.

[SM]

Вопрос 1 - остался без ответа (а сейчас для меня он архиважный),

С прочтения стандартов - 802.3, а затем изучении того, что такое MAC и с чем его едят.

Вопрос 2 - освещён только со стороны трудоёмкости разработки решения (сторона очень важная, я бы даже сказал ключевая), но необходимо всё-таки ответить на вопрос "А нужен ли вообще TCP/IP ??! И чего полезного он действительно может дать ?", т.к. если особой пользы от TCP/IP нет (а пока я склоняюсь к этой мысли), то при обсужденных трудозатратах на его освоение/поддержку тратиться жалко.

Верно, TCP/IP в первую очередь нужен для выхода в сети, построенные на этом протоколе. У Вас же своя собственная сеть, для которой TCP/IP не нужен, а нужен лишь какой то свой простой механизм контроля целостности и доставки с ретрансмитами.

1. Применение SX35T позволит хранить данные на 25мс (при 15МБайтном потоке). Достаточно ли этого времени, чтобы гарантировать устойчивую передачу данных в Windows XP ?

Я бы поставил внешнюю SDRAM. Так, на всякий случай. 25 мс это маловато.

2. Какой должен быть размер буфера (в мс), чтобы гарантировать устойчивую передачу данных в Windows XP (и где это можно прочесть) ?

Прочесть - нигде. Это зависит исключительно от того, что крутится под этой ОС и на сколько корректно оно написано. Сколько... Я бы сделал 100 мс минимум. Так как большой буфер это просто и быстро, а вот отладка и поиск того, что вдруг тормозит, это сложно, долго и муторно.

3. Если использовать внешную память, то что лучше использовать ? (с динамической памятью пока не работал, да и что-то не тянет,.. а может зря ?)

DDR/DDRII с готовой коркой.

4. Какие "неочень дорогие" микросхемы двухпортовой памяти (али даже готового FIFO) можете посоветовать. От двухпортовой памяти требуется иметь один порт для записи, второй - для чтения.

не надо это. Динамика ваши потоки через один порт 10 раз успеет.

PS.
Ethernet MAC можно и в почти любой спартан сунуть. Эт Вас обманул кто-то, что Eth MAC можно сделать только на какой-то части виртексов. Скорее всего речь про PHY, так PHY внешний значительно проще и дешевле, чем юзать монстроПЛИС.

[Aprox]

Вопрос 1 - остался без ответа (а сейчас для меня он архиважный),

Я начинал с учебника по TCP/IP для студентов. И там сразу обнаружил форматы фрэймов Ethernet , и всех специальных управляющих пакетов. Этого мне оказалось достаточным для самостоятельной работы с пакетами в FPGA. Стандарты осваивать не советую- утонете в малосущественных деталях. В стандарты лазить только по четко сформулированным вопросам, но не для начального ознакомления.

Вопрос 2 - освещён только со стороны трудоёмкости разработки решения (сторона очень важная, я бы даже сказал ключевая), но необходимо всё-таки ответить на вопрос "А нужен ли вообще TCP/IP ??! И чего полезного он действительно может дать ?", т.к. если особой пользы от TCP/IP нет (а пока я склоняюсь к этой мысли), то при обсужденных трудозатратах на его освоение/поддержку тратиться жалко.

Мне представляется, TCP был разработан для связи на дальние растояния, когда пакеты путешествуют через маршрутизаторы и роутеры, могут теряться по дороге и перепутываться. Если же речь идет о локалке на обычных свитчах, TCP безусловно излишне сложен. Лучше подходит UDP или RAW пакеты. Самое простое и быстрое в реализации на FPGA- это RAW пакеты. Hо тут возникнут сложности со стороны OС ПК, например в виндах. UDP чуть сложнее за счет необходимости еще в протоколе ARP, но зато в каждой OC ПК вы найдете готовый компонент клиента или сервера. Я лично выбрал UDP вариант, как оптимальный по трудозатратам.

Пока думаю, что воспользуюсь Virtex5 Gigabit Ethernet MAC (по сравнению с Virtex4 у Virtex5 немного дешевле встроенная блочная память). Использовать PowerPC не хочу, может и ошибаюсь, конечно, но думаю, что проще набросать несколько несложных FSM. чем разбираться с EDK... В крайнем случае, если появиться ощущение, что я заблуждался, то воспользуюсь MicroBlase; конечно такое решение хуже встроенного PowerPC с прямым интерфейсом к Ethernet MAC.

Для организации потока данных от периферии я использовал STR912FAW44- это ARM-9 c Ethernet-100 на борту. И добился потока UDP-пакетов в ПК производительностью 86 Мбит/сек. FPGA не потребовалось.

Соединения пока планирую делать точка-точка (т.е. от моего комплекса в специально зарезервированную сетевуху).

Это совершенно необязательно. UDP и RAW пакеты нормально ходят по сети через свитчи.

2. Какой должен быть размер буфера (в мс), чтобы гарантировать устойчивую передачу данных в Windows XP (и где это можно прочесть) ?

Зачем буфер? Как заполнили пакет в памяти данными, так и отправляйте. Он уйдет быстрее, чем сформируется новый пакет. Пропадание пакетов в XP зависит от скорости компа, от типа сетевухи, от типа шины этой сетевухи, от параллельно выполняемых задач. Hа скорости 50 Мбит/сек на моем стареньком и примитивном ПК ни один UDP пакет не пропал (проверялось снифером).

3. Если использовать внешную память, то что лучше использовать ? (с динамической памятью пока не работал, да и что-то не тянет,.. а может зря ?)

Вполне хватило встроенной SRAM на борту STR912. Внешняя память не потребовалась.

[SM]

Да, а что Вас так ксилинксом приплющило? Ведь есть отличные более-менее бюджетные микросхемы, поддерживающие физику 1G Eth - LatticeECP2/M, Arria GX

[DmitryR]

но думаю, что проще набросать несколько несложных FSM. чем разбираться с EDK... В крайнем случае, если появиться ощущение, что я заблуждался, то воспользуюсь MicroBlase; конечно такое решение хуже встроенного PowerPC с прямым интерфейсом к Ethernet MAC.

Microblaze тоже делается через EDK и у него тоже есть прямой интерфейс к MAC. И разобраться с EDK в принципе не сложнее, чем делать простенькие FSM. А в вашем случае я не думаю, что FSM будут на самом деле простыми.

[Boris_TS]

Microblaze тоже делается через EDK и у него тоже есть прямой интерфейс к MAC.

Дело в том, что настолько я успел проглядеть внутренние соединения Virtex5FX, у PowerPC есть аппаратная шина к Ethernet MAC (или я заблуждаюсь ?).

А в вашем случае я не думаю, что FSM будут на самом деле простыми.

Начну делать - увижу что необходимо, тогда и решу. Пока вариант с MicroBlase я не отбрасывал.

Сейчас изучаю решение соседей... и в нем не используются RocketIO от Virtex4/5 (а я почему-то думал, что именно его то и прийдется использовать), если они действительно не нужны, тогда попробую уйти на заметно более дешёвый на Spartan3E/A. О полученном решении обязательно сообщу.

Да, а что Вас так ксилинксом приплющило? Ведь есть отличные более-менее бюджетные микросхемы, поддерживающие физику 1G Eth - LatticeECP2/M, Arria GX

Как обычно с меня требуют решение быстро и с первого раза (совсем работодатель обарзел, привык, что все мои платы для него (9 шт. на каждой по паре ПЛИС - ну не работаем пока с BGA...) работали с первого варианта разводки). С Xilinx работаю около 8 лет, вроде достаточно хорошо работаю, поэтому и плющит, и колбасит (кроме как от их цен); а со средой Lattice пока ну нету времени разбираться, но ничего против этих ПЛИС не имею, и если появиться небольшой передых погляжу на них очень внимательно.

[AlexandrY]

Странно вы решаете эту проблему.
Траблы у вас в PC, а решить их хотите со стороны внешнего железа.
Так как вы подошли к вопросу, так не решают.
Нужно знать точно кто потребитель данных.
Если это системный IDE диск, Win GUI то ловить тут нечего, ваш поток будет тормозить по любому.
И если у вас другого ничего нет (ну там RAID-ы), то выход может быть в балансировании нагрузки на уровне IP маршрутизаторов или VLAN свитчеров.
Т.е. вы применяете два и более компов для записи своего потока, а маршрутизатор по IP или по тэгу VLAN селектирует какой пакет на какой комп.
Посмотрите в ветке про процессоры PowerQUICC, в них что-то есть для данной проблемы.
Т.е. они заданный вами поток точно разрулят. Правда удовольствие не для любителей.

Дальше опять вопрос в том как же вы собираетесь дальше свои данные хранить и индексировать.
Если примените просто Ethernet пакеты то их не поймет никакой движок real-time баз данных.
Если не примените TCP, то можете оказаться зависимым от технологии свитчеров (блокирующие/неблокирующие, c Flow control или без), и это создаст большие сложности при развертывании вне вашей лаборатории.
Далее было бы умным поверх TCP еще использовать прикладной уровень поскольку потом данные придется когда нибудь агрегировать и делать это скорее всего специализированным софтом который для таких целей использует собственные форматы данных.

Вообщем проблемы железа тут только цветочки.

Подведу очередные итоги обсуждения:

К сожалению, вынужден констатировать, что:
Вопрос 1 - остался без ответа (а сейчас для меня он архиважный),
Вопрос 2 - освещён только со стороны трудоёмкости разработки решения (сторона очень важная, я бы даже сказал ключевая), но необходимо всё-таки ответить на вопрос "А нужен ли вообще TCP/IP ??! И чего полезного он действительно может дать ?", т.к. если особой пользы от TCP/IP нет (а пока я склоняюсь к этой мысли), то при обсужденных трудозатратах на его освоение/поддержку тратиться жалко.
Вопрос 3 - можно считать более или менее хорошо обсужденным.

[Boris_TS]

Странно вы решаете эту проблему.
Траблы у вас в PC, а решить их хотите со стороны внешнего железа.

Если внимательно разуть глаза, то можно заметить, что "Проблемы" не просто в PC, а в отмирании PCI 32bit 5V (PCI v2.3) в этих самых персональных компьютерах (т.е. именно в железе)... Ну а в какай области проблема - в такой естественно и решается.

Так как вы подошли к вопросу, так не решают.
Нужно знать точно кто потребитель данных.

Читаем внимательно:

Имеется система сбора данных - ящик 19 дюймовый 4U. Внутри ящика самопальный cross на 10 плат расширения и 1 плата управления. От платы управления шел самопальный канал связи (6 диф. пар по 50МГц) к PCI плате (32бита 5V), втыкаемой в обычный компьютер.

Мне необходимо непрерывное гладкое графическое полноэкранное отображение вводимых данных (ну где-то 1280x1024 @ 100Гц - картинка весьма нагруженная). С PCI всё работает нормально... благо Bus mastering помогает.

Нетрудно догадаться, что применение самопальной PCI платы и непрерывное гладкое графическое полноэкранное отображение врятли будут сдруживаться с какими-либо стандартными программами, а посему логично предположить, что используется какая-то своя специализированная программа. Для исчезновения дискуссий не связанных с темой обсуждения сразу скажу, что данные этой программой успешно накапливаются сотнями гигабайт в своей "базе данных" (если это так можно назвать). Да и не просто накапливаются, но и достаточно хорошо компрессируются, и с выборкой данных из этой груды тоже никаких проблем нет.

Если это системный IDE диск, Win GUI то ловить тут нечего, ваш поток будет тормозить по любому.

Выражу своё резкое несогласие:
1. Поток в 15МБайт/с для HiperTransport/PCI-E (основных коммуникационных артерий современного PC) - это просто смех.
2. Если правильно подбирать железо, то пишет на HDD хорошо (почую, что будет зашиваться один серверный винчестер - поставлю два... и в RAID их).
3. Программы тоже надо уметь писать, если пользовать DirectX и (или) OpenGL (а у нас есть варианты программы для обоих), то даже под Windows графика не тормозит, да и грамотно организованная многопоточность хорошо помогает на современных процессорах (2 и более ядерных). В ПЛИС страшно посчитать количество "так сказать" параллельных потоков, почему же тогда параллельное программирование для CPU считается чем-то из ряда вон выходящим ??!

Дальше опять вопрос в том как же вы собираетесь дальше свои данные хранить и индексировать.

Я не собираюсь хранить, а уже храню:

Как лучше модифицировать имеющееся решение

Ну да, с увеличением потока понадобится поставить не 500ГБ винчестер, а наверное пару то 1ТБ (и в RAID их), ну а если заказчик захочет ещё и надежности побольше (чего, к моему удивлению, за 10 лет работы с оным ну никак не отмечалось), то поставлю 4 HDD по 1-2ТБ.

Если не примените TCP, то можете оказаться зависимым от технологии свитчеров (блокирующие/неблокирующие, c Flow control или без), и это создаст большие сложности при развертывании вне вашей лаборатории.

Вот чтобы не было всех этих проблем:

Соединения пока планирую делать точка-точка (т.е. от моего комплекса в специально зарезервированную сетевуху).

Для того, чтобы не возникало ненужных вопросов - комплекс специализированный. На территории Российской Федерации их требуется всего около 100 шт, естественно конкуренты не дадут занять всю нишу. Железо, в т.ч. и для PC, работающего на объекте подбирается только производителем комплекса.

P.S. Ваши замечания могу считать справедливыми только если Вы по ошибке приняли 120Мбитный поток, за 120БМайтный поток. Но 120БМайтный поток данных через одиночную Gigabit Ethernet линию никак прокачать не удастся.

Вопрос ведь стоял не "в куда" залить данные, а какбы это так поудобнее их выпихнуть из железяки, чтобы уж очень сильно не напрягаться.

[zltigo]

Я вот только думаю, что нормальная реализация контроля целостности и повтора передачи займет столько усилий, что отсутствие ембеддед-процессоров будет очень быстро проклято. А в EDK все готовое: проц, MAC, Linux. Остается написать драйвер устройства сбора данных для Linux - и все.

Вы хоть ПРИМЕРНО представляете себе, сколько времени уйдет у этого "готового TCP/IP Linux" на эту самую перепередачу? Ни о каком ровном многомегабитном потоке и речи идти не может, если встретится сбой. В реальности уровень ошибок на этих десятках метров и тем более при соединении точка точка будет ничтожен и соответственно или с этим мириться или делать заточенные под реальное время системы котроля, препередачи или избыточного кодирования. Использование штатных реализаций TCP/IP есть бред, если только за ними нет больших буферов на передачу на секунды и соответственно многократного запаса по пропускной способности канала.

[SM]

Сейчас изучаю решение соседей... и в нем не используются RocketIO от Virtex4/5 (а я почему-то думал, что именно его то и прийдется использовать), если они действительно не нужны, тогда попробую уйти на заметно более дешёвый на Spartan3E/A.

Я Вам уже объяснял, что трансиверы нужны, если Вы не хотите внешний PHY. Если хотите внешний PHY - трансиверы не нужны.

[Boris_TS]

Я Вам уже объяснял, что трансиверы нужны, если Вы не хотите внешний PHY. Если хотите внешний PHY - трансиверы не нужны.

Просмотрев Virtex-5 FPGA Embedded Tri-Mode Ethernet MAC User Guide я пришел к выводу, что если необходимо работать с медными проводами, то необходима внешняя PHY, а RocketIO (без HPY) может использоваться только для работы с оптическим приемопередатчиком (1000BASE-X). Надеюсь я всё правильно понял ?
Ну а коли в режиме GMII частоты более 125МГц не используются, то можно брать практически любую недорогую ПЛИС.

Если я в чём заблуждаюсь, то прошу меня поправлять (сейчас приходится много чего читать, а после детального прочтения задень более 150 страниц на нерусском, ум за разум заходит к вечеру...)

[jojo]

>Для того, чтобы не возникало ненужных вопросов - комплекс специализированный. На территории Российской Федерации их требуется всего около 100 шт, естественно конкуренты не дадут занять всю нишу. Железо, в т.ч. и для PC, работающего на объекте подбирается только производителем комплекса.

С таким "ценообразованием" можно взять любую ПЛИС средней жирности, подрисовать к ней два доставаемых гигабитных PHY, DDR SDRAM для синтезируемого контроллера. И дело сделано.

По поводу того, как завести этот "колхоз" - зависит от привычности среды разработки. Для Альтеры я подобрал всё типовое и готовое. Даже стыдно, ни строчки своего кода для ПЛИС. Скорость 114 МБ по UDP в одну сторону, не помню, с заголовками кадров IP/UDP или без.

В деле передачи данных из ПЛИС лимит пропускной способности на практике (вроде бы, не углублялся) задаётся межкадровым промежутком (IPG).
Вот куда поток пойдет далее - это вопрос. Приходилось увеличивать буфер стека TCP/IP.

Кстати, как дружат SFP модули с сетями, через них IP гонять можно? Не могу пока проникнуться этими SFP.

[SM]

Все так, трансивер -> SFP -> волокно. Если медь, однозначно внешний PHY.

Кстати, как дружат SFP модули с сетями, через них IP гонять можно? Не могу пока проникнуться этими SFP.

IP можно даже через RS-232 гонять, не то, что через любой транспорт, поддерживаемый SFP.

[Builder]

По поводу того, как завести этот "колхоз" - зависит от привычности среды разработки. Для Альтеры я подобрал всё типовое и готовое. Даже стыдно, ни строчки своего кода для ПЛИС. Скорость 114 МБ по UDP в одну сторону, не помню, с заголовками кадров IP/UDP или без.

Не подскажете, а что типовое было на IP и UDP? Нашёл только у альтеры "Video Over IP Reference Design", там есть такие модули,
но где добыть, не вижу. Или ещё что-то есть?

[Muxa]

По поводу USB переходников, не всё так просто.

боюсь, что в случае USB-IDE вашей плис придётся прикидываться дисковым устройством и в ней придётся реализовать хотя бы часть протокола ATA... т. е. как мин. его почитать.

по поводу CY68013 сейчас начаты поставки универсального мостика FT2232H в котором реализовано много разных интерфейсов, вплоть до эмуляции шины 8051 на частоте 30 Мгц.
у меня сейчас стоИт похожая задача и я почитал про эту микруху. всё вроде бы хорошо. имеется драйвер и дллька с описанным АПИ. но увы, мне решение не подошло. у меня жёсткие ограничения на стоимость и я могу поставить максимум это СПЛД Альтера 3128 или что то подобное. второе ограничение, это время реакции на переданную команду. отклик должен быть не позже нескольких микросекунд. реально USB решение даже на 480мб/сек похоже не позволяет этого сделать. во всяком случае, используя готовые мостики.

дело в том, что все передачи на шине начинаются по команде хоста. поскольку шина физически это одна витая пара, то двунаправленная передача не возможна. хост обязательно должен послать команду чтения девайса. всем занимается планировщик виндоус, а он работает от 1мс таймера. в АПИ есть параметр времени опроса и минимальноработающее значение состовляет 2мс.
кроме того, в баре мод на хай спид блоки имею размер 512 байт только. это означает что по приходе команды чтения ваш буфер должен быть заполнен не менее чем на 510байт (2байта служебных). если такого не случиться, то транзакция завершится с ош. а контроллер девайса (FT2232) сам отловит таймаут по умолчанию через 16мс (время тоже программируется, но с шагом 1мс)

резюмируя, протокол USB (пусть и Hi-Speed) заточен на на передачу потоков всегда по инициативе хоста. реакция на событие в конечном устройстве реально может последовать через 2мс (независимо от скорости). при изхронной передаче возможные скорости реально до 40-45мб/сек, но надо быть готовым к буфферизации данных на интервал до 2мс. кроме того в изохронном режиме протокол реализует только обнаружение ош. передачи. повтор передачи испорченных данных нужно делать самому. и он будет имет большой лаг (не менее 2мс)

вот такие есть ограничения...
если они вам не мешают, то посмотрите подробнее.

вообще, я тоже советую эзернет. мак левел можно реализовать в плис, а физический (PHY) сейчас реализуют даже в розетках. даже микруху подбирать не надо. я это совсем недавно видел в описании демоплат на атмеловские 32 бит. проц.

[DmitryR]

Вы хоть ПРИМЕРНО представляете себе, сколько времени уйдет у этого "готового TCP/IP Linux" на эту самую перепередачу?

Представляю. Нисколько, если настроить все на работу по DMA.

Просмотрев Virtex-5 FPGA Embedded Tri-Mode Ethernet MAC User Guide я пришел к выводу, что если необходимо работать с медными проводами, то необходима внешняя PHY, а RocketIO (без HPY) может использоваться только для работы с оптическим приемопередатчиком (1000BASE-X). Надеюсь я всё правильно понял ?
Ну а коли в режиме GMII частоты более 125МГц не используются, то можно брать практически любую недорогую ПЛИС.

Почти так. Еще RocketIO умеет 1000BASE-CX (но вам это вряд ли пригодится), а также, что несколько более интересно, SGMII. Что же касается недорогой ПЛИС - то все так, лишь бы еще вписалось по емкости.

[jojo]

Не подскажете, а что типовое было на IP и UDP? Нашёл только у альтеры "Video Over IP Reference Design", там есть такие модули,
но где добыть, не вижу. Или ещё что-то есть?

NIOS2.
Протоколы IP и UDP реализованы программно в т.н. "наивной" манере, когда все уровни TCP/IP спрессованы в одну функцию. Эту наивность можно перенести в цифровой автомат, если нужно.

Контрольную сумму UDP можно занулить, но возместить это циклической суммой в данных UDP.

Кривое выравнивание протокола UDP (16 бит) возмещается двумя первыми пустыми байтами в данных UDP, после чего остальные данные сами выравниваются по 32 бита.

Высокая скорость передачи кадров достигается использованием контроллера DMA. В моем случае это был встроенный в сам MAC DMA-мастер.

Порядок байт шины можно поменять в нужную сторону, если он не подходит. Тогда пострадают регистры команд и состояний, что в 100-1000 раз менее затратно.

Если конкретно = NIOS2+Cyclone2+National Gig Phy + MAC IFI GMACII 1.7 + самый простой DDR контроллер Altera.
Лучше попробовать купить Realtek, а то National - "утюг" и по размерам, и по мощности.

[Builder]

NIOS2.
Протоколы IP и UDP реализованы программно в т.н. "наивной" манере, когда все уровни TCP/IP спрессованы в одну функцию. Эту наивность можно перенести в цифровой автомат, если нужно.

... CUT ...

Если конкретно = NIOS2+Cyclone2+National Gig Phy + MAC IFI GMACII 1.7 + самый простой DDR контроллер Altera.
Лучше попробовать купить Realtek, а то National - "утюг" и по размерам, и по мощности.

Ясно, я то-ж к такому варианту скланялся, теперь больше уверенности - сначала сделать полностью программную реализацию,
а потом, после тестирования при необходимости в железо...
А код сами писали или какой готовый стек брали за снову?
Поковырял тут пару стеков, в принципе если IP-UDP в принципе не сложно, особенно если есть куда подсматривать

[jojo]

Стек сам писал. Это же "наивная реализация" ("НР"), в ней почти ничего нет. Пишется, глядя в логи Ethereal и в бумаги RFC. Рекомендую.

Готовые стеки для микроконтроллера либо велики (lwip), либо это те же "НР", только с многоэтажной оберткой (ucip и OpenTCP). Плюс еще проблемы с выравниванием по 16 бит и многократным копированием.

[zltigo]

Представляю. Нисколько, если настроить все на работу по DMA.

Все понятно, так и думал, что не представляете - это проблема TCP/IP протокола и возможного упирания в ширину канала, а отнюдь не затрат времени uC-MAC и мантра "DMA DMA.." тут ни причем.

[AlexandrY]

Ага, народ даже не подозревает, что в большинстве случаев DMA работает медленнее программной пересылки.
И действительную пользу от DMA можно получить только в многозадачных решениях под управлением RTOS.
А если думать о масштабировании и разделении потоков, то однозначно надо использовать многозадачный многинтерфейсный стек с мощным процессором сделанным не на FPGA
В данной теме я уверен человек просто никуда не денется и ему придется заниматься масштабированием с расчеплением TCP потоков если надо сделать в сумме больше 100 MBit/s

Никакой самопал на UDP не спасет ситуацию. Сетевая карта перегруженного компа просто молча отбрасывает UDP пакеты.
UDP уровень в стеке TCP/IP нужен для протоколов которые обеспечивают целостность данных на более верхних уровнях, например SNMP или L2TP тоннели.
В данном случае переносить контроль целостности на еще более верхний уровень будет нетривиальной задачей хотя в некоторых случаях есть интересные решения, как тоннель с мultilink PPP поверх UDP делающий один логический канал на нескольких физических Ethernet линиях.
Эта фишка реализована в PowerQUICC на аппаратном уровне! Ваще кода писать не надо!

Все понятно, так и думал, что не представляете - это проблема TCP/IP протокола и возможного упирания в ширину канала, а отнюдь не затрат времени uC-MAC и мантра "DMA DMA.." тут ни причем.

[blackfin]

Эта фишка реализована в PowerQUICC на аппаратном уровне! Ваще кода писать не надо!

"Инвайт?" "Просто добавь воды?"

[Aprox]

Никакой самопал на UDP не спасет ситуацию. Сетевая карта перегруженного компа просто молча отбрасывает UDP пакеты.

Применение Jumbo- пакетов сильно уменьшают вероятность отбрасывания UDP-пакетов в перегруженном компе.

[jojo]

В нормальных процессорах DMA таки ускоряет пересылку данных. Особенно в синхронных шинах.
Пересылка - последовательность операций ввода-вывода.

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

>И действительную пользу от DMA можно получить только в многозадачных решениях под управлением RTOS

Её успешно получают и в однозадачной среде без РТОС.


>UDP уровень в стеке TCP/IP нужен для протоколов которые обеспечивают целостность данных на более верхних уровнях, например SNMP или L2TP тоннели

Целостность данных в своем протоколе в ПЛИС реализовать можно оптимальным для себя образом, а не так, как в TCP.

Кто хочет, сделает перезапрос потерянных блоков, кто не хочет - блоки потеряет.
У ПЛИС буфер в DDR памяти на весь массив данных спокойно можно сделать.

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

У автора всё оборудование в одной комнате. Глобально-сетевые навороты здесь не требуются.

[AlexandrY]

В нормальных процессорах DMA таки ускоряет пересылку данных. Особенно в синхронных шинах.
Пересылка - последовательность операций ввода-вывода.

Лучше расскажите где вы этот миф прочитали.

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

Эта логика не работает в коммуникационных процессорах. Надо знать и учитывать правила шинного арбитража.

Её успешно получают и в однозадачной среде без РТОС.

Не представляю как. Но не будем здесь об этом, а то основная тема погибнет

Целостность данных в своем протоколе в ПЛИС реализовать можно оптимальным для себя образом, а не так, как в TCP.

У этой системы два конца и было сказано о затыках на стороне PC. Значит задача должна облегчаться для PC. Один из реальных стандартных вариантов - multilink

Кто хочет, сделает перезапрос потерянных блоков, кто не хочет - блоки потеряет.
У ПЛИС буфер в DDR памяти на весь массив данных спокойно можно сделать.

Здесь вы в фантазиях ограничены. Поскольку все диктуется механизмом сохранения данных в PC.
На таких скоростях и с цепочкой буферов на всех устройствах от сетевой карты до CPU и диска может не быть возможности переповторов на уровне приложения.

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

Такую скорость только iperf умеет показывать на обычном десктопе.

У автора всё оборудование в одной комнате. Глобально-сетевые навороты здесь не требуются.

Неплохая комната в 40 м да еще с гальванической развязкой.
Тут суровое пром. применение проглядывает.

[Builder]

CUT
А если думать о масштабировании и разделении потоков, то однозначно надо использовать многозадачный многинтерфейсный стек с мощным процессором сделанным не на FPGA
CUT

Может предложите конкретно, на чём можно сделать кроме FPGA пересылку потока 100 МБАЙТ по гигабиту с гарантией доставки (не голый UDP)?
А то что-то когда доходит до поиска, ничего не нахожу. Заманчиво поставить некий комуникационный проц и не иметь гемора с
реализацией всёго самому на FPGA, но что-то не находится проца, который может взять у моего устройства по локальной шине 100 МБАЙТ и передать по гигабиту с гарантией доставки (не голый UDP).
А то помнится все говорили что ARM за 15$ есть решение, только вот где тот ARM...
Да, и хотелось-бы не что-то абстрактное, а то что реально купить можно. Думаю будет не только мне интересно.

[jojo]

>Лучше расскажите где вы этот миф прочитали

В этот миф смотрю осциллографом и сетевым анализатором. Процессоры DSP и синтезируемый Nios2.
В мире DSP и ПЛИС то, что я говорю о пересылке DMA, никого не смутит.

>>Программная пересылка медленнее хотя бы потому, что разбавлена операциями увеличения указателей и поддержанием работы цикла
>Эта логика не работает в коммуникационных процессорах. Надо знать и учитывать правила шинного арбитража

У нас есть примерно два варианта - Nios/Microblaze или готовый процессор. Применительно к ним эта логика работает.


>У этой системы два конца и было сказано о затыках на стороне PC. Значит задача должна облегчаться для PC. Один из реальных стандартных вариантов - multilink

Сколько PC и сколько линков нужно, чтобы передать 125 Мбайт в секунду? 1 и 1. Сам передавал.
Блин, заболтали. 114 МБ пользовательских данных. 125, если голый сокет.

>Здесь вы в фантазиях ограничены. Поскольку все диктуется механизмом сохранения данных в PC.
На таких скоростях и с цепочкой буферов на всех устройствах от сетевой карты до CPU и диска может не быть возможности переповторов на уровне приложения.

Как может не быть, если приложение всегда способно перезапросить блок данных. Разве что дисковая система не справится, что зависит о потребностей автора. А тогда вопрос не в передаче.

Меня это вообще удивляет, пропускная способность нутра компьютера достигла десятка гигабайт в секунду, а поток опять не лезет.

На точкеNet, конечно, это может и не заработать.

>Такую скорость только iperf умеет показывать на обычном десктопе.

WinSocket + приемный поток + увеличенный буфер сокета (!) показывает такую скорость


> комната
пусть 40 м. Гигабитный Ethernet, пусть и в двух экземплярах, спасет отца русской демократии (с).



>Может предложите конкретно, на чём можно сделать кроме FPGA пересылку потока 100 МБАЙТ по гигабиту с гарантией доставки (не голый UDP)?

Да, и о гарантиях. Меня всегда интересовало, что будет гарантировать TCP, если вытащить сетевой провод из хаба.
Голый UDP с пользовательким протоколом гарантирует всё, что нужно.

>но что-то не находится проца, который может взять у моего устройства по локальной шине 100 МБАЙТ и передать по гигабиту с гарантией доставки (не голый UDP).

Проц такой есть. У AD это TigerSharc TS20x, у Техаса что-нибудь в духе C64xx. Главное, чтобы была внешняя шина 100-125 МГц в синхронном режиме. Наличие последовательных портов с LVDS у процессора тоже сособствует.

Арм за 15 долл здесь не катит.

[Aprox]

Может предложите конкретно, на чём можно сделать кроме FPGA пересылку потока 100 МБАЙТ по гигабиту с гарантией доставки (не голый UDP)? А то что-то когда доходит до поиска, ничего не нахожу.

И не найдете. Поскольку 100 МБАЙТ по гигабиту получали только в лабораторных условиях с голыми Jumbo-пакетами размером до 16К.

А то помнится все говорили что ARM за 15$ есть решение, только вот где тот ARM...
Да, и хотелось-бы не что-то абстрактное, а то что реально купить можно. Думаю будет не только мне интересно.

Про ARM за 15$ говорили в контексте скорости 86 МБИТ/СЕК на голых UDP пакетах.

[Builder]

И не найдете. Поскольку 100 МБАЙТ по гигабиту получали только в лабораторных условиях с голыми Jumbo-пакетами размером до 16К.

Так хоть что близкое найти. Только PowerPC вот советовали, но там проц 400MHZ, явно не хватит.
Про максимум, вы тесили или как? Слышал что 2 компа выжимают под 100мбайт без напряга. Сам ещё не тестил, но проверю.

Про ARM за 15$ говорили в контексте скорости 86 МБИТ/СЕК на голых UDP пакетах.

Да тут в соседней ветке AlexandrY советовал ARM с Гиг MAC-ом, но как-то напряг с такими.
Вот и хотел узнать, где такие берут.

[SM]

Народ, вы все позабывали то, откуда берутся данные. Собрать их оттуда без ПЛИС решения вообще не видно.

[Boris_TS]

Народ, вы все позабывали то, откуда берутся данные. Собрать их оттуда без ПЛИС решения вообще не видно.

Точно.

Сейчас прорабатываю варианты реализации - какую Eth PHY проще купить (и использовать), какое внешнее ОЗУ легче достать и т.п. Но архитектура уже более или менее определилась: две груды LVPECL линий заходят на Spartan-3AN (благо, хоть это и не документированно для этой ПЛИС, но при желании, можно собрать LVPECL выходы аналогичные "Virtex-E LVPECL"), благополучно преобразуются в 2 потока (данных и команд), далее запихиваются во внешнее ОЗУ. При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные.

Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни).
Также не может не радовать и то, что выступившим удалось передать более 100МБайт/с по Gigabit Ethernet, мне же всего-то требуется только 15МБайт/с (или, если очень захочется заказчику увеличить количество датчиков - ну никак не более 30МБайт/с - только для меня остается загадной: нафига ставить еще больше датчиков - их и так в полноценной системе их дофига, а обычно заказывают с 50%-60% каналов сбора данных).

[Builder]

Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни).

Один из плюсов UDP - стандартные возможности програмирования, например в винде стандартно можно работать только с TCP и UDP, если ниже, придётся использовать WinPCap: http://netgroup-serv.polito.it/winpcap/
Если WinPCap допустим, можно и без UDP попробовать.

Сейчас прорабатываю варианты реализации - какую Eth PHY проще купить (и использовать), какое внешнее ОЗУ легче достать и т.п.

И к чему склоняетесь?

преобразуются в 2 потока (данных и команд), далее запихиваются во внешнее ОЗУ. При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные.

Кстати, как-то пролистал стандарт на TCP, и меня терзают смутные мысли, что если начать делать такой протокол, получится почти тот-же TCP, только без уровня функций пользователя. Ни кто не пробовал, насколько это так?

[blackfin]

Кстати, как-то пролистал стандарт на TCP, и меня терзают смутные мысли, что если начать делать такой протокол, получится почти тот-же TCP, только без уровня функций пользователя. Ни кто не пробовал, насколько это так?

Есть ещё древний RDP (rfc908+rfc1151):

The Reliable Data Protocol (RDP) is designed to provide a
reliable data transport service for packet-based applications
such as remote loading and debugging. The protocol is intended
to be simple to implement but still be efficient in environments
where there may be long transmission delays and loss or non-
sequential delivery of message segments.

[SM]

Один из плюсов UDP - стандартные возможности програмирования, например в винде стандартно можно работать только с TCP и UDP, если ниже, придётся использовать WinPCap: http://netgroup-serv.polito.it/winpcap/
Если WinPCap допустим, можно и без UDP попробовать.

На самом деле все не так сложно и ограничено в выборе. Стандартные возможности программирования позволяют без проблем написать свой любой протокол, который будет работать с NDIS-уровнем, и представляться в юзермоде хоть через те же обычные сокеты, что и TCP/IP, хоть как-то по своему. Тоже мне сверхзадача. И никакие пкапы не нужны.

Я в общем тоже считаю, что никакие UDP там не нужны. Голый Eth уровень, и своя удобная лично для себя система контроля доставки и ретрансмитов (на UDP ее кстати тоже реализовывать, так что UDP это просто лишняя возня в ПЛИС)

[:-)]

Хотелось бы продолжить данную тему.

Есть желание реализовать гарантированную доставку данных на базе fast Ethernet от внешнего устройства на базе FPGA на компьютер с максимально возможной скоростью.

В распоряжении имеется демо-плата (Spartan 3e starter kit). На ней соответственно имеется: FPGA Spartan 3e500, Ethernet phy LAN83C185, память DDR (32M x 16).

После ознакомления с данной темой возник ряд вопросов:

1) Реализовывать протокол UDP + IP, по-видимому смысла нет.
2) Соответственно стоит использовать пакеты Ethernet. На этом месте возникает первый вопрос: какой тип пакета использовать (Ethernet II, IEEE 802.3 или IEEE 802.2)? В голове сейчас некоторая каша, поэтому сильно не пинайте за, возможно, глупые вопросы.
3) На каком уровне обеспечивать гарантию доставки данных? Т.е. Например, я решил передавать голые кадры Ethernet II. Тогда, на сколько я понимаю, потребуется придумать некоторый свой заголовок, который будет, например, нести информацию о номере посланного пакета. На компьютере программа-сервер будет принимать пакеты и при обнаружении пропуска будет запрашивать внешнее устройство повторно передать потерянный пакет. Т.е. гарантия доставки выполняется приложением, принимающим данные? Либо есть какие-либо встроенные в операционную систему средства (продолжение вопроса в п.4)?
4) Как на компьютере принимать голые пакеты (под Windows и под Linux)? Использовать библиотеку pcap (winpcap/libpcap)? Или достаточно встроенных в операционную систему средств?
5) Стандарт IEEE 802.2 описывает LLC. После беглого пролистывания стандарта решил, что LLC type 3 как раз то, что я бы хотел реализовать: гарантированная доставка данных без установления соединения. Вопрос вот в чём: есть ли какая-то поддержка данного механизма в операционных системах (windows, Linux)? Т.е. есть ли встроенные в операционную систему средства, которые облегчили бы создание соединения, гарантирующего доставку данных?
6) На сколько я понимаю, реализация в лоб схемы ARQ (automatic repeat request: отправили пакет, дождались подтверждения, отправили следующий, либо если не дождались - повторно отправили текущий) приведет к получению мизерной скорости передачи данных. Как с этим бороться? Отправлять непрерывно пакеты, храня их буфере до получения подтверждения? Есть ли примеры реализации, доступные для просмотра в интернете? Есть ли другие алгоритмы?

[o_khavin]

Хотелось бы продолжить данную тему.

Есть желание реализовать гарантированную доставку данных на базе fast Ethernet от внешнего устройства на базе FPGA на компьютер с максимально возможной скоростью.

Для начала имеет смысл озвучить количественный эквивалент выражения "максимально возможная скорость". :-)

[:-)]

Для начала имеет смысл озвучить количественный эквивалент выражения "максимально возможная скорость". :-)

Не менее 80 мбит/с

[o_khavin]

Не менее 80 мбит/с

А... так речь всё-же о пропускной способности. А то первый пост был м... неоднозначным.
А чем так нравится ethtrnet? Или подразумевается большая (больше 3-х метров) удалённость девайса от компьютера? Я это к тому, что есть много микросхем USB интерфейса, где всё уже готово. Я сам достигал где-то 160-200 мбит/с с применением ez-usb от cypress-а.

[:-)]

Ethernet нравится тем, что, во-первых, имеются некоторые знания о нём, в отличие от USB, во-вторых, коллеги планируют его использовать. В-третьих, расстояние в перспективе, действительно, может составить более 3 м. И, в-четвертых, под Ethernet имеется указанная выше демо-плата.

Уточню исходный вопрос. На данный момент планирую использовать голые Ethernet фреймы (формат кадра - Ethernet II). Главная сложность продумать реализацию алгоритма гарантированной доставки данных.

Сам алгоритм описан в данном посте.

При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные.

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

Может быть, где-то есть примеры реализации похожих механизмов передачи данных?

[XVR]

Главная сложность продумать реализацию алгоритма гарантированной доставки данных.

'Гарантированная доставка данных' - это TCP или нечто аналогичное по сложности. Можно взять соотвествующий RFC (по TCP) и выкинуть из него все ненужное.

[Aprox]

Уточню исходный вопрос. На данный момент планирую использовать голые Ethernet фреймы (формат кадра - Ethernet II). Главная сложность продумать реализацию алгоритма гарантированной доставки данных.

Если используете BASE 100-TX "точка в точку", без свитчей, в пределах 100м, то заморачиваться на предмет гарантированной доставки данных не следует вообще. Что же касается RAW-пакетов, то возникнут приличные софтовые проблемы на стороне PC. В то время как для UDP существуют готовые и многократно проверенные компоненты в С-Builder и Delfi. Советую UDP пакеты, которые отличаются от RAW только размером хидера,- это для FPGA не проблема. Зато на стороне PC получите громадный выигрыш от стандартного решения.

[warrior-2001]

В данной ветке проскакивало упоминание о "Video Over IP Reference Design". Не могли бы добрые люди скинуть в закрома данный проект. Кит для него куплен. По опыту - тут получить проект быстрее, чем от Альтеры.


--------------------------------------------
Проект найден. Вопрос снят.