реализация switch, какие есть варианты Опции

[line]

Добрый день!

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

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

[iosifk]

Добрый день!

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

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

какие скорости потоков?
Если меньше, чем 500/32 то можно перекидывать через память. Если потоки быстрые - то через кучу FIFO, вот примерно так....
Удачи!

[line]

какие скорости потоков?
Если меньше, чем 500/32 то можно перекидывать через память. Если потоки быстрые - то через кучу FIFO, вот примерно так....
Удачи!

Потоки по 100 Мбит. Буферная память на каждом конце есть.
Проблема в том, как создать матрицу переключений потоков + организовать управление переключением.
Как создать матрицу я вроде нашел, что надо ставить на каждый выход по мультиплексору, на которые подключить все входы - логично...
Но вот арбитраж всех этих мультиплексоров???

[DmitryR]

Потоки по 100 Мбит. Буферная память на каждом конце есть.
Проблема в том, как создать матрицу переключений потоков + организовать управление переключением.
Как создать матрицу я вроде нашел, что надо ставить на каждый выход по мультиплексору, на которые подключить все входы - логично...
Но вот арбитраж всех этих мультиплексоров???

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

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

[line]

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

Буферирование не надо.
С остальным согласен.
И далее, видимо, нужен хитрый арбитр ---последовательно???--- просматривающий запросы от входных каналов и в случае свободного запрашиваемого выходного производящий подключение?

[DmitryR]

Буферирование не надо.
С остальным согласен.
И далее, видимо, нужен хитрый арбитр ---последовательно???--- просматривающий запросы от входных каналов и в случае свободного запрашиваемого выходного производящий подключение?

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

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

[line]

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

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

О. То есть это на каждом мультиплексоре еще такая штука должна присутствовать? Вроде ситуация проясняется! Ладно, пора домой, завтра на свежую голову все взвешу.