Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: реализация switch
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
line
Добрый день!

Не приходилось заниматься такими вещами, а требуется свитч 32 х 32 сериальных канала. Причем, тербуется параллельная работа нескольких каналов при свободных соответствующих входах-выходах (как это называется - "неблокирующий свитч" чтоли???).

Подскажет ли кто умную мысль? Или что бы прочесть, или где бы пример глянуть? Пасиб.
iosifk
Цитата(line @ Aug 2 2007, 14:51) *
Добрый день!

Не приходилось заниматься такими вещами, а требуется свитч 32 х 32 сериальных канала. Причем, тербуется параллельная работа нескольких каналов при свободных соответствующих входах-выходах (как это называется - "неблокирующий свитч" чтоли???).

Подскажет ли кто умную мысль? Или что бы прочесть, или где бы пример глянуть? Пасиб.

какие скорости потоков?
Если меньше, чем 500/32 то можно перекидывать через память. Если потоки быстрые - то через кучу FIFO, вот примерно так....
Удачи!
line
Цитата(iosifk @ Aug 2 2007, 16:12) *
какие скорости потоков?
Если меньше, чем 500/32 то можно перекидывать через память. Если потоки быстрые - то через кучу FIFO, вот примерно так....
Удачи!

Потоки по 100 Мбит. Буферная память на каждом конце есть.
Проблема в том, как создать матрицу переключений потоков + организовать управление переключением.
Как создать матрицу я вроде нашел, что надо ставить на каждый выход по мультиплексору, на которые подключить все входы - логично...
Но вот арбитраж всех этих мультиплексоров??? wacko.gif
DmitryR
Цитата(line @ Aug 2 2007, 16:34) *
Потоки по 100 Мбит. Буферная память на каждом конце есть.
Проблема в том, как создать матрицу переключений потоков + организовать управление переключением.
Как создать матрицу я вроде нашел, что надо ставить на каждый выход по мультиплексору, на которые подключить все входы - логично...
Но вот арбитраж всех этих мультиплексоров??? wacko.gif

Рассмотрим начальный момент, когда все порты неактивны. В некий порт начинает вливаться информация. Она направляется в линию задержки длинной в заголовок. Когда заголовок полностью в линии задержки - он декодируется и по результатам декодирования переключается соответствующий мультиплексор и на этом мультиплексоре ставится флаг "занят". Если потом кто-то хочет в этот же мультиплексор - он видит флаг "занято" и на передающем сегменте объявляет коллизию. Когда пакет прошел - флаг "занято" с мультиплексора (то есть выходного порта) снимается.

Разумеется, алгоритмы с полным буферированием (когда при занятости порта не объявляется коллизия, а пакет кладется в память и передается "потом") эффективнее, но они и сложнее на порядок, поэтому обычно управление такими коммутаторами осуществляется с помощью процессора, а не автомата.
line
Цитата(DmitryR @ Aug 2 2007, 16:44) *
Рассмотрим начальный момент, когда все порты неактивны. В некий порт начинает вливаться
...
Разумеется, алгоритмы с полным буферированием (когда при занятости порта не объявляется коллизия, а пакет кладется в память и передается "потом") эффективнее, но они и сложнее на порядок, поэтому обычно управление такими коммутаторами осуществляется с помощью процессора, а не автомата.

Буферирование не надо.
С остальным согласен.
И далее, видимо, нужен хитрый арбитр ---последовательно???--- просматривающий запросы от входных каналов и в случае свободного запрашиваемого выходного производящий подключение?
iosifk
Цитата(line @ Aug 2 2007, 17:06) *
Буферирование не надо.
С остальным согласен.
И далее, видимо, нужен хитрый арбитр ---последовательно???--- просматривающий запросы от входных каналов и в случае свободного запрашиваемого выходного производящий подключение?

Если буферирования не будет, то это же блокирующий коммутатор.
А по жизни такие штуки делают так:
нет никаких арбитров или просматривающих автоматов...
А есть адрес выходного порта. Если заголовок имеет адрес данного выходного порта, то порт пропускает данный пакет, если адрес не соответствует - то не пропускает. Так устроены Ethernet-switch. А для того, чтобы свитч узнал, кто на каком порте сидит есть широковещательные пакеты. На них все обязаны ответить и при этом их адреса попадают в хэш-таблицу. Но у Вас видимо адреса заранее известны, поэтому Вы можете определить объем памяти типа САМ. Вот и все хитрости....
удачи!
line
Цитата(iosifk @ Aug 2 2007, 17:27) *
Если буферирования не будет, то это же блокирующий коммутатор.

Буферирование входных пакетов есть на премной стороне. Я фактически разбираю пакеты из буферных ФИФО приемников.

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

Цитата(iosifk @ Aug 2 2007, 17:27) *
А по жизни такие штуки делают так:
нет никаких арбитров или просматривающих автоматов...
А есть адрес выходного порта. Если заголовок имеет адрес данного выходного порта, то порт пропускает данный пакет, если адрес не соответствует - то не пропускает. Так устроены Ethernet-switch. А для того, чтобы свитч узнал, кто на каком порте сидит есть широковещательные пакеты. На них все обязаны ответить и при этом их адреса попадают в хэш-таблицу. Но у Вас видимо адреса заранее известны, поэтому Вы можете определить объем памяти типа САМ. Вот и все хитрости....
удачи!

Тут все так. а вот в тригеры это уложить бы еще smile.gif
DmitryR
Цитата(line @ Aug 2 2007, 17:06) *
Буферирование не надо.
С остальным согласен.
И далее, видимо, нужен хитрый арбитр ---последовательно???--- просматривающий запросы от входных каналов и в случае свободного запрашиваемого выходного производящий подключение?

это не арбитр называется, а priority encoder, поиск младшей единицы:

if(!busy)
if(запрос[0])
select<=0;
else
if(запрос[1])
select<=1;
else
if(запрос[2])
select<=2;
else
...
line
Цитата(DmitryR @ Aug 2 2007, 17:43) *
это не арбитр называется, а priority encoder, поиск младшей единицы:

if(!busy)
if(запрос[0])
select<=0;
else
if(запрос[1])
select<=1;
else
if(запрос[2])
select<=2;
else
...

О. То есть это на каждом мультиплексоре еще такая штука должна присутствовать? Вроде ситуация проясняется! Ладно, пора домой, завтра на свежую голову все взвешу.
CaPpuCcino
ну если это в ветке FPGA то я так понимаю что центральным элементом будет ПЛИС. а что за ПЛИС? почему ПЛИС? что за протокол? какая архитектура платформы (в общих чертах - раскрывать ноу-хау не прошу, просто интересно узреть логику принимаемых решений)
des00
А вы не попробуйте пошариться по опенкоресам. В разделе генераторы для вишбона smile.gif))

В тех генераторах можно сделать как shared bus так и switch архитектуры. Причем Свич архитектуры хитрые, с менеджерами потоков и разделением по времени (для фифо правда не подходит).

а 100 мегабит можно и на не высоких тактовых легко разрулить. главное с шириной шины данных разобраться и способом комутации.

Удачи.
line
Цитата(CaPpuCcino @ Aug 2 2007, 18:53) *
ну если это в ветке FPGA то я так понимаю что центральным элементом будет ПЛИС. а что за ПЛИС? почему ПЛИС? что за протокол? какая архитектура платформы (в общих чертах - раскрывать ноу-хау не прошу, просто интересно узреть логику принимаемых решений)

Пока стоит Spartan3. ПЛИС - потому что планируется потом все в АСИК. Платформа - ЦП с обвязкой + ПЛИС для интеграции внешних интерфейсов. Там же нужен еще и свитч, т.к. в системе много таких распределенных вычислителей, которые нужно между собой связывать. Все что подробнее - военная тайна. biggrin.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.