[DmitryR 0]

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

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

[Beby 5]

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 3]

Странно вы решаете эту проблему.

Траблы у вас в 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 - можно считать более или менее хорошо обсужденным.

[Beby 5]

Странно вы решаете эту проблему.

Траблы у вас в 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 1]

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

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

[SM 0]

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

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

[Beby 5]

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

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

Ну а коли в режиме GMII частоты более 125МГц не используются, то можно брать практически любую недорогую ПЛИС.

 

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

[jojo 0]

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

 

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

 

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

 

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

Вот куда поток пойдет далее - это вопрос. Приходилось увеличивать буфер стека TCP/IP.

 

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

[SM 0]

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

 

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

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

[Builder 1]

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

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

но где добыть, не вижу. Или ещё что-то есть?

[Muxa 0]

По поводу 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 0]

Вы хоть ПРИМЕРНО представляете себе, сколько времени уйдет у этого "готового 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 0]

Не подскажете, а что типовое было на 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 1]

NIOS2.

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

 

... CUT ...

 

Если конкретно = NIOS2+Cyclone2+National Gig Phy + MAC IFI GMACII 1.7 + самый простой DDR контроллер Altera.

Лучше попробовать купить Realtek, а то National - "утюг" и по размерам, и по мощности.

Ясно, я то-ж к такому варианту скланялся, теперь больше уверенности - сначала сделать полностью программную реализацию,

а потом, после тестирования при необходимости в железо...

А код сами писали или какой готовый стек брали за снову?

Поковырял тут пару стеков, в принципе если IP-UDP в принципе не сложно, особенно если есть куда подсматривать :)

[jojo 0]

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

 

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