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

[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 пока еще не работал...

[murmel1]

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

[zltigo]

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

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

[SM]

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

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

[zltigo]

CY7C68013 ... Wiznet....

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

[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, типа, нигде не работает и вообще "покойник"

[Михаил_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 мегабайт .

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

[Михаил_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. Есть выбор. Я ничего не упустил?

[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

[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 только приходилось иногда слышать...

[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) можете посоветовать. От двухпортовой памяти требуется иметь один порт для записи, второй - для чтения.

[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 линию никак прокачать не удастся.

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