[Beby 5]

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

 

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

 

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

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

[Beby 5]

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

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

 

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

[murmel1 0]

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

[Beby 5]

Рекомендую задуматься о 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 0]

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

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

[SM 0]

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

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

[zltigo 1]

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

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

[des00 25]

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

 

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

[SM 0]

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

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

[Beby 5]

На всякий случай опишу чуть подробнее работу имеющихся шин.

От блока управления (так я прозвал большую интерфейсную плату) к каждой плате расшинения через 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 1]

CY7C68013 ... Wiznet....

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

[murmel1 0]

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

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

 

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

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

 

Спасибо !

[SM 0]

Оказывется Вы на самом не имеете представления не только об 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 28]

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

 

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

 

Я бы взял все таки одну FPGA. можно и Spartan3 , но лутше Virtex4 FX серии, +SDRAM +внешний PHY.

Ethernet в такой конфигурации поднимается не сложно - все зависит что вы хотите получить

-полный TCP/IP стек это Microblaze или PowerPC + lwIP.

- или некое его подмножество - PicoBlaze или совсем без проца, чисто апаратно.

Я например в свое время делал обработку данных радара на Spartan3s400 со 100Mb Ethernet каналом.

 

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

 

Успехов! Rob.