Разработка контроллера протокола MIL-STD-1553B на ПЛИС. Части 1, 2, 3, 4

Разработка контроллера протокола MIL-STD-1553B на ПЛИС. Часть 1

Автор: Дайнеко Дмитрий

Аннотация: Существует множество интерфейсов информационного обмена, используемых в промышленных и коммерческих электронных устройствах, например SPI, RS-232, RS-485, Ethernet, USB. Также с избытком хватает справочных материалов и примеров реализации контроллеров этих интерфейсов.

 

Введение

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

  • MIL-STD-1553B (бортовая авиация Министерства обороны США);
  • ARINC-429 (гражданская авиация);
  • STANAG-3919B (модернизированный 1553B);
  • ASCB (легкие летательные аппараты);
  • HSDB (истребители F-22, вертолет RAH-66 Comanche);
  • FibreChannel (компьютерная промышленность и авиационная отрасль);
  • 646 Ethernet Local Area Network (коммерческая авиация).

Каждый из этих интерфейсов отличается скоростью обмена данными, размером посылки, совмещенной или раздельной линией приема/передачи данных и другими параметрами.

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

В статье проанализирован полный процесс реализации контроллера протокола MIL-STD-1553B, начиная с описания протокола, как логического, так и физического уровня, выбора компонентов, создания схемы, написания HDL-кода проекта контроллера интерфейса и заканчивая моделированием в ModelSim с использованием testbench.

Автор выбрал именно этот протокол, так как, несмотря на то, что этот документ был разработан по заказу Министерства обороны США в 1970-х годах, он до сих пор широко применяется в авиационной промышленности. Автор лично разрабатывал устройства, имеющие в своем составе контроллер протокола MIL-STD-1553B или его отечественный аналог — МКИО (мультиплексный канал информационного обмена). Статья будет полезна начинающим разработчикам цифровой электроники, имеющей в своем составе ПЛИС. Кроме того, автор решил представить этот материал так, как если бы начинающему разработчику была поставлена задача сконструировать устройство обмена данными по протоколу MIL-STD-1553B, а этой темой он раньше не занимался.

Итак, статья содержит следующие разделы:

  • описание протокола MIL-STD-1553B;
  • выбор элементной базы;
  • создание структурной схемы устройства;
  • написание HDL-кода проекта;
  • моделирование HDL-кода проекта в ModelSim.

В связи с тем, что объем статьи не позволяет опубликовать ее полностью в одном номере, материал разделен на четыре части. В первой части описаны особенности протокола MIL-STD-1553B, необходимые электронные компоненты, а также рассмотрена структурная схема устройства.

 

Описание протокола MIL-STD-1553B

Не будем углубляться в подробности протокола, так как полностью этот стандарт можно найти в Интернете [1]. Мы приведем в статье лишь ту информацию, с помощью которой начинающий разработчик сможет понять, что конкретно представляет собой этот протокол. Автор считаем важным предложить различные варианты реализации физического и логического уровня контроллера под нужный нам интерфейс обмена данными, так как в реальной ситуации перед специалистом редко когда ставится задача, в точности такая же, как в представленном разработчику материале.

Итак, стандарт MIL-STD-1553B был разработан по заказу Министерства обороны США и изначально предназначался для использования в военной авионике, но в дальнейшем его стали применять и в гражданских системах.

Каналы обмена информацией, выполненные по MIL-STD-1553B, имеют шинную организацию. Есть одна общая магистраль, а к ней, через гальваническую развязку, подключаются абоненты. Количество абонентов может достигать 31 (рис. 1).

 

Рис. 1. Структура магистрали

 

Рассматриваемый нами протокол предусматривает резервирование. То есть каждый из абонентов может быть подключен к двум каналам — основному и резервному, которые в иностранной литературе обозначаются как channel A и channel B соответственно.

Все абоненты на магистрали подразделяются на три вида:

  • КК — контроллер канала. Центральное устройство системы. Отправляет командные слова (КС) и информационные данные остальным абонентам. На одной магистрали может быть только один КК.
  • ОУ — оконечное устройство. Одно из 31-го периферийного устройства. Ожидает командные слова от КК, обрабатывает их и отдает ответное слово (ОС) обратно на КК. Каждый из ОУ имеет уникальный адрес разрядностью 5 бит.
  • М — монитор. Нечто вроде отчетного устройства. Следит за информацией в канале. Собирает статистику и пр. Монитор — безадресное устройство и не выдает в магистраль никакой информации. В данном случае монитор можно сравнить с «черным ящиком» самолета, который записывает переговоры пилотов и показания датчиков.

Стандарт MIL-STD-1553B предусматривает возможность организации иерархической системы, то есть каждое из ОУ может быть «интеллектуальным», а значит, является контроллером канала со своими оконечными устройствами нижнего уровня.

Рассмотрим физический уровень подключения абонента к магистрали. Стандарт предусматривает два вида подключения — с одинарной и двойной трансформаторной развязкой. Выбор схемы подключения определяется расстоянием от абонента до магистрали (рис. 2). Здесь IT — изолирующий трансформатор; CT — согласующий трансформатор; Ri1 = 55 Ом; Ri2 = 0,75Zo; Zo — волновое сопротивление линии магистрали (characteristicimpedance), которое составляет 70–85 Ом на частоте 1 МГц; Vp-p — значение напряжения peak-to-peak (размах).

 

Рис. 2. Два вида схемы подключения абонента к магистрали

 

По поводу рис. 2 следует уточнить, что одинарная трансформаторная развязка используется, если протяженность соединения до основной магистрали не превышает ≈30 см (по стандарту — один фут). Двойная трансформаторная развязка используется, если протяженность соединения не превышает ≈6 м (по стандарту — 20 футов).

Под абонентом понимается цифровая система управления для организации и обработки пакетов протокола на логическом уровне, а также драйвер физического уровня. В качестве цифровой системы управления может использоваться микроконтроллер или ПЛИС. Драйвер — это устройство, предназначенное для преобразования уровней напряжений в магистрали в логические уровни КМОП или ТТЛ.

Итак, особенности физического уровня мы рассмотрели. Теперь перейдем к логическому уровню протокола.

Информация в мультиплексном канале передается с частотой 1 МГц словами по 20 бит. Слова передаются пакетами. Количество слов в пакете может быть разным, в зависимости от вида пакета (мы рассмотрим это далее).

Необходимо отметить, что вся информация на магистрали передается в коде «Манчестер-2». Это означает, что наша цифровая система управления должна иметь в своем составе кодер и декодер этого кода.

«Манчестер-2» относится к самосинхронизирующимся кодам и имеет нулевую постоянную составляющую. Передача нулей и единиц определяется не уровнем, а переходом с уровня на уровень (рис. 3).

 

Рис. 3. Передача логических нуля и единицы в коде «Манчестер-2»

 

Протокол MIL-STD-1553B предусматривает также два вида синхросигнала (SYNC C и SYNC D), которые позволяют отличать командные слова от информационных. Вид синхросигналов SYNC C и SYNC D представлен на рис. 4.

 

Рис. 4. Синхросигналы SYNC C и SYNC D

 

Согласно стандарту этого протокола слова могут иметь три различных формата:

  • командное слово (КС);
  • информационное слово (ИС);
  • ответное слово (ОС).

Битовый состав этих слов приведен на рис. 5.

 

Рис. 5. Формат слов

 

Командное слово передается от контроллера канала оконечному устройству. Командное слово содержит в себе адрес ОУ (Address Remote Terminal, ADDR RT), которому предназначена информация, субадрес (sub-address, SUBADDR) и сколько именно слов (N) будет передано на это ОУ или принято с него. Бит приема-передачи (Write-Read, WR) говорит о том, в каком направлении будут передаваться последующие за командным словом информационные слова. Если WR = 0, контроллер канала передает данные на оконечное устройство. Если WR = 1, контроллер канала принимает данные от оконечного устройства.

Если командное слово содержит не субадрес, а признак команды (Command Indication, CI), то вместо количества слов передается команда (Command, COM).

Информационное слово содержит только данные разрядностью 16 бит и может передаваться как от контроллера канала к оконечному устройству, так и в обратном направлении. Что и понятно — информацию нужно передавать как на периферию, так и на центральную машину.

Ответное слово передается оконечным устройством на контроллер канала. Оно необходимо для подтверждения того, что периферия приняла пакет. Для того чтобы контроллер канала знал, от кого пришло ответное слово, в нем содержится адрес ОУ. Остальные биты несут служебную информацию:

  • A — признак ошибки в сообщении.
  • B — инструментальный бит.
  • C — запрос на обслуживание.
  • X— зарезервировано, может использоваться по усмотрению разработчика.
  • D — признак принятия групповой команды.
  • E — признак занятости абонента.
  • F — флаг неисправности абонента.
  • G — признак принятия управления каналом.
  • H — флаг неисправности.

В каждом из этих слов используется бит паритета (Parity, P). Бит паритета должен иметь такое значение, чтобы общее количество единиц в слове (за исключением синхросигнала) было нечетным. Если поле ADDR RTимеет значение «11111», то посылка адресована всем оконечным устройствам. Именно это объясняет то, что всего оконечных устройств может быть не 32, а 31.

Признак команды CI имеет значение «00000» или «11111». Все остальные значения — это субадрес (SUBADDR). Использование дополнительных команд управления позволяет, например, блокировать и разблокировать передатчик резервной линии. (Подробно об этом написано в стандарте.)

Следует упомянуть инструментальный бит (B). Использование инструментального бита позволяет мониторам отличать командные слова от ответных. Значит, при использовании этого бита количество возможных значений SUBADDR сокращается с 30 до 14. Если в поле «количество слов» N указана цифра 0, то имеется в виду 32 слова.

На рис. 6 приведен пример контрольного, информационного и ответных слов в виде манчестерского кода.

 

Рис. 6. Примеры слов в манчестерском коде

 

На рис. 6а представлена передача командного слова с требованием оконечному устройству с адресом 5 (ADDR RT = 5) принять (так как WR = 0) набор данных с субадресом 2 (SUBADDR = 2) в количестве девяти информационных слов (так как N = 9). Бит паритета в конце этого слова равен 0, потому что количество единиц в слове, не считая синхросигнала, нечетно.

На рис. 6б представлено также командное слово, но с требованием оконечному устройству с адресом 3 передать (так как WR = 1) обратно набор данных с субадресом 7, в количестве слов 32 (так как N = 0).

На рис. 6в представлено информационное слово. Напомним, что его от других слов отличает синхросигнал SYNC D. Поле D имеет значение 1A37 hex (hex означает, что число представлено в шестнадцатеричном виде).

На рис. 6г представлено ответное слово, переданное от оконечного устройства с адресом 5.

На этих временных диаграммах видно, что спектр сигнала при обмене информацией по протоколу MIL-STD-1553B имеет две составляющие:

  • 1 МГц — при передаче либо всех нулей, либо всех единиц;
  • 0,5 МГц — при передаче чередующихся нулей и единиц.

Завершая раздел описания протокола, рассмотрим разновидность пакетов, которыми обмениваются абоненты (рис. 7).

 

Рис. 7. Разновидность пакетов

 

На рис. 7а представлен пакет передачи информации от контроллера канала оконечному устройству. Заголовком пакета в этом случае является командное слово, содержащее адрес нужного оконечного устройства, субадрес и количество слов, которые контроллер канала собирается передать. Далее, без всяких временных задержек, один за другим, передаются все информационные слова. После передачи последнего информационного слова должен быть выдержан тайм-аут t2 (2–10 мкс), перед тем как оконечное устройство отправит ответное слово, сообщающее контроллеру канала о состоянии принятых данных. Следующий пакет можно начинать передавать, только выдержав тайм-аут t1 (не менее 2 мкс). Необходимо добавить, что если контроллер канала собирается передать информационное слово всем абонентам, то в этом случае ответное слово в пакете отсутствует.

На рис. 7б представлена структура пакета при передаче данных от оконечного устройства на контроллер канала. Заголовком пакета является командное слово с соответствующим битом приемопередачи. Далее, выждав тайм-аут t2,, оконечное устройство сначала передает обратно в магистраль ответное слово и сразу за ним, без всяких задержек, нужное количество информационных слов, указанное в командном слове. Следующий пакет также можно начинать передавать только после тайм-аута t1.

Протокол MIL-STD-1553B предусматривает передачу данных от одного оконечного устройства другому. Структура этого пакета представлена на рис. 7в.

 

Выбор элементной базы

В этом разделе автор представляет некоторых производителей электронных компонентов, необходимых для конструирования устройства, способного обмениваться информацией по протоколу MIL-STD-1553B.

Как уже было упомянуто в предыдущем разделе, минимальный набор компонентов, необходимых разработчику, чтобы связать некую цифровую систему управления с магистралью стандарта MIL-STD-1553B, состоит из драйвера (приемопередатчика) и трансформатора (изолирующего и/или согласующего).

В таблице 1 приведены некоторые производители приемопередатчиков протокола MIL-STD-1553B, а в таблице 2 — производители трансформаторов этого же протокола.

 

Таблица 1. Производители приемопередатчиков

Производитель

Компонент

Напряжение питания, В

Габариты, мм

Примечания

ЗАО «Элкус»

EL-12N

+5, +12, –12

30×44

Только основной канал. Дополнительный компонент — симметрирующий конденсатор

EL-12R

+5, +12, –12

33,8×38,4

Основной и резервный каналы. Дополнительный компонент — симметрирующий конденсатор на каждый канал

EL-15N

+5, +15, –15

30×40

Только основной канал. Дополнительный компонент — симметрирующий конденсатор

Data Device Corporation

BU-63152

+5

16×16

Основной и резервный каналы

BU-63155

+5

7×7

Только основной канал

BU-67401L

+3,3

7×7

Основной и резервный каналы

Holt Integrated Circuits

HI-1565

+5

7×7

12,8×10,4

25×8

Основной и резервный каналы

HI-1570

+5

12,8×10,4

25,5×8

Основной и резервный каналы. Возможность регулировки амплитуды сигнала в магистраль

HI-1575

+3,3

9×9

6×6

Основной и резервный каналы. Встроенный кодер-декодер

 

Таблица 2. Производители трансформаторов

Производитель

Компонент

Коэффициент передачи

Габариты, мм

Примечания

АО «Мстатор»

(схема сопоставления аналогов ТИЛ и ТИС)

ТИЛ3В

(меньший аналог: ТИС1-1 и ТИС2-1;

аналог с увеличенной мощностью: ТИЛ4В)

1; 0,5; 0,2

12,5×12,5×6,5

Используется в связке с 15-В приемопередатчиками

ТИЛ5В

(меньший аналог: ТИС1-2 и ТИС2-2)

1; 0,64; 0,26

12,5×12,5×6,5

Используется в связке с 12-В приемопередатчиками

ТИЛ6В

(меньший аналог: ТИС1-3 и ТИС2-3)

1:2,5

1:1,79

12,5×12,5×6,5

Используется в связке с 5-В приемопередатчиками

Beta Transformer Technology Corporation

B-3226

1:2,5

1:1,79

15,88×15,88×6,2

Два коэффициента передачи. С общей точкой

B-2206

1:1,41

12,7×8,9×6,35

Без общей точки

B-2208

1:1,41

12,7×8,9×6,35

С общей точкой

B-3229

1:1,79

12,7×8,9×6,35

С общей точкой

B-3230

1:2,5

12,7×8,9×6,35

С общей точкой

B-3227

1:2,5

1:1,79

15,88×15,88×7

С общей точкой

Premier Magnetics

PB-DB2705

1:1,41

12,7×8,9×6,35

С общей точкой

PB-DB2707

1:1,41

12,7×8,9×6,35

С общей точкой

PB-DB2725

1:2,5

1:1,79

15,87×15,87×9,52

Два коэффициента передачи. С общей точкой

PB-DB2791S

1:2,5

10,16×10,16×4,7

–

PB-DB2795

1:1,79

10,16×10,16×4,7

–

PB-DB2745M

1:2,5

1:1,79

10,92×10,92×4

Два коэффициента передачи. С общей точкой

 

Обсудим компоненты приемопередатчиков из таблицы 1. Первое — на рынке присутствуют драйверы протокола MIL-STD-1553B, требующие для своей работы не одно, а несколько номиналов напряжения питания. А дополнительная цепь питания только для одной микросхемы увеличивает габариты устройства и усложняет его. Второе — при выборе приемопередатчика в плане питающего напряжения следует обратить внимание на то, какие уровни напряжения ввода/вывода поддерживает система управления, которая будет подключена к приемопередатчику. Например, если мы пользуемся 5-В приемопередатчиком, а входные буферы управляющей микросхемы питаются от +3,3 В, то следует убедиться, что «лог. 1» с уровнем +5 В не повредит линии ввода/вывода управляющей микросхемы.

Компании выпускают микросхемы приемопередатчиков в различных корпусах, что дает широкий выбор в плане габаритов.

Анализируя данные графы «Примечания», можно сказать, что существуют исполнения с одним каналом и двумя сразу (основной и резервный). В тех сферах, например авионике, где используется протокол MIL-STD-1553B, в основном требуются два канала как минимум.

Теперь взглянем на таблицу 2. Как известно, существует три различных трансформатора, предназначенных для устройств с протоколом MIL-STD-1553B. Если разработчик собирается использовать длинное соединение с магистралью, то нужно ставить изолирующий трансформатор с одним коэффициентом трансформации. Если же короткое, то необходимо выбрать другой. Производители представляют их в отдельных корпусах, но следует обратить внимание на трансформаторы с двойным коэффициентом трансформации — для возможности реализации ближнего и дальнего подключения.

Итак, определимся с конкретными компонентами для будущего проекта. В качестве системы управления будем использовать ПЛИС. В ПЛИС можно реализовать синхронную логику, любую цифровую схему и тот же самый контроллер. Возьмем, например, ПЛИС семейства Cyclone III от Altera Corporation. Это семейство не позволяет использовать питание банков ввода/вывода больше +3,7 В. Поэтому будем выбирать приемопередатчик с +3,3-В питанием.

Из таблицы 1 по этому параметру нам подходят два компонента: BU-67401L от DDC и HI-1575 от HoltIntegrated. Первый — это простой приемопередатчик с резервным каналом, а второй — такой же, но со встроенным кодером-декодером. То есть HI-1575 при приеме декодирует посылку и выставляет на выходы в параллельном виде. При передаче — процесс обратный. Функционально этот компонент, конечно, выигрывает по сравнению с простым приемопередатчиком, но требует больше выводов ПЛИС для обмена информацией. (Не говоря уже о том, что стоимость HI-1575 будет выше, чем у простого драйвера.)

Автор предпочитает экономить выводы ПЛИС, потому что к ПЛИС, помимо всего прочего, могут быть подключены какие-либо другие периферийные устройства. Тем более что реализация кодирования и декодирования посылок протокола MIL-STD-1553B не занимает большого количества логических ячеек ПЛИС. Итак, в качестве приемопередатчика будем использовать BU-67401L.

Теперь по поводу выбора трансформатора. Нужно выбрать трансформатор с двумя коэффициентами трансформации, чтобы была возможность подключения нашего устройства к магистрали по ближнему и дальнему соединению. Раз мы решили выбрать приемопередатчик от DDC, следует сказать, что DDC имеет дочернее предприятие BTTC, которое производит трансформаторы по стандарту MIL-STD-1553B. Поэтому в нашем случае логичнее будет использовать компонент именно этого производителя. Выберем B-3227.

На рис. 8 приведена обобщенная схема подключения выбранных нами компонентов. Здесь показаны только те сигналы, которые представляют интерес в контексте этой статьи. На рисунке не изображены цепи питания, «земли» и т. д.

 

Рис. 8. Подключение компонентов

 

Создание структурной схемы проекта на ПЛИС

Практически любой HDL-проект начинается с определения структурной схемы модулей. Очевидно, что наш проект должен содержать модули приемника и передатчика, а также память хранения принятой или передаваемой информации. Автор решил не усложнять проект всеми возможностями протокола (такими как включение/отключение приемопередатчика, статус занятости и пр.), а реализовать прием одного потока данных под конкретным субадресом и передачу другого. На рис. 9 приведена структурная схема нашего будущего HDL-проекта.

 

Рис. 9. Структурная схема

 

Помимо приемника и передатчика на структурной схеме представлен модуль RT_control.v, алгоритм которого основан на работе оконечного устройства. Вспомним, что оконечные устройства могут иметь до 30 субадресов, по которым можно передавать или принимать информацию. Подмодули device3.v и device5.vорганизуют прием и передачу информации соответственно по субадресам 3 и 5. Подмодуль device3.vобеспечивает прием потока данных от контроллера канала и отправку обратно ответного слова. Подмодуль device5.v обеспечивает отправку на контроллер канала ответного слова и следующие за ним информационные слова. Все информационные слова планируется хранить в двухпортовой памяти с разделенными шинами адреса и данных для записи и чтения.

Модуль приемника содержит помимо входных сигналов самого протокола (DI1, DI0) еще и выходную шину принятых данных (data_get[15:0]), а также сигналы сервиса, такие как готовность принятых данных (done) и др. Почти аналогичным образом организован интерфейс модуля передатчика. Интерфейс модуля RT_control.v помимо шин принимаемых и передаваемых данных (rx_data[15:0], tx_data[15:0]) и соответствующих им сигналов управления (rx_done, tx_ready, tx_busy и т. д.) имеет также интерфейсы двухпортовой памяти, соответствующие каждому подмодулю — device3.v и device5.v.

Напомним, что подмодуль device3.v занимается приемом данных от модуля приемника и готов к выдаче этой принятой информации для внешней логики. Подмодуль device5.v, наоборот, записывает от внешней логики в свою память данные, которые потом может передать на контроллер канала с помощью передатчика. Именно поэтому интерфейс памяти для device5.v отличается от device3.v наличием сигнала разрешения записи в память we_dev5.

Одним описанием интерфейсом модулей проекта нельзя ограничиться, поэтому следует рассмотреть каждый модуль в отдельности. Иерархия модулей, написанных на языке описания аппаратуры Verilog, приведена на рис. 10.

 

Рис. 10. Иерархия проекта

 

Следующие части статьи будут содержать разбор HDL-кода каждого модуля проекта. Во второй части будут рассмотрены модули Top_MIL-1553B: приемник и передатчик.

(смотрите вкладку "Часть 2" в начале этой страницы)

 

Литература

  1. ГОСТ Р 52070-2003. «Интерфейс магистральный последовательный системы электронных модулей».
  2. Дайнеко Д. Реализация CORDIC-алгоритма на ПЛИС // Компоненты и технологии. 2011. № 12.
  3. IEEE Standart Verilog Hardware Description Language. 2001.
  4. Mentor Graphics. ModelSim Tutorial. May,

 


Скачать статью:

"Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 1.pdf" (2013)

​​ "Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 2.pdf" (2014)

"Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 3.pdf" (2014)

​​ "Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 4.pdf" (2014)

 

Ресурс: журнал КОМПОНЕНТЫ И ТЕХНОЛОГИИ

Разработка контроллера протокола MIL-STD-1553B на ПЛИС. Часть 2

Автор: Дайнеко Дмитрий

Аннотация: В предыдущей, первой части этой статьи было приведено подробное описание авиационного протокола MIL-STD-1553B. Рассмотрена различная элементная база, необходимая для реализации контроллера этого протокола, выбраны и обоснованы конкретные компоненты. Также проанализирована структурная схема системы управления на базе ПЛИС, о HDL-коде которой мы и расскажем во второй части статьи. Весь материал представлен максимально подробно, а значит, будет полезен начинающему разработчику. Итак, наш HDL-проект состоит из головного модуля (top-level) Top_MIL_1553B, который включает в себя три модуля следующего уровня иерархии — Transmitter, Receiever и RT_control. В этой части статьи представлен HDL-код модулей передатчика и приемника.

 

Написание HDL-кода проекта

Мы попытаемся максимально подробно объяснить работу каждого модуля проекта. Сначала расскажем о тех модулях, которые непосредственно занимаются обработкой протокола MIL-STD-1553B, а потом уже о модулях, реализующих логику управления.

 

Модуль Top_MIL_1553B

Естественно, описание HDL-кода проекта целесообразнее всего начинать с модуля самого верхнего уровня (top-level). Наш модуль верхнего уровня подключает модули передатчика и приемника (Transmitter.v и Receiver.v) к модулю отработки алгоритма оконечного устройства (RT_control.v). Помимо этого, он обеспечивает функционирование обоих каналов протокола — основного и резервного.

Рассмотрим интерфейс ввода/вывода этого модуля:

module Top_MIL_1553B (
 
input clk,
input reset,
 
//MKIO interface - channel A
input DI1A, DI0A,
output DO1A, DO0A,
output RX_STROB_A,
output TX_INHIBIT_A,
 
//MKIO interface - channel B
input DI1B, DI0B,
output DO1B, DO0B,
output RX_STROB_B,
output TX_INHIBIT_B,
 
//device3 RAM interface
input [4:0] addr_rd_dev3,
input clk_rd_dev3,
output [15:0] out_data_dev3,
output busy_dev3,
 
//device5 RAM interface
input [15:0] in_data_dev5,
input [4:0] addr_wr_dev5,
input clk_wr_dev5,
input we_dev5,
output busy_dev5
);

Чтобы было легче ориентироваться в HDL-коде проекта, разработчик использует комментарии. Под текстом “//MKIO interface – channel A” представлены сигналы для драйвера протокола MIL-STD-1553B, соответствующие основному каналу. Сигналы DI1A, DI0A — это прямой и инверсный сигналы от приемника драйвера (рис. 8 [5]), а сигналы DO1A, DO0A — это аналогичные сигналы на передатчик драйвера. Сигналы RX_STROB_A, TX_INHIBIT_A — это сигналы управления каналом, а именно разрешение работы приемника и передатчика драйвера соответственно. Внимательно изучив официальную документацию на микросхему BU-67401L, можно выяснить, что приемник драйвера управляется прямой логикой, а значит, приемник будет активен при наличии «лог. 1» на сигнале RX_STROB_A. В то же время передатчик драйвера управляется инверсной логикой, то есть передатчик будет активен, когда на сигнале TX_INHIBIT_A будет установлен «лог. 0».

Под текстом “//MKIO interface – channel B” представлены сигналы для драйвера протокола MIL-STD-1553B, соответствующие резервному каналу. Назначение этих сигналов полностью идентично сигналам основного канала.

Под текстом комментариев “//device3 RAM interface” и “//device5 RAM interface” представлены сигналы обращения к памяти хранения данных, соответствующие субадресам (sub-address) 3 и 5. Ранее было решено, что подмодуль device3.v будет обеспечивать прием данных с магистрали протокола MIL-STD-1553B и хранить принятые данные во внутренней ОЗУ, а значит, что для некой сторонней периферии необходим доступ к этой ОЗУ для чтения принятых данных. Подмодуль device5.v должен обеспечивать передачу информации из внутренней ОЗУ в магистраль протокола, поэтому сторонняя периферия должна иметь интерфейс заполнения этой внутренней ОЗУ. Описанием всех этих сигналов целесообразнее заняться именно при рассмотрении подмодулей device3.v и device5.v.

Сначала проанализируем «тело» модуля Top_MIL_1553B.v.

В следующем фрагменте кода мы получаем тактовый сигнал частотой 16 МГц, необходимый для работы с протоколом:

//clocks
wire clk32 = clk;
reg clk16 = 1'b0;
always @ (posedge clk32) clk16 = !clk16;

Входную частоту нашего устройства — 32 МГц — мы выбрали исходя из следующих соображений: для стабильной работы проекта системный тактовый сигнал должен превышать частоту работы Transmitter.v и Receiver.v, а также быть кратным ей.

Далее с помощью элемента «логическое ИЛИ» мы объединяем выходные линии обоих каналов — основного и резервного. Таким образом, в любой момент наше устройство сможет адекватно принять входной поток информации от магистрали. Выходные же линии связи просто включены параллельно, поэтому отправляемая информация будет присутствовать на обоих каналах:

wire DI1, DI0, DO1, DO0;
 
assign DI1 = DI1A | DI1B;
assign DI0 = DI0A | DI0B;
 
assign DO1A = DO1;
assign DO0A = DO0;
assign DO1B = DO1;
assign DO0B = DO0;

Читатель может заявить, что резервирование канала организовано слишком просто. Но автор спешит напомнить, что его цель — разобраться в особенностях приема и отправки информации по данному протоколу на примере простого проекта. Как было сказано в разделе описания протокола MIL-STD-1553B, этот стандарт позволяет использовать команды управления, которые, помимо всего прочего, «умеют» блокировать или разрешать резервную линию. Поэтому логику резервирования канала можно реализовать намного сложнее, однако в данном проекте автор решил этого не делать.

Следующим текстом кода мы разрешаем/запрещаем работу приемника и передатчика в моменты передачи информации от нашего оконечного устройства на контроллер канала. Приемник драйвера должен быть разрешен всегда, кроме момента, когда нужно отправить на контроллер канала ответное или информационное слово. Передатчик драйвера, соответственно, наоборот. Для этого мы используем сигнал от модуля передатчика tx_busy(он будет рассмотрен ниже), удлиненный на несколько тактов clk16, так как строб tx_busy в модуле Transmitter.vпоявляется раньше, чем происходит реальная передача данных в магистраль.

reg [4:0] ena_reg = 5'd0;
 
always @ (posedge clk16 or posedge reset)
if (reset) ena_reg = 5'd0;
else ena_reg = {ena_reg[3:0],tx_busy};
 
assign RX_STROB_A = ~{|ena_reg};
assign TX_INHIBIT_A = ~{|ena_reg};
assign RX_STROB_B = ~{|ena_reg};
assign TX_INHIBIT_B = ~{|ena_reg};

Подключаем в проект модули передатчика и приемника:

Transmitter Transmitter (
.clk (clk16),
.reset (reset),
 
.DO1 (DO1), .DO0 (DO0),
 
.imp_send (tx_ready),
.cd_send (tx_cd),
.data_send (tx_data),
.busy_send (tx_busy)
);
 
Receiver Receiver (
.clk (clk16),
.reset (reset),
 
.DI1 (DI1), .DI0 (DI0),
 
.data_get (rx_data),
.cd_get (rx_cd),
.done (rx_done),
.parity_error (parity_error)
);

Назначение всех сигналов ввода/вывода модулей подробно будет описано далее, при рассмотрении самих модулей. Следует только уточнить, что здесь к модулям подключаются линии данных магистрали протокола. Также тут указаны параллельные шины данных и сигналы сервиса, которые связывают передатчик и приемник с модулем RT_control.v, который, в свою очередь, необходимо подключить к нашему проекту:

RT_control RT_control (
.clk (clk32),
.reset (reset),
 
.rx_done (rx_done),
.rx_data (rx_data),
.rx_cd (rx_cd),
.p_error (parity_error),
 
.tx_ready (tx_ready),
.tx_data (tx_data),
.tx_cd (tx_cd),
.tx_busy (tx_busy),
 
.addr_rd_dev3 (addr_rd_dev3),
.clk_rd_dev3 (clk_rd_dev3),
.out_data_dev3 (out_data_dev3),
.busy_dev3 (busy_dev3),
 
.in_data_dev5 (in_data_dev5),
.addr_wr_dev5 (addr_wr_dev5),
.clk_wr_dev5 (clk_wr_dev5),
.we_dev5 (we_dev5),
.busy_dev5 (busy_dev5)
);

Подключение этого модуля показано на рис. 9 из [5].

 

Модуль Transmitter.v

Назначение этого модуля — по некоторому внешнему сигналу принять параллельные данные и последовательно передать их в виде манчестерского кода в соответствии с протоколом MIL-STD-1553B.

Рассмотрим интерфейс ввода/вывода модуля:

module Transmitter (
input clk,
input reset,
 
input imp_send,
input cd_send,
input [15:0] data_send,
output reg busy_send,
 
output reg DO1, DO0
);

Назначение тактового сигнала clk и внешнего сигнала сброса reset объяснять не требуется. Нужно только уточнить, что сигнал clk должен иметь частоту 16 МГц, чтобы обеспечить протокольную частоту обмена данными в 1 МГц. По импульсу imp_send параллельные данные будут «защелкнуты», и начнется передача манчестерского кода по дифференциальным линиям DO1 и DO0. Напомним, что существует три разных слова — командное, информационное и ответное. Если нужно передать командное или ответное слово, используется один синхросигнал, если информационное — другой. Так вот именно сигнал cd_send и сообщает модулю, какой синхросигнал использовать. Параллельная 16-разрядная шина data_send — это передаваемые данные. Если необходимо передать командное слово, то на этой шине должны присутствовать адрес, субадрес, количество слов и бит приема-передачи. Если же необходимо передать информационное слово, то, соответственно, 16 бит данных. Наличие «лог. 1» на сигнале busy_send говорит о том, что идет передача. Временные диаграммы этих сигналов приведены на рис. 11.

 

Рис. 11. Сигналы ввода/вывода модуля Transmitter.v

 

Перейдем к описанию сигналов, используемых в этом модуле:

reg [15:0] data_buf;
reg cd_buf;
reg [2:0] length_bit;
reg [5:0] count_bit;
 
wire [31:0] data_manchester;
wire [39:0] word_manchester;
wire parity;

Сигнал cd_buf и 16-разрядный data_buf — это «защелкнутый» бит нужного синхросигнала и шина данных соответственно. 32-разрядный data_manchester — это, проще говоря, удвоенный 16-разрядный сигнал data_send. Из раздела описания протокола читатель узнал, что в манчестерском коде каждый бит данных представляет собой переход с «лог. 0» в «лог. 1» или наоборот — с «лог. 0» в «лог. 1». Поэтому data_manchester и имеет удвоенную разрядность. 40-разрядный word_manchester — это полностью манчестерское слово, содержащее помимо data_manchester еще синхросигнал и паритет (удвоенные 20 бит передаваемого слова). Что касается 3-разрядного length_bit, то в момент переполнения этого счетчика на выходе появляется следующий разряд сигнала word_manchester[39:0]. Другими словами, регистр length_bit — счетчик длины (в тактах clk) элемента манчестерского кода. А вот счетчик count_bit — это уже номер элемента манчестерского кода. Когда начнем разбирать код модуля, понять все будет намного проще.

Рассмотрим следующую часть модуля:

1. always @ (posedge clk or posedge reset)
2. begin
3.    if (reset) begin
4.       busy_send = 1'b0;
5.       data_buf = 16'd0;
6.       cd_buf = 1'b0;
7.       length_bit = 3'd0;
8.       count_bit = 6'd0;
9.    end
10.    else begin
11.
12.       if (imp_send) begin
13.          data_buf = data_send;
14.          cd_buf = cd_send; end
15.
16.       if (imp_send) length_bit = 3'd0;
17.       else if (busy_send) length_bit = length_bit + 1'b1;
18.
19.    if (imp_send) count_bit = 6'd39;
20.       else if ((count_bit != 6'd0) & (length_bit == 3'd7))
21.          count_bit = count_bit - 1'b1;
22.
23.       if (imp_send) busy_send = 1'b1;
24.       else if ((count_bit == 6'd0) & (length_bit == 3'd7))
25.          busy_send = 1'b0;
26.
27.    end
28. end

В строках 3–10 по сигналу сброса reset происходит начальная установка всех сигналов этого процесса в начальное состояние. В дальнейшем подобную часть кода (начальный сброс) автор упоминать не будет, чтобы не повторяться.

В строках 12–14 описывается «защелкивание» входных данных для передачи при появлении импульса imp_send.

В строках 16–17 происходит подсчет длительности элемента манчестерского кода. Инкремент length_bitразрешается только во время передачи и сбрасывается в ноль во время «защелкивания» входных данных для передачи.

В строках 19–21 описан декремент номера элемента последовательности манчестерского кода count_bit[5:0]. Декремент происходит до нуля и только во время переполнения счетчика длины элемента length_bit[3:0].

Процесс передачи сопровождается сигналом busy_send (строки 23–25): во время «защелкивания» входных данных этот сигнал поднимается в «лог. 1», а сбрасывает в «лог. 0» при окончании передачи последнего элемента манчестерского кода. Временные диаграммы этих сигналов представлены на рис. 12.

 

Рис. 12. Временные диаграммы модуля Transmitter.v

 

Теперь нужно преобразовать «защелкнутые» входные данные в выходную посылку. Как мы помним, посылка состоит из синхросигнала, поля данных и бита четности. Сначала преобразуем поле данных в манчестерский вид:

genvar i;
generate for (i = 0; i 16; i = i + 1)
begin : gen_manchester
assign data_manchester[2*i] = ~data_buf[i];
assign data_manchester[2*i + 1] = data_buf[i];
end
endgenerate

Здесь использована конструкция generate for, которая размножает нужное количество раз то, что описано в теле конструкции. Напомним, что шина data_manchester[31:0] имеет удвоенную разрядность по отношению к «защелкнутым» входным данным data_buf[15:0], потому что нам нужно иметь переходы либо с «лог. 0» в «лог. 1», либо с «лог. 1» в «лог. 0».

Далее сформируем полностью манчестерскую посылку:

assign word_manchester[39:34] = (cd_buf) ? 6'b000111 : 6'b111000;
assign word_manchester[33:2] = data_manchester;
assign word_manchester[1:0] = (parity) ? 2'b10 : 2'b01;

В первой строке кода идет выбор синхросигнала. Во второй строке присваивается только что преобразованное поле данных. В третьей же строке присваивается пара элементов манчестерского кода (или, как было упомянуто, — переход, который состоит из пары элементов), в зависимости от бита паритета. Напомним, бит паритета выбирается таким, чтобы общее количество единиц 20-разрядного слова (рис. 5 [5]) было нечетным.

Следующее выражение вычисляет нужный нам бит паритета:

assign parity = ~(^data_buf);

В завершение приведем процесс, в котором по тактовому сигналу на дифференциальные выходы модуля выставляется тот разряд посылки, готовой на передачу, номер которой указан в регистре count_bit[5:0]:

always @(posedge clk)
begin
if (busy_send) begin
DO1 = word_manchester[count_bit];
DO0 = ~word_manchester[count_bit]; end
else begin
DO1 = 1'b0;
DO0 = 1'b0; end
end

Когда передача отсутствует, в посылке на дифференциальных линиях должны находиться логические нули. Это необходимо для того, чтобы не нагружать линию (рис. 13).

 

Рис. 13. Временные диаграммы модуля Transmitter.v

 

Модуль Receiver.v

Назначение этого модуля — принять информацию по протоколу MIL-STD-1553B, проверить корректность принятой посылки, определить, какое слово принято (командное или информационное), и выставить слово в параллельном виде на выход.

Рассмотрим интерфейс ввода/вывода этого модуля:

module Receiver (
input clk,
input reset,
 
input DI1, DI0,
 
output reg [15:0] data_get,
output reg cd_get,
output reg done,
output reg parity_error
);

Здесь тактовый сигнал clk, так же как и в передатчике Transmitter.v, должен иметь частоту 16 МГц, чтобы адекватно принять входящие данные с протокольной частотой 1 МГц. Входной манчестерский код поступает на дифференциальные входы DI1, DI0. После окончания приема данных будет создан импульс done, по которому принятые данные появятся на линиях data_get[15:0]. По сигналу cd_get можно будет определить, какое слово принято — информационное или командное. Сигнал parity_error покажет, что правило паритета не было выполнено (рис. 14).

 

Рис. 14. Временные диаграммы модуля Receiver.v

 

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

reg [2:0] pos_shift_reg;
reg [2:0] neg_shift_reg;
 
always @ (posedge clk or posedge reset)
begin
if (reset) begin
pos_shift_reg = 3'd0;
neg_shift_reg = 3'd0; end
else begin
pos_shift_reg = {pos_shift_reg[1:0], DI1};
neg_shift_reg = {neg_shift_reg[1:0], DI0}; end
end

Для этого используются 3-разрядные сдвиговые регистры.

Только во время обмена информацией по магистрали линии DI1 и DI0 будут находиться в противоположных друг относительно друга состояниях. Во время простоя магистрали линии будут иметь одинаковое состояние — нулевое. Следующий процесс позволяет детектировать начало приема информации:

reg det_sig;
 
always @ (posedge clk or posedge reset)
begin
if (reset)
det_sig = 1'b0;
else case ({pos_shift_reg[2], neg_shift_reg[2]})
2'b00: det_sig = ~det_sig;
2'b01: det_sig = 1'b0;
2'b10: det_sig = 1'b1;
2'b11: det_sig = ~det_sig;
endcase
end

В момент простоя магистрали сигнал det_sig будет постоянно инвертироваться, что не позволит в дальнейшем начать прием слова.

Далее рассмотрим фрагмент кода, который будет фиксировать момент начала приема элемента манчестерского кода:

reg [2:0] sig_shift_reg;
wire in_data;
wire reset_length_bit;
 
always @ (posedge clk or posedge reset)
begin
if (reset) sig_shift_reg = 3'd0;
else sig_shift_reg[2:0] = {sig_shift_reg[1:0], det_sig};
end
 
assign in_data = sig_shift_reg[2];
assign reset_length_bit = sig_shift_reg[2] ^ sig_shift_reg[1];

Сначала сигнал det_sig задвигается в регистр sig_shift_reg[2:0]. «Логическое исключающее ИЛИ» из двух старших разрядов регистра позволит обнаружить момент перехода входного манчестера с «лог 0» в «лог. 1» либо наоборот. Вспомним, что код Манчестер-II, используемый в протоколе MIL-STD-1553B, — самосинхронизируется именно потому, что каждый элемент информации передается переходом с одного логического состояния в другое. На этот переход и нужно опираться. Сигнал reset_length_bit — импульс сброса счетчика длины элемента манчестерского кода, который используется в следующем процессе. Описанные процессы представлены на рис. 15.

 

Рис. 15. Временные диаграммы модуля Receiver.v

 

За счет того, что наш модуль работает на тактовой частоте 16 МГц, восемь тактов сигнала синхронизацииприходится на один элемент манчестерского кода. Зная момент начала приема элемента и имея счетчик длины элемента length_bit[2:0], мы можем поймать середину элемента. Следующий процесс собирает весь манчестерский код в сдвиговый регистр manchester_reg[39:0]:

reg [2:0] length_bit;
wire middle_bit;
reg [39:0] manchester_reg;
 
assign middle_bit = (length_bit == 3'd3);
 
always @ (posedge clk or posedge reset)
begin
 
if (reset) begin
length_bit = 3'd0;
manchester_reg = 40'd0; end
else begin
if (reset_length_bit) length_bit = 3'd0;
else length_bit = length_bit + 1'b1;
 
if (middle_bit)
manchester_reg[39:0] = {manchester_reg[38:0], in_data};
 
end
end

Здесь мы начинаем инкремент счетчика length_bit[2:0] сразу после обнаружения начала элемента. Когда сигнал middle_bit находится в «лог. 1» (а это произойдет в середине элемента), информация сдвигается в младший разряд регистра manchester_reg[39:0].

Следующий фрагмент кода выделяет из регистра manchester_reg сигнал паритета parity_buf, вид синхросигнала cd_buf и 16-разрядное поле данных data_buf[15:0]. Так же вырабатывается импульс правильности принятого манчестерского кода true_data_manchester:

wire true_data_packet;
wire [15:0] data_buf;
wire parity_buf;
wire cd_buf;
 
assign true_data_packet =
((manchester_reg[39:34] == 6'b000111) |
(manchester_reg[39:34] == 6'b111000))
& (manchester_reg[33] ^ manchester_reg[32])
& (manchester_reg[31] ^ manchester_reg[30]);
 
genvar i;
generate for (i = 0; i = 15; i = i + 1)
begin : bit_a
assign data_buf[i] = manchester_reg[2*i+3];
end
endgenerate
 
assign parity_buf = manchester_reg[1];
assign cd_buf = manchester_reg[35];

Напомним, что каждый разряд принятой информации состоит из двух элементов манчестерского кода (рис. 3 [5]). В соответствии с этим из регистра manchester_reg выделяются вид синхросигнала и бит паритета. Так же, но с использованием конструкции generate for, выделяется поле данных data_buf[15:0]. Сигнал true_data_bufустанавливается в «лог. 1» только тогда, когда в сдвиговом регистре manchester_reg появятся один из двух синхросигналов и хотя бы два верных бита информации. Можно, конечно, проверять полностью весь регистр, но, как показывает практика, двух битов достаточно.

Завершающий фрагмент кода модуля Receiver.v по окончании приема выставляет на выход принятые данные, а также вырабатывает импульс окончания приема done:

reg ena_wr;
 
always @ (posedge clk or posedge reset)
begin
if (reset) begin
cd_get = 1'b0;
parity_error = 1'b0;
ena_wr = 1'b0;
data_get = 16'd0;
end
else begin
 
ena_wr = middle_bit;
 
if (true_data_packet & ena_wr) begin
cd_get = cd_buf;
data_get = data_buf[15:0];
parity_error = ~(^({data_buf,parity_buf}));
end
 
done = true_data_packet & ena_wr;
 
end
end

Сигнал ena_wr — это, по сути, импульс середины элемента, задержанный на один такт clk. Он необходим, чтобы по окончании приема все данные успели задвинуться в manchester_reg и «защелкнуться» на выходных регистрах. Сигнал parity_error устанавливается в «лог. 1», если принятые данные имеют четное количество единиц, а значит, не соответствуют правилу паритета. Это показано на рис. 16.

 

Рис. 16. Временные диаграммы модуля Receiver.v

 

Мы рассказали, как реализовать кодирование и декодирование последовательных слов данных в стандарте MIL-STD-1553B. Теперь осталось реализовать логику управления и формирования нужных пакетов данных.

В следующей, третьей части статьи мы рассмотрим модуль RT_control и входящие в его состав подмодули device3 и device5, которые реализуют работу устройства с субадресами 3 и 5 соответственно.

(смотрите вкладку "Часть 3" в начале этой страницы)

 

Литература

  1. ГОСТ Р 52070-2003. «Интерфейс магистральный последовательный системы электронных модулей».
  2. Дайнеко Д. Реализация CORDIC-алгоритма на ПЛИС // Компоненты и технологии. 2011. № 12.
  3. IEEE Standart Verilog Hardware Description Language. 2001.
  4. Mentor Graphics. ModelSim Tutorial. May, 2008.
  5. Дайнеко Д. Разработка контроллера протокола MIL-STD-1553B на ПЛИС. Ч. 1 // Компоненты и технологии. 2013. № 12.

 

Скачать статью:

"Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 1.pdf" (2013)

​​ "Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 2.pdf" (2014)

"Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 3.pdf" (2014)

​​ "Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 4.pdf" (2014)

 

Ресурс: журнал КОМПОНЕНТЫ И ТЕХНОЛОГИИ

Статья редактируется

Разработка контроллера протокола MIL-STD-1553B на ПЛИС. Часть 3

Автор: Дайнеко Дмитрий

Аннотация: В предыдущей, второй части статьи автор начал рассматривать HDL-код проекта на ПЛИС, который описывает контроллер авиационного протокола MIL-STD 1553B. Из всех модулей были рассмотрены передатчик (Transmitter.v) и приемник (Receiver.v). Были приведены временные диаграммы для лучшего понимания кода модулей. Модули передатчика и приемника обеспечивают декодирование и кодирование слов стандарта MIL-STD 1553B соответственно. Пакетной организацией этих слов занимается модуль RT_control.v. Именно ему и посвящена эта часть статьи.

 

Скачать статью:

"Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 1.pdf" (2013)

​​ "Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 2.pdf" (2014)

"Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 3.pdf" (2014)

​​ "Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 4.pdf" (2014)

 

Ресурс: журнал КОМПОНЕНТЫ И ТЕХНОЛОГИИ

Статья редактируется

Разработка контроллера протокола MIL-STD-1553B на ПЛИС. Часть 4

Автор: Дайнеко Дмитрий

 Аннотация: В предыдущей, третьей части статьи автор завершил рассмотрение HDL-кода проекта контроллера протокола MIL-STD-1553B. Был проанализирован модуль RT_control и приведены временные диаграммы. Теперь нам осталось провести моделирование HDL-проекта с использованием тестбенча, чтобы убедиться в работоспособности созданного проекта. Моделирование мы будем проводить в известной fpga-дизайнерам САПР ModelSim Altera Startet Edition.  

 

Скачать статью:

"Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 1.pdf" (2013)

​​ "Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 2.pdf" (2014)

"Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 3.pdf" (2014)

​​ "Разработка контроллера протокола MIL-STD‑1553B на ПЛИС. Часть 4.pdf" (2014)

 

Ресурс: журнал КОМПОНЕНТЫ И ТЕХНОЛОГИИ