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

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

Имеется система сбора данных - ящик 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 пока еще не работал...

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

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

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

Рекомендую задуматся о 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. Может, конечно, у моих знакомых ребят руки кривые - поэтому так и работает. А поэтому мне и интересно на что именно стоит тратить время - с каким стандартным интерфейсом разбираться ?)

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

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

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

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

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

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

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


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

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

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


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


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

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

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

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

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

Спасибо !

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

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

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


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

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

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

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

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

Успехов! Rob.

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

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

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

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

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

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

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

Эквивалентно - скажите, как сделать так, что-бы ничего не делать? Дайте мне мои любимые протезы . Ну не нужны они. В данном случае для 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 и получаете точка-точка.





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

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

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

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

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

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

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

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

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

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

Успехов! Rob.

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

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

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

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

А без 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 шиной.

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



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



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




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




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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Причем я об этом сказал значительно раньше 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 мм влез. Поэтому и знаю про затраты....

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

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

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


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

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



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



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



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

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

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

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

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

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



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

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

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

Упустили главное. Засовывание и отладка корки, что УСБ, что МАК, одинаковый геморрой недели на две, особенно если впервые, а поднятие передачи с мостом - вопрос получаса. Плюс, если впервые, еще работа по откручиванию всяких там вишбонов, 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 мм

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

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

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

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

Фуххх... Вернулся из 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 только приходилось иногда слышать...

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

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

IMHO тогда так:

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

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

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

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

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

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

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

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