.Проектирование устройств и систем с высокоскоростными соединениями

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

Рис. 2.20. Компоненты эквалайзера внутри кабеля

При использовании стандартных протоколов многие параметры, такие как соединители, уровни сигналов и т.д., заданы. В случае пользовательских протоколов детали физического взаимодействия могут не быть так хорошо определены. Так, если оба элемента SERDES одинаковы или имеют одинаковое терминальное напряжение (VTT), используется связь по постоянному току. Это не требует соединительных конденсаторов, а значит, не возникнет дополнительных проблем (рис. 2.21).

Рис. 2.21. Связь по переменному и постоянному току

51

Вопросы для самоконтроля

1.Какова роль линейного кодирования в структуре SERDES?

2.В каком случае можно отказаться от эластичного буфера

вструктуре SERDES?

3.Почему в структуре кадра линейного кода 64b/66b есть

поле «тип»?

4.Для какого из кодов 64b/66b или 8b/10b время выравнивания на приеме меньше и почему?

5.Какую задачу решает многофазная схема тактирования?

6.Какова природа межсимвольной интерференции и способы ее устранения в SERDES?

7.Как в технологии CML формируется выходной сигнал?

8.Какова роль эквалайзера в структуре SERDES?

52

3.ПРОЕКТИРОВАНИЕ УСТРОЙСТВ

СВЫСОКОСКОРОСТНЫМ ВВОДОМ-ВЫВОДОМ

Задачи проектирования высокоскоростного ввода-вывода включают соглашение о протоколе приема-передачи, обеспечение целостности сигнала, требований к мощности потребления, экранированию, проектированию печатной платы и выбор соединителей и кабелей. Моделирование и тестирование прототипа также важно для успешного создания высокоскоростного ввода-вывода.

3.1. ВЫБОР/РАЗРАБОТКА ПРОТОКОЛОВ

Протоколы скоростного ввода-вывода специфицируют следующие элементы:

•Формат данных. Определяет величину разрешения для видео- и аудиопротоколов, использование единиц и нулей для представления специфических величин или значений.

•Подканалы. Часто существует необходимость в нескольких разных каналах в одном соединении. В общем случае используют каналы для передачи управления, статуса и вспомогательных данных.

•Расслоение данных (Data Striping). Общей функцией про-

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

•Встраивание (Embedding). Протокол определяет механизм встраивания данных в протокольный поток или пакет.

•Обнаружение ошибок и обработка. Протокол определяет механизм обнаружения ошибки и реакцию на нее.

•Управление потоком. Протокол может определять механизм управления потоком от динамического распределения пропускной способности подканалов до изменения скорости ведения символов ожидания для коррекции часов.

•Адресация/переключение/продвижение данных. Необходимость в адресации данных обусловлена необходимостью их переключения и продвижения.

•Физический интерфейс. Для обеспечения совместимости между устройствами протокол специфицирует уровни сигнала драйвера, предыскажение и т.д.

53

3.1.1. Стандартные протоколы

Представим краткий обзор стандартных протоколов. XAUI. 4-канальный интерфейс (нагрузка 2,5 Гбит/с, ско-

рость на линии 3,125 Гбит/с) для 10-Gigabit Ethernet.

PCI Express. Взята прежняя параллельная структура PCI и преобразована в высокоскоростную последовательную структуру. Верхние уровни протокола остаются совместимыми, обеспечивая легкую адаптацию с действующими PCI-системами.

Serial RapidIO. Последовательная версия старой параллельной спецификации RapidIO, которая является достаточно гибкой и иногда используется как метод сопряжения с несколькими протоколами, такими как PCI и Infiniband.

FiberChannel. Протокол FiberChannel всегда был последовательным стандартом, а скорость росла из года в год. К передаче по оптическому волокну была добавлена передача по меди.

Infiniband. Взаимодействие между блоками через медь или оптическое волокно. Infiniband-кабели стали популярными для мультигигабитных соединений на дальность в несколько метров. Спецификация допускает варьирование устройствами и сложностью и включает спецификации повторителей, коммутаторов или концентраторов для расширения количества соединяемых устройств. Infiniband также может быть использована для сложной конфигурации системы, использующей Infiniband-коммутаторы и консоли управления (рис. 3.1).

Advanced Switching. Протокол для коммутируемой связной архитектуры строится на таких же протоколах физического уровня и уровня данных, как и PCI Express.

PICMG. PICMG – консорциум из 600 компаний, которые совместно развивают открытую спецификацию высокопроизводительных стандартизованных архитектур объединительных плат. Многие из этих стандартов используют другие промышленные стандарты, такие как PCI и Infiniband.

ATCA (Advanced Telecom Computing Architecture) или AdvancedTCA. Это стандарт PICMG, являющийся спецификацией для следующего поколения телекоммуникационных шкафов. Его целью является облегчение возможности мультивендорного взаимодействия, обеспечивающего гибкость и масштабируе-

54

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

Рис. 3.1. Infiniband-коммутаторы и консоли управления

Aurora. Aurora является относительно простым протоколом, который решает задачи только канального и физического уровня. Он разработан Xilinx для того, чтобы другие протоколы, такие как TCP/IP или Ethernet, легко переносились поверх него. Протокол использует одну или более высокоскоростных последовательных линий (дорожек) (рис. 3.2).

В дополнение к физическому интерфейсу Aurora определяет структуру пакета и рекомендуемую процедуру для встраивания пакетов других протоколов, расслоение данных и управление потоком (рис. 3.3).

Протокол определяет процедуру инициализации для установления валидности соединений и описывает процедуру отказа

55

Рис. 3.2. Канал Aurora

Рис. 3.3. Перенос других протоколов в Aurora

от соединений с неисправностями. Aurora не имеет системы адресации и поэтому не поддерживает коммутацию. Протокол не определяет, как обнаруживаются и исправляются ошибки.

3.1.2. Разработка и реализация пользовательского протокола

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

Пусть необходимо передавать поток данных с постоянной скоростью от одной платы к другой. Данные – это 12-разрядные отсчеты АЦП, образующиеся со скоростью 150 000 000 отсчет/с,

56

т.е. скорость передачи нагрузки в виде сериализованных данных должна быть 150 000 000·12 = 1,8 Гбит/с. Необходимо определить структуру кадра, символы для выравнивания границ и холостые символы для коррекции часов. Будем использовать линейный код 8b/10b и позаимствуем из других стандартов этого кода символы для маркировки структуры кадра. На рис. 3.4 представлена базовая структура кадра, где SF (Start of Frame) – маркер начала кадра, а EF (End of Frame) – маркер конца кадра.

Рис. 3.4. Базовая структура кадра

Далее определим символы для SF, EF и маркера простоя/ ожидания I (Idle), скорость передачи и длину кадра. Размер поля данных кадра должен быть таким, чтобы гарантировать достаточное число SF-символов для выравнивания границ и I-сим- волов для обеспечения коррекции часов. В нашем случае, поскольку необходима нагрузка в 1,8 ГГц, легко выбрать одну из часто используемых линейных скоростей в 2,5 ГГц. Это обеспечит передачу нагрузки с учетом кода 8b/10b в 2,5·8/10 = 2 ГГц без учета служебных символов. Поэтому можно использовать линейную скорость 2,5 ГГц для нагрузки в 1,8 ГГц.

Поскольку необходимо передавать данные между платами, это означает, что передачу обеспечивают два разных тактовых генератора. Следовательно, необходим механизм коррекции часов. При рассмотрении вопроса о длине поля данных приходится балансировать между двумя противоречивыми требованиями. Большая длина кадра – меньше доля накладных расходов, а значит, доступна более широкая полоса пропускания. Небольшая длина кадра – больше доля служебных символов. Необходимо оценить оба варианта и выбрать среднее. Итак, надо передать 1,8 ГГц, доступно 2 ГГц.

Если поле данных переносит 2048 байт, заголовок 10 байт (2 для SF, 2 для EF и 6 для I), то накладные расходы составят 10/2058, или около 0,5 %. Доступные же накладные расходы составляют (2 – 1,8)/2, или 10 %. Можно сделать кадр в 20 раз короче и остаться в пределах доступного бюджета. Для коррекции часов необходимо передавать небольшими кадрами.

57

Пусть точность опорных тактовых генераторов составляет 20 ppm. Если использовать 2-символьную последовательность для I, то коррекция должна выполняться максимально за каждые 49 999 символов. Расстояние между I символами может быть меньше этой величины. В большинстве случаев делают 1/3 от максимального значения. Для нашего примера выбрана величина 2048, приблизительно равная 1/24 от максимального значения.

На рис 3.5 представлен окончательный вариант протокола передачи 1,8 Гбит данных между двумя платами.

Рис. 3.5. Протокол передачи 1,8 Гбит данных между двумя платами

На рис. 3.6 приведена структурная схема аппаратной реализации пользовательского протокола на программируемой логике.

Код 8b/10b преобразует 8-битовые данные в 10-битовые символы. В примере на кодирование поступают 12-битные данные. Можно, например, дополнить 12 бит до 16 и полученные

58

данные преобразовать в два 10-битных символа. Это потребует увеличения полосы пропускания не в 10/8 = 1,25 раза (это то, что мы ожидаем от кода 8b/10b), а в 20/12 = 1,7 раза. На рис. 3.7 приведена схема преобразования пары соседних 12-битовых данных в три 10-битных символа. Эту схему реализует узел «Преобразование 12/8 бит», интерфейс которого с окружающей средой при-

веден на рис. 3.8 под именем conv_2_12_to_3_8.

Рис. 3.6. Структурная схема аппаратной реализации пользовательского протокола

Рис. 3.7. Схема преобразования данных перед кодированием 8b/10b

conv_2_12_to_3_8

Rd

rd_mode(1…0) data_out8(7…0) data_in12(11…0)

Рис. 3.8. Интерфейс узла «Преобразование 12/8 бит»

59

Спад сигнала Rd инициирует очередной этап трехэтапного преобразования последовательности из 12-битных входных данных data_in12, номер этапа (0, 1 или 2) поступает на двухразрядный вход rd_mode. Ниже приведена программа-специфи- кация на VHDL узла conv_2_12_to_3_8, содержащая единствен-

ный процесс CONVERT_12_8. Сигналы data_11_4 и data_11_8

запоминают соответствующие части двух соседних 12-битных данных, поступающих с входа data_in12.

VHDL программа-спецификация узла «Преобразование 12/8 бит»

library IEEE;

use IEEE.STD_LOGIC_1164.all; entity conv_2_12_to_3_8 is

port(

reset_n : in STD_LOGIC; rd : in STD_LOGIC;

rd_mode : in STD_LOGIC_VECTOR(1 downto 0); data_in12 : in STD_LOGIC_VECTOR(11 downto 0); data_out8 : out STD_LOGIC_VECTOR(7 downto 0)

);

end conv_2_12_to_3_8;

architecture conv_2_12_to_3_8 of conv_2_12_to_3_8 is signal data8: STD_LOGIC_VECTOR(7 downto 0); signal data_11_4: STD_LOGIC_VECTOR(7 downto 0); signal data_11_8: STD_LOGIC_VECTOR(3 downto 0); begin

data_out8<=data8; CONVERT_12_8: process(rd,reset_n)

begin

if reset_n='0' then data8<="00001111"; data_11_8<=(others=>'0'); data_11_4<=(others=>'0');

elsif falling_edge(rd) then case rd_mode is

when "00"=> data8<=data_in12(7 downto 0);

data_11_8<=data_in12(11 downto 8); when "01"=>

data8(3 downto 0)<=data_11_8;

data8(7 downto 4)<=data_in12(3 downto 0);

60