Добрый день! Есть ПЛИС в которой реализованы всякие относительно медленные интерфейсы ввода вывода и один высокоскоростной SPI интерфейс который в себе должен объединять потоки данных с этих интерфейсов:

Реализации отдельных этих интерфейсов написаны, но вот как объединить лучшим образом данные с узкими потоками в один широкий поток не могу придумать.
Какую лучше глобально выбрать стратегию реализации объединения этих потоков? Где лучше разместить буфферы и как их связать?. Делал ли кто-нибудь что-нибудь подобное? Возможно есть какие-нибудь открытые шины на VHDL, предназначенные для такого рода арбитража.
Прошу прощения за столь глобальный и нечеткий вопрос, но боюсь изобретать велосипед так как могу это сделать неграмотно в связи с отсутствием опыта.

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

Вопрос первый. Если все модули пассивные, то должен быть арбитраж... Это понятно. И надо сделать хотя бы один активный модуль, который займется пересылками. Но не это главное...
Вот главный вопрос. А какой протокол передачи по тем интерфейсам, которые "справа"... Ну скажем, кто считает контрольные суммы, делает перезапросы и т.д.
Или Вы получив байт "справа" добавляете к нему "адрес" и перегоняете "налево"???
Но и в этом случае, все что придет из "правой части" надо "запакетить". Ведь в SPI тоже могут быть ошибки и могут понадобиться перезапросы... Так что начинайте с этого. Поскольку трехстабильных шин в ПЛИС не бывает, то будут мультиплексоры. А нарисовать мультиплексоры и арбитр - 5 минут дело.

Спасибо за ответ!

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


Должен объединятся модуль SPI Slave(в который из вне ПЛИС входит один высокоскоростной поток данных и выходит один такой же)
со всеми низкозкоскоростными модулями.

То есть реализовать очереди FIFO на основе внутренней блочной двухпортовой памяти для каждого низкоуровневого интерфейса, и получается в один порт будет писать/читать низко-скоростной интерфейс а из второго порта будет читать/писать высоко-скоростной? Или я не правильно понял?

2iosifk
Спасибо, Да, видимо придется "пакетить" еще наверное до того как отправлять налево, но тут сложность в том что нужно определить на какие размеры дробить эти пакеты. И получается справа нужно еще реализовать логику обработки ошибок. Хотелось конечно уйти от всяческих протоколов и сделать такой обмен наиболее прозрачным, но ваши слова действительно заставили задуматься еще и об этом. Таки наверно придется делать классическую схему: первый байт пакета размер, потом пару каких-нибудь служебных байтов с адресом и потом уже данные.
Спасибо, действительно нужно начать с проработки протокола, буду думать

Сообщение отредактировал dotnot - Feb 17 2014, 18:35

Начинать надо с "Гайки М3", если не читали...(Ну пусть будут высказывания, я уже привык... )

Самый простой способ, подключить процессор софтовый, NIOS или Microblaze. Частоты интерфейсов невысокие, размеры FIFO могут быть значительные если делать на современных ПЛИС. Процессор успеет отработать любой алгоритм без задержек для интерфейсов. И позволит Вам отладить протокол обмена гибко, а вопрос задачи перейдет в область C/C++ что значительно проще, чем создавать state машину с кучей FIFO.

PS: Я не ошибся 143 человека читают эту тему ????? Похоже electronix ддосят

Сообщение отредактировал vzelenuk - Feb 17 2014, 18:43

я тоже за "гайку М3", однако похоже что у ребят даже её пока что нет ;-)

Я думаю так: если не найдут эту гайку, то и с шиной будут кранты... А поисковик никто не отменял...

Если вы сильны в программировании МК - поставьте софткорный проц. Не так красиво, но очень просто. Если же сильны в обычном "крестьянском" VHDL/Verilog - тогда пишете фифо к каждому из интерфейсов и параллельно пишете/читаете их.
Хотя на вышеописанных скоростях мне кажется МК более адекватным задаче. Какой-нибудь из TI Stellaris/Tiva, в них аппаратных интерфейсов дофигища, остальное сделать софтово. Проц на 160 МГц, рулить 2-мегагерцовым ногодрыгательством будет не напрягаясь. Или поставить 2 МК: ведущий и ведомый - расширитель портов, если лень писать битбэнговые протоколы. Дешево и быстро.

Что-то мне кажется, что все эти софт-коры и процы на 160 МГц это какое-то монстроидальное решение простейшей задачи... Тут судя по картинкам, ПЛИСка на 3000 LE нужна самая дешовая....

Сейчас проц на 160 МГц стоит 4-5 баксов Дешевле будет только если плисину где-то украсть.

Это далеко не самый простой способ и вот почему :
1. Логики отожрёте на софт процессор с кучей периферии на порядок больше.
2. Фифошки они ж никуда не денутся, природу не обманешь.
3. Сколько говорите времени вы готовы убить на отладку многпоточного софта?
4. В случае если надо выжать максимум производительности - тупо не успеете софт процессором прерывания обрабатывать.

З Ы А вообще это решение из серии "сляпать в визарде кусочек говна по-быстрому, а дальше пусть программисты мудохаются".

Сейчас ПЛИС на 3000LE стоит те же 4-5 баксов. А теперь найдите проц с 8 уарт, 8 i2c и 4 SPI за эту сумму

Уже написали выше, что потребуется арбитраж и работа с пакетами. Плюс автор хочет встроить отработку ошибок, а это ретрансмиссии по каждому из интерфейсов. Реализовывать это на CPLD не хватит места никак, нужны FIFO, нужна дополнительная буферная память для ретрансмиссий и много чего нужно, как минимум отдельная стейт машина на каждый медленный интерфейс. В результате ТС придется иметь дело с протоколами, а как только возникает слово "протокол" у меня лично сразу же срабатывает ответ "процессор". Только на процессоре реализовать и отладить протокол проще и быстрее. Возможно потом, после отладки протокола все это можно реализовать "в железе". Но то, что удастся "упихать" в CPLD скажу знаменитым "не верю".

Сообщение отредактировал vzelenuk - Feb 18 2014, 02:08

Функции контроля ошибок можно на данное устройство и не возлагать по двум причинам :
1. Если всё спроектировано грамотно, то вероятность ошибок в любом из интерфейсов пренебрежимо мала.
2. Эти функции более свойственны главному процессору в системе, который там в любом случае уже есть.