Что такое аппаратный интерфейс: Аппаратные интерфейсы

Аппаратные интерфейсы

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

Аппаратный интерфейс
представляет собой систему шин, разъемов, согласующих устройств,
алгоритмов и протоколов, обеспечивающих связь всех частей …

Интерфейс (взаимодействие) – это взаимосвязь между компонентами и участниками микропроцессорной системы.

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

• аппаратный интерфейс;

• программный интерфейс;

• интерфейс пользователя.

Программный интерфейс обеспечивается операционной системой (если таковая имеется). Наиболее распространенными интерфейсами пользователя являются графический интерфейс (например, рабочий стол PC с иконками или кнопки команд в редакторе Microsoft Office Word) и интерфейс «джойстика», когда мы выбираем необходимую нам команду, перемещаясь по меню (например, мобильные телефоны, программируемые контроллеры), что также является видом графического интерфейса.

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

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

Управление шинами осуществляют мосты. В сложных МС, например, таких как персональный компьютер, центральное место занимает «чипсет» (ChipSet) – набор мостов и контроллеров. Чипсет включает две главные микросхемы, которые традиционно называют южный мост и северный мост (рисунок 1). Северный мост обслуживает системную шину, шину памяти, AGP (ускоренный графический порт) и является главным контроллером компьютера. Южный мост обслуживает работу с внешними устройствами (шина PCI — шина ввода/вывода для подключения периферийных устройств).

Рисунок 1 — Организации обмена данными в персональных компьютерах (РС)

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

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

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

Простейшим последовательным интерфейсом, получившим распространение как в PC, так и в промышленных системах, является стандарт RS-232, реализуемый СОМ — портами. В промышленной автоматике широко применяется RS-485.

Шина USB (Universal Serial Bus — универсальная последовательная шина) обеспечивает подключение к компьютеру большое количество разнообразных периферийных устройств, в том числе мобильные телефоны и бытовую электронику.

Первая спецификация интерфейса имела название USB 1.0, в настоящее время используется спецификация USB 2.0, современные устройства интерфейсом спецификации USB 3.0.

Стандарт USB 2.0 содержит в себе четыре линии: приём и передача данных, питание +5 В и корпус. В дополнение к ним USB 3.0 добавляет еще четыре линии связи (2 на прием и две на передачу) и корпус.

Шина USB имеет высокую пропускную способность (USB 2.0 обеспечивает максимальную скорость передачи информации до 480 Мбит/с, USB 3.0 — до 5,0 Гбит/с) и обеспечивает не только передачу данных, но и питание маломощных внешних устройств (максимальная сила тока, потребляемого устройством по линиям питания шины USB, не должна превышать 500 мА для USB 2.0 и 900 мА для USB 3.0), что позволяет не использовать внешних источников питания.

Беспроводные (wireless) интерфейсы позволяют уйти от кабелей связи, что особенно актуально для малогабаритных устройств, по размеру и весу соизмеримых с кабелями. В беспроводных интерфейсах используются электромагнитные волны инфракрасного (IrDA) и радиочастотного (Bluetooth, USB wireless) диапазонов.

Инфракрасный интерфейс IrDA позволяет осуществлять беспроводную связь между двумя устройствами на расстоянии до 1 метра. Инфракрасная связь — IR (Infra Red) Connection — безопасна для здоровья, не создает помех в радиочастотном диапазоне и обеспечивает конфиденциальность передачи. ИК-лучи не проходят через стены, поэтому зона приема ограничивается небольшим, легко контролируемым пространством.

Bluetooth (синий зуб) — радиоинтерфейс с низким энергопотреблением (мощность передатчика всего порядка 1 мВт) для организации персональных сетей, обеспечивающий передачу данных в режиме реального времени на небольшие расстояния. Каждое устройство Bluetooth имеет радиопередатчик и приемник, работающие в диа¬пазоне частот 2,4 ГГц. Дальность действия радиоинтерфейса составляется около 100 м — для покрытия стандартного дома.

Беспроводной USB (USB wireless) – радиоинтерфейс малой дальности с высокой пропускной способностью: 480 Мбит/с на расстоянии до 3 метров и 110 Мбит/с на расстоянии до 10 метров. Работает в диапазоне частот 3,1 — 10,6 ГГц.

Интерфейс RS-232 (RS — recommended standard — рекомендованный стандарт) соединяет два устройства — компьютер и устройство передачи данных. Скорость передачи — 115 Кбит/с (максимум), расстояние передачи — 15 м (максимум), схема соединения — от точки к точке.

Сигналы этого интерфейса передаются перепадами напряжения величиной (3…15) В, поэтому длина линии связи RS-232, как правило, ограничена расстоянием в несколько метров из-за низкой помехоустойчивости. Чаще всего используется в промышленном оборудовании, в персональном компьютере использовался для подключения манипулятора типа «мышь», модема. Интерфейс RS-232 принципиально не позволяет создавать сети, так как соединяет только 2 устройства.

Рисунок 2 — Разъем RS-232 типа DB9

Интерфейс RS-485 — широко распространенный высокоскоростной и помехоустойчивый промышленный последовательный интерфейс двунаправленной передачи данных. Практически все современные компьютеры в промышленном исполнении, большинство датчиков и исполнительных устройств содержат в своем составе ту или иную реализацию интерфейса RS-485.

Для передачи и приема данных достаточно одной скрученной пары проводников (витая пара). Передача данных осуществляется с помощью дифференциальных сигналов (по одному проводу идет оригинальный сигнал, а по другому — его инверсная копия.). Разница напряжений одной полярности между проводниками означает логическую единицу, разница другой полярности — ноль.

При наличии внешних помех, наводки в соседних проводах одинаковы, и так как сигналом является разность потенциалов в проводниках, уровень сигнала остаётся неизменным. Это обеспечивает высокую помехоустойчивость и общую длину линии связи до 1 км (и более с использованием специальных устройств – повторителей).

Интерфейс RS-485 обеспечивает обмен данными между несколькими устройствами по одной двухпроводной линии связи в полудуплексном режиме (Прием и передача идут по одной паре проводов с разделением по времени). Широко используется в промышленности при создании АСУ ТП.

Ethernet (ether — эфир) — технология передачи данных, используемая в большинстве локальных компьютерных сетей. Этот интерфейс базируется на стандарте IEE 802.3. Если интерфейс RS-485 можно рассматривать по принципу «один ко многим», то Ethernet работает по принципу «многие ко многим».

В зависимости от скорости передачи данных и передающей среды существует несколько вариантов:

• Ethernet — 10 Мбит/с

• Быстрый (Fast) Ethernet — 100 Мбит/с

• Гигабитный (Gigabit) Ethernet — 1 Гбит/с

• 10-гигабитный Ethernet

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

Витая пара (twisted pair) — вид кабеля связи, представляет собой одну или несколько пар изолированных проводников, скрученных между собой и покрытых пластиковой оболочкой.

Например, кабель FTP (foiled twisted pair — витая пара с общим экраном из фольги и медным проводником для отвода наведенных токов), 4 пары (solid), категория 5e (рисунок 3). Кабель предназначен для стационарной прокладки внутри зданий, сооружений и эксплуатации в структурированных кабельных системах. Разработан для приложений, работающих в частотном диапазоне с верхней границей 100 МГц.

Рисунок 3 — Витая пара: 1 — Внешняя оболочка, 2 — Экран-фольга, 3 — Дренажный провод, 4 — Защитная пленка, 5 — Витая пара

На физическом уровне протокол Ethernet реализован в виде сетевых карт, встраиваемых в микропроцессорные системы, и концентраторов, соединяющих системы друг с другом.

На основе Ethernet строят промышленные сети (Profinet, EtherNet/IP, EtherCAT, Ethernet Powerlink), которые успешно конкурируют с ранее разработанными сетями Profibus, DeviceNet, CANopen и др.

10. 12.2016

Без рубрики

Аппаратный интерфейс Thunderbolt (ликбез).

Аппаратный интерфейс Thunderbolt (ликбез).

Thunderbolt (с англ. — «раскат грома») — аппаратный интерфейс, ранее известный как Light Peak, разработанный компанией Intel в сотрудничестве с Apple. Служит для подключения различных периферийных устройств к компьютеру с максимальными скоростями передачи данных около 10 Гбит/с по медному проводу и 20 Гбит/с при использовании оптического кабеля.

Thunderbolt комбинирует интерфейсы PCI Express (PCIe) и DisplayPort (DP) в одном кабеле. Допускается подключение к одному порту до шести периферийных устройств путём их объединения в цепочку.

Thunderbolt 2

В 2013 году был представлен обновлённый интерфейс Thunderbolt 2. На физическом уровне он идентичен Thunderbolt 1, используются такие же кабели и разъёмы, сохранена обратная совместимость. На логическом уровне была добавлена возможность агрегации каналов, и теперь два отдельных канала 10 Гбит/с могут объединяться в один логический канал со скоростью 20 Гбит/с. Thunderbolt 2 использовался в Apple MacBook Pro Retina конца 2013 года (представлен 22 октября 2013 года).

Thunderbolt 3

Контроллер Intel Thunderbolt 3 (кодовое имя Alpine Ridge) увеличивает максимальную пропускную способность в 2 раза, до 40 Гбит/с (5 ГБ/с), имеет меньшее энергопотребление и позволяет подключать два монитора с разрешением 4K, либо один с разрешением 5K (вместо одного 4K для более ранних версий стандарта). Новый контроллер будет поддерживать PCIe 3.0 и протоколы HDMI 2.0, DisplayPort 1.2 (до 30 Гц 4K). Thunderbolt 3 представляет собой порт, совместимый с USB 3.1, выполнен с разъёмом USB Type-C. Совместимость с более ранними вариантами интерфейса будет обеспечиваться с помощью переходников.

Intel предложит два варианта контроллера Thunderbolt 3 — один будет использовать PCI Express x4 и предоставит два порта Thunderbolt 3, второй использует PCI Express x2 и имеет лишь один порт Thunderbolt 3. Первый будет использоваться в Mac Pro (2-го поколения) и Retina MacBook Pro, а второй — в более дешёвых Mac mini и MacBook Air.

Поддержка Thunderbolt 3 ожидается в чипсетах для платформы Skylake. Thunderbolt 3 станет частью стандарта USB4, так как компания Intel передала все права на него USB Implementers Forum.

Thunderbolt 4

В июле 2020 года Intel опубликовала спецификацию интерфейса Thunderbolt 4. Скорость Thunderbolt 4 составляет 40 Гбит/с.

В начале 2021 г. представитель Intel сообщил, что новый интерфейс Thunderbolt 5 уже разрабатывается и окажется в два раза быстрее текущего Thunderbolt 4, а также USB4 (ожидается скорость в 80 Гбит/с).

TPM 2,0 — аппаратный интерфейс

• 
  Статья
• 
  02/08/2022
• Чтение занимает 2 мин

Были ли сведения на этой странице полезными?

Были ли сведения на этой странице полезными?

Да



Нет

Хотите оставить дополнительный отзыв?

Отзывы будут отправляться в корпорацию Майкрософт. Нажав кнопку «Отправить», вы разрешаете использовать свой отзыв для улучшения продуктов и служб Майкрософт. Политика конфиденциальности.

Отправить

Спасибо!

В этой статье

этот ручной тест проверяет каналы связи между Windows и доверенный платформенный модуль (TPM) (TPM).

Сведения о тесте

Дополнительная документация

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

Выполнение теста

Перед выполнением теста ознакомьтесь с предварительными требованиями в статье основные сведения о тестировании основных компонентов TPM.

У этого теста нет дополнительных параметров теста.

Выявлен

общие сведения об устранении неполадок тестирования хлк см. в разделе устранение неполадок Windows хлк тестов.

Сведения об устранении неполадок см. в разделе Устранение неполадок при проверке основ системы.

Этот тест возвращает значение «пройден» или «ошибка». чтобы ознакомиться с подробными сведениями о тесте, изучите журнал тестирования из пакета Windows Hardware Lab Kit (Windows хлк) Studio. Чтобы предоставить дополнительные сведения для устранения ошибок в этом тесте, можно включить трассировку TPM. См. действия, описанные в разделе Устранение неполадок в тесте интеграции модуля TCG (вручную). Расследования также требуются файлы журналов с именами, например «TPM * .txt», и console.txt из папки «документы»

Аппаратный интерфейс представляет собой совокупность шин комплекс проводов

Аппаратный интерфейс представляет собой совокупность шин (комплекс проводов), электронных схем (контроллеров) и протоколов (правил передачи информации), обеспечивающих передачу информации внутри компьютера. Ханнанов Т. А. лекция Аппаратные интерфейсы

На программном уровне интерфейс поддерживается драйвером, который входит либо в состав операционной системы, либо в комплект поставки устройства, либо «зашит» внутри компонента. Ханнанов Т. А. лекция Аппаратные интерфейсы

Радиальный интерфейс Ханнанов Т. А. лекция Аппаратные интерфейсы

Магистральный интерфейс Ханнанов Т. А. лекция Аппаратные интерфейсы

Цепочный интерфейс Ханнанов Т. А. лекция Аппаратные интерфейсы

Устройства ISA Ханнанов Т. А. лекция Аппаратные интерфейсы видеокарты, контроллеры ввода — вывода, контроллеры жестких и гибких дисков, модемы, звуковые карты

Разъемы ISA Ханнанов Т. А. лекция Аппаратные интерфейсы

Устройства PCI Ханнанов Т. А. лекция Аппаратные интерфейсы Карты расширения: сетевые, звуковые, ведеозахвата, модемы, контроллеры др. интерфейсов

Разъемы PCI Ханнанов Т. А. лекция Аппаратные интерфейсы

Видеокарта с интерфейсом AGP Ханнанов Т. А. лекция Аппаратные интерфейсы

Разновидности интерфейса AGP Ханнанов Т. А. лекция Аппаратные интерфейсы

Разъемы AGP Ханнанов Т. А. лекция Аппаратные интерфейсы

Устройства PCI-Express 1 x Карты расширения: видеокарты (в основном), звуковые, ведеозахвата, контроллеры др. интерфейсов 16 x Ханнанов Т. А. лекция Аппаратные интерфейсы

Разъемы PCI-Express 1 x 16 x Ханнанов Т. А. лекция Аппаратные интерфейсы

Сравнение AGP и PCI-Express Ханнанов Т. А. лекция Аппаратные интерфейсы

Преимущество PCI-Express: Возможность установки нескольких видеокарт Ханнанов Т. А. лекция Аппаратные интерфейсы

Пример внутренней организации системных плат с интерфейсом PCI-Express Ханнанов Т. А. лекция Аппаратные интерфейсы

Устройства с интерфейсом IDE НЖМД, оптические накопители Ханнанов Т. А. лекция Аппаратные интерфейсы

Разъемы IDE Ханнанов Т. А. лекция Аппаратные интерфейсы

Подсказки по установке перемычек “джамперы” (перемычки) Ханнанов Т. А. лекция Аппаратные интерфейсы

Кабели IDE интерфейса Ханнанов Т. А. лекция Аппаратные интерфейсы

Этапы развития интерфейса IDE (ATA) Ханнанов Т. А. лекция Аппаратные интерфейсы

Переход от параллельного интерфейса IDE (PATA) к последовательному SATA НЖМД, оптические накопители Ханнанов Т. А. лекция Аппаратные интерфейсы

Разъемы и кабель SATA Ханнанов Т. А. лекция Аппаратные интерфейсы

Устройства с SCSI НЖМД, оптические накопители, стримеры , магнитооптические диски , сканеры Ханнанов Т. А. лекция Аппаратные интерфейсы

Ханнанов Т. А. лекция Аппаратные интерфейсы

Разъемы с SCSI Ханнанов Т. А. лекция Аппаратные интерфейсы

Соединительные кабели SCSI Ханнанов Т. А. лекция Аппаратные интерфейсы

Интерфейс LPT (IEEE 1284) Сканеры, принтеры, электронные ключи Ханнанов Т. А. лекция Аппаратные интерфейсы

Устройства с LPT-портом Ханнанов Т. А. лекция Аппаратные интерфейсы

Com-порт (RS-232) Модемы, принтеры, мыши, трекболы, измерительные приборы Ханнанов Т. А. лекция Аппаратные интерфейсы

Разновидности интерфейса RS-232 Ханнанов Т. А. лекция Аппаратные интерфейсы

Соединительный кабель и устройства, использующий интерфейс RS-232 Ханнанов Т. А. лекция Аппаратные интерфейсы

интерфейс PS/2 Мыши, клавиатуры Ханнанов Т. А. лекция Аппаратные интерфейсы

Устройства на базе PS/2 Ханнанов Т. А. лекция Аппаратные интерфейсы

Переходники PS/2 > USB и наоборот Ханнанов Т. А. лекция Аппаратные интерфейсы

USB Модемы, принтеры, мыши, трекболы, flash-карты, сканеры и др. Ханнанов Т. А. лекция Аппаратные интерфейсы

USB устройства Ханнанов Т. А. лекция Аппаратные интерфейсы

Архитектура USB Ханнанов Т. А. лекция Аппаратные интерфейсы

Кабель и разъемы USB Тип А Тип В Ханнанов Т. А. лекция Аппаратные интерфейсы

IEEE 1394 (Fire Wire) Ханнанов Т. А. лекция Аппаратные интерфейсы Видеокамеры, накопители инфорации

Разъемы IEEE 1394 (Fire Wire) Ханнанов Т. А. лекция Аппаратные интерфейсы

Архитектура IEEE 1394 (Fire Wire) Ханнанов Т. А. лекция Аппаратные интерфейсы

MIDI Модемы, принтеры, мыши, трекболы, flash-карты, сканеры и др. Ханнанов Т. А. лекция Аппаратные интерфейсы

Ir. DA Ханнанов Т. А. лекция Аппаратные интерфейсы

Bluetooth Ханнанов Т. А. лекция Аппаратные интерфейсы

технология Ethernet Ханнанов Т. А. лекция Аппаратные интерфейсы

Ханнанов Т. А. лекция Аппаратные интерфейсы

звуковые выходы Ханнанов Т. А. лекция Аппаратные интерфейсы

Домашнее задание: N п/п Наименование интерфейса Внешний/ внутренний 1 2 … n Ханнанов Т. А. лекция Аппаратные интерфейсы Применение Скорость передачи данных

Что такое интерфейс. Графический интерфейс, типы и API

Пользовательский интерфейс — это средства взаимодействия между человеком и компьютером. Говоря простыми словами, интерфейс — внешняя часть программы или устройства, с которыми работает пользователь. Слово интерфейс — калька с английского interface, то есть «граница, связующее звено».

Чаще всего под словом интерфейс подразумевают именно пользовательский интерфейс. Например, говорят: «У этого интернет-магазина неудобный, запутанный интерфейс». Это значит, что с сайтом магазина неудобно взаимодействовать. Скажем, сложно найти нужные товары, непонятно, как оформить заказ, сайт не сохраняет ранее введенные данные и т.п.

Примеры употребления:

Многие пользователи хотели бы вернуть старый интерфейс «ВКонтакте», новый им не нравится.

У программы интуитивно понятный интерфейс — сразу ясно, куда нажимать и к чему это приведет.

Интерфейс Windows очень сложен: неопытные пользователи путаются в куче настроек.

Веб-интерфейс (web-interface) — это страница в интернете, позволяющая пользователю взаимодействовать с каким-то сервисом или устройством прямо через браузер. К примеру, с помощью веб-интерфейса можно воспользоваться онлайн-банком: зайти на страницу банка, ввести логин и пароль, а затем переводить деньги между счетами, оплачивать услуги и т. п.

Аппаратный и программный интерфейс. Что такое интерфейс USB и API

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

Когда говорят об аппаратном интерфейсе, обычно имеют в виду разъемы, через которые устройства можно подключить друг к другу. Например, «подключение через интерфейс USB» — это значит соединение устройств через универсальную последовательную шину, предназначенную для подключения периферийной техники. Через USB, например, можно подключить к компьютеру клавиатуру, мышку, фотоаппарат или смартфон.

Аппаратный интерфейс — кабель USB

Программный интерфейс — это способ взаимодействия программ между собой. Например, API (application programming interface, программный интерфейс приложения) — это набор команд, который позволяет программам автоматически обмениваться данными без участия людей. Одна программа по API отправляет запрос, другая отвечает ей.

К примеру, на новостном сайте показываются курсы валют, которые меняются в реальном времени. Это не значит, что редактор сайта каждый раз вручную меняет числа на странице. Новостной сайт сам отправляет по API запрос на сервер с данными валютной биржи и получает оттуда необходимые цифры.

Типы пользовательских интерфейсов. Графический, текстовый и другие

Текстовый интерфейс — это способ общения человека с компьютером с помощью печати команд. Например, в операционной системе MS-DOS интерфейс был текстовым — пользователь набирал на клавиатуре нужные команды, а машина их выполняла.

Текстовый интерфейс MS-DOS — командная строка

Проблема текстового интерфейса в том, что пользователь должен знать необходимые команды и каждый раз вручную набирать их без ошибок. Частично от этой трудности избавили оболочки для MS-DOS — например, Norton Commander.

Norton Commander — файловый менеджер для MS-DOS. В нем можно не только набирать команды на клавиатуре, но работать с файлами с помощью сочетаний клавиш.

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

Графический интерфейс Windows 3.11

Материальный интерфейс — это способ взаимодействия с компьютером с помощью осязаемых конструкций. Например, компьютерная мышка или джойстик — это материальный интерфейс. Двигая мышку по столу, мы одновременно перемещаем стрелку курсора по экрану.

Материальный интерфейс — компьютерная мышь. Фото: Depositphotos

Голосовой интерфейс — это управление с помощью речевых команд. Человеческий голос сегодня умеют понимать даже мобильные телефоны. Например, Siri от Apple, голосовой помощник Google, «Алиса» от «Яндекса»

Голосовой интерфейс — Siri от Apple. Siri — это сокращение от Speech Interpretation and Recognition Interface (интерфейс распознавания и интерпретации речи). Фото: Depositphotos

Жестовый интерфейс позволяет отдавать команды, делая жесты пальцем, рукой, компьютерной мышью, специальным контроллером и т.п.

Жестовый интерфейс — игровая приставка Nintendo Wii, контроллеры которой реагируют на движения пользователя.

Тактильный интерфейс позволяет пользователю испытывать осязательные ощущения (нажим, вибрацию и т.п.) и взаимодействовать с компьютером с их помощью.

Перчатки виртуальной реальности — пример тактильного интерфейса. Фото: NASA

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

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

Киану Ривз в фильме «Матрица» (1999). Герои пользуются нейроинтерфейсом, чтобы попасть в виртуальную реальность — Матрицу.

Киберспейс — интерфейс в виде виртуальной реальности. Кадр из фантастического фильма «Джонни Мнемоник» (1995)

Аппаратный интерфейс — общие вопросы

Что такое аппаратный интерфейс?
Прибор, отправляющий информацию, и прибор, получающий информацию, должны быть согласованы. Согласование включает в себя уровень электрического сигнала и настройки связи. Промышленные стандарты существуют для определения аппаратного интерфейса. К ним относятся RS-232, RS-422, RS-485. Есть целый ряд параметров, связанных с обменом данными, которые включают скорость, четность, стартовый и конечный биты — все эти вопросы регламентируются стандартом.

Что такое RS-232? Можно его использовать в продуктах KEP?
RS-232 — это отраслевой стандарт для электрического уровня сигнала. Он широко используется при последовательной передаче данных на расстояние не больше 15 метров. Порты RS-232 имеются на всех персональных компьютерах и представляют собой порт mini-D или D-SUB.
Что такое RS-485? Можно его применять с приборами KEP?
RS-485 — это отраслевой стандарт для электрических сигналов в линиях передачи данных. Он широко используется при последовательной передаче информации в задачах, где необходимо передать данные на расстояние не более 1200 метров. Передача информации выполняется по 3-м проводам (включая заземление). Для подключение RS-485 к персональному компьютеру необходимо использовать адаптер RS-485/RS-232.
Что такое протокол?
Протоколом называют согласованный метод обмена информацией. Он используется для определения методов форматирования информации, передача которой выполняется по кабелю связи. Примером протокола может служить MODBUS-RTU, который используют во многих приборах и устройствах. На рынке существует много других протоколов.

Что из оборудования KEP может быть полезно:

Что еще почитать по теме:

Коммуникационные возможности приборов KEP.

Применение интерфейса RS-232 для вывода отчетов на печать.

Программные решения по сбору данных с приборов.

[Серия искусственного интеллекта-Интеллектуальное оборудование-15] Приложение: Портативный аппаратный интерфейс XHWIF

XHWIF — это стандартный аппаратный интерфейс для аппаратного обеспечения Xilinx FPGA, который позволяет легко переносить JBits и BoardScope или подключать их к новой аппаратной платформе.

Как только интерфейс XHWIF определен как подробный и конкретный аппаратный блок, такие инструменты, как BoardScope, будут работать без перекомпиляции или изменений.

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

Наконец, часть пакета XHWIF основана на TCP / IP, поддерживаемом удаленным доступом.

Как только интерфейс XHWIF подключен к новому оборудованию, удаленные серверы и сети также автоматически поддерживаются для доступа к оборудованию.

XHWIF — это интерфейс Java, который взаимодействует с платами на основе FPGA. Он включает в себя метод чтения и записи потока битов ПЛИС и способ описания типа и количества ПЛИС на плате. Он также включает в себя способ увеличения часов на плате и способ чтения и записи встроенной памяти, если память доступна. Ключ в том, что интерфейс описывает плату и может передавать данные или читать данные с платы.

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

Конкретная информация об используемом оборудовании скрыта в классе, реализованном интерфейсом XHWIF.

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

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

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

Как только XHWIF реализован как новая система, приложения могут напрямую обращаться к новому оборудованию. Кроме того, интерфейс XHWIF снабжен интерфейсом удаленного доступа. Это позволяет приложению работать без изменений на некотором удаленном оборудовании. Для удаленного оборудования требуется сетевое соединение TCP / IP, XHWIF может поддерживать все.

Удаленный доступ особенно полезен в таких приложениях, как инструменты отладки BoardScope. Используя режим удаленного доступа XHWIF, оборудование может совместно использоваться несколькими пользователями, хотя они находятся в разных местах, и нет необходимости предоставлять несколько полных систем для каждого пользователя.

Пользователи или исследователи используют XHWIF для прямого доступа к оборудованию FPGA.

В обычном «локальном» режиме приложения XHWIF используют интерфейсы для реализации функциональных функций, требуемых системой.

В режиме удаленной сети сервер XHWIF использует прямой интерфейс для доступа к локальному оборудованию, который подключается к некоторым приложениям XHWIF через сеть TCP / IP и использует удаленный интерфейс XHWIFnet.

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

Рассмотрите возможность подключения системы удаленно, сервер XHWIF должен работать в системе, содержащей аппаратное обеспечение FPGA. Этот сервер является приложением Java, ожидающим сетевого подключения от удаленного приложения XHWIF, и выполняет все функции аппаратного доступа для удаленного приложения.

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

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

Возвращаемая информация о сервере XHWIF содержит: описание, состояние и конфигурацию аппаратной платформы.

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

В настоящее время интерфейс XHWIF поддерживает следующие аппаратные системы:

• PametteVDC — DEC/Compaq PCI Pamette Virtex Daughtercard (XCV300)
• Pamettevdc800 — DEC/Compaq PCI Pamette Virtex Daughtercard (XCV800)
• Rc1000pp — ESL’s RC1000PP Virtex Card (XCV1000)
• Xsv — XESS Virtex Card(XCV800)

Запустите XHWIF как приложение для проверки интерфейса с платой, команда выглядит следующим образом:

java com. xilinx.XHWIF.XHWIF -<board> <bitfile>，

Где board — это имя класса java для предоставления аппаратного интерфейса, bitfile — это файл строки битов, который можно загрузить или прочитать.

Если приложение не может быть найдено, войдите в систему или получите доступ к созданной вами библиотеке, интерпретатор java должен сгенерировать сообщение об ошибке, описывающее проблему.

Наиболее распространенная проблема заключается в том, что библиотека находится не в том месте, которое может найти интерпретатор, например в системном пути PATH.

Аппаратно-программный интерфейс: где мы были и куда идем

Аппаратно-программный интерфейс, или сокращенно «HSI», — это термин, используемый для описания как конфигурации, так и как они взаимодействуют с процессорами.

Аппаратно-программный интерфейс, или сокращенно «HSI», — это термин, используемый для описания как конфигурации, так и функциональности периферийных устройств SoC, а также их взаимодействия с ЦП.

Огромный объем различных факторов здесь — от битов регистра до типов доступа, свойств и функций, которыми они управляют — может быть абсолютно ошеломляющим в современной SoC.37, или 137 438 953 472!

А что, если адресная шина 64-битная? Что делать, если в SoC есть многопроцессорные ядра? Очевидно, что сказать, что типичная архитектура SoC сложна, — это ничего не сказать.

Несомненно, современные отраслевые тенденции приведут только к более продвинутым SoC с растущим числом периферийных устройств для большей функциональности, чем когда-либо прежде. Чтобы понять все это, а тем более управлять им, нам потребуется полностью переосмыслить аппаратно-программный интерфейс.Это верно как в отношении того, как далеко мы продвинулись… так и в отношении того, куда мы движемся.

Аппаратно-программный интерфейс в том виде, в каком он существует сегодня

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

В контексте современного процессора HSI и архитектура набора инструкций (ISA) по сути являются одним и тем же.Это уровень, на котором программное обеспечение «разговаривает» с оборудованием. Процессор может быть ARM, RISC-V — на самом деле это не имеет значения, потому что процесс остается прежним. Вы пишете программу на C или C++ для достижения желаемых целей, компилируете ее и затем размещаете на процессоре. Вот как вы взаимодействуете как с регистрами, так и с внешними шинами, а также с вводом-выводом.

Что касается фактического SoC, вам также придется иметь дело с матрицей межсоединений, которая соединяет ваш ЦП с различными программируемыми ведомыми устройствами.Эти подчиненные устройства могут иметь собственную память или даже быть мостом к более медленной шине, в зависимости от уникальной ситуации, о которой вы говорите. Ведомые программируются чтением и записью встроенных регистров. Когда вы смотрите на вещи с точки зрения этого типа макросов, регистры и прерывания являются IP-адресами (или подчиненными) HSI.

Хотя до сих пор это работало хорошо, также трудно поспорить с тем фактом, что это создает серьезные проблемы для любого проекта.В недавнем исследовании, в котором более подробно изучались первопричины функциональных недостатков чипов, ключевым фактором стала ошибка проектирования. Также учитывались изменения в спецификации, а также неправильная или неполная спецификация. Все эти проблемы столь же серьезны, сколь и распространены, и все они имеют одну общую черту: более 50 процентов проблем, попадающих в любую из этих трех категорий, напрямую связаны с уровнем HSI.

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

Основываясь только на этом, должно быть легко понять, почему более половины всех проблем могут быть связаны непосредственно с аппаратно-программным интерфейсом. Не менее усложняет ситуацию и тот факт, что часто у компаний есть свои собственные уникальные задачи и требования, связанные с SoC.

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

Гибкое инновационное будущее, которое вам нужно

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

IDesignSpec (IDS) компании Agnisys — это лишь один из многих примеров достижений, которые значительно продвинулись в решении всех этих проблем в будущем.Эти типы решений обычно совместимы с широким спектром различных выходов в зависимости от ваших потребностей, включая, помимо прочего, такие, как Verilog/VHDL, модель C, UVM и другие. Они часто доступны во всем, от пакетной обработки (вспомните: командная строка) до Word и Excel и даже опций с открытым исходным кодом, таких как Open Office.

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

Наконец, можно использовать единый инструмент для создания тестовых последовательностей и сред, для создания формальных свойств и утверждений, для создания последовательностей UVM и программно-аппаратных программ из спецификации, а также для создания межплатформенной спецификации уровня HSI, которая в равной степени служит всем сторонам в способ, который должен был присутствовать все время. У Agnisys есть записанный веб-семинар по  , как определить и повысить производительность при работе с HSI , если вы хотите узнать больше.

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

Опять же, неважно, о каком именно инструменте вы говорите. Появилось следующее поколение аппаратно-программных интерфейсных решений, и они не только помогают решить подавляющее большинство проблем, которые присутствовали в «старой школе», но также имеют ряд важных последствий для почти каждая отрасль, о которой вы только можете подумать, слишком сильна, чтобы ее игнорировать.

Функциональная безопасность

Одна из многих областей, в которых HSI играет важную роль, связана с функциональной безопасностью и стандартом ISO 26262. Автомобильные инженеры, например, должны убедиться, что в их конструкции нет единой точки отказа, и они придерживаются этого стандарта для ECC — CRC и четности или других методов, таких как тройное резервирование модулей (или TMR).

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

Наконец, у нас есть область медицины — область, в которой аппаратно-программный интерфейс важен, поскольку соблюдение определенных требований является критически важным. Кроме того, все они также предъявляют свои уникальные требования к самому уровню HSI, влияя на то, как вы реализуете определенные факторы и как все будет выглядеть в будущем.

К сожалению, как бы ни был важен HSI в теории, на практике он находится в застое в худшем из возможных способов. Это так же важно, как и всегда, но существуют определенные проблемы, которые абсолютно сдерживают инновации, а не продвигают их вперед.

В конце

Само собой разумеется, что при работе со сложным программно-аппаратным интерфейсом возникает множество проблем. Однако, как это чаще всего бывает, существует также огромное количество возможностей.Достижения в этой области, например, IDesignSpec, позволили людям изменить свое представление о HSI в лучшую сторону.

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

Аппаратный интерфейс

– обзор

3.1 ОЦИФРОВКА АНАЛОГОВЫХ СИГНАЛОВ

При выборе подходящего аппаратного и программного обеспечения для лабораторного интерфейса возникает много вопросов, но в основе всего лежит основной принцип представления аналогового сигнала в цифровой форме. Обсуждение сбора компьютерных данных требует четкого понимания того, что означают термины «аналоговый» и «цифровой». Цифровой означает выражаемый в виде числовых цифр, а цифровой компьютер — это тот, который хранит и обрабатывает данные в виде чисел.Числовая информация является точной, в том смысле, что число либо имеет, либо не имеет определенного значения. Это также , дискретное , поскольку двоичные числа, используемые компьютерными системами, могут принимать только целые значения (… −2, −1, 0, 1, 2, …). В реальном мире, однако, большая часть информации находится в форме , аналога – по своей природе является непрерывным , а приближается к по своей природе. Например, нельзя точно указать температуру в комнате. В лучшем случае можно сказать, что она находится в определенных пределах, и теоретически в этих пределах возможен бесконечный диапазон значений температуры.Простой ртутный термометр может показывать значение 20°C, более точный – 20,1°C. Даже если предположить, что существует бесконечно точный термометр, для выражения точного значения температуры потребовалось бы числовое значение с бесконечным числом цифр.

Хранение аналоговой информации в цифровой компьютерной системе, таким образом, требует преобразования непрерывной, приблизительно известной величины в точную числовую форму. Для этого непрерывный диапазон возможных аналоговых значений должен быть преобразован в соответствующий диапазон дискретных целых чисел.Основа процесса оцифровки показана на рис. 3.1, на котором показан изменяющийся аналоговый сигнал напряжения (а), создаваемый электронным термометром в течение 8 секунд в зависимости от изменения температуры. Диапазон выходного напряжения термометра (0–5 В) разбит на серию из 16 равных интервалов, каждому из которых присвоено целое число в диапазоне 0–15, как показано на (б). Отсчеты напряжения берутся через равные промежутки времени (каждые 0,25 с) в течение временного хода сигнала, и целые числа назначаются в зависимости от интервала напряжения, в котором находится каждый отсчет.В результате получается оцифрованная запись с 32 отсчетами, показанная на (c). Можно видеть, что процесс оцифровки привел к некоторой потере информации из-за квантования аналогового сигнала с амплитудой сигнала, представленной ближайшим из последовательности фиксированных уровней. Непрерывный сигнал также квантуется по времени, при этом информация доступна только в фиксированные моменты времени, когда были получены образцы.

Рисунок 3.1. Оцифровка аналогового сигнала. (а) Исходный аналоговый сигнал.(b) Уровни квантования (16) 4-битного АЦП в диапазоне 0–5 В. (c) Оцифрованное представление (a) с использованием 4-битного АЦП, выборка каждые 0,25 с. (d) Оцифровка более высокого качества с использованием 8-битного (256-уровневого) АЦП, дискретизация каждые 0,08 с.

Качество оцифрованного представления аналогового сигнала в решающей степени зависит как от количества доступных уровней амплитуды, так и от количества выборок (или, точнее, частоты выборки), сделанных во время прохождения сигнала. Как видно из рис.3.1(c), 16 уровней и всего 32 отсчета явно недостаточно для представления плавно изменяющегося во времени хода исходного сигнала. Однако значительного улучшения качества сигнала можно добиться, используя 256 уровней оцифровки, а также увеличив число отсчетов до 98, как показано на рис. 3.1(d). Как показывает этот пример, важно обеспечить наличие достаточного количества уровней оцифровки для представления амплитуды сигнала с достаточным количеством выборок, взятых для представления временной динамики, если необходимо избежать ошибок квантования.

Скорость, с которой должны собираться выборки, зависит от того, насколько быстро изменяется аналоговый сигнал. Например, на рис. 3.1(а) видно, что сигнал изменяется за долю секунды. Само собой разумеется, что интервал выборки должен быть значительно короче, чтобы адекватно представить этот временной ход. Рисунок 3.1(d) с интервалом выборки 0,08 с (или 12,5 выборки в секунду) дает гораздо лучшее представление временной динамики аналогового сигнала, чем рис.3.1(c), где интервал выборки составляет всего 0,25 с (четыре выборки в секунду). Установка частоты дискретизации — одно из самых важных решений, которое принимает экспериментатор при настройке системы оцифровки, и именно здесь новички часто допускают ошибки. Вообще говоря, полезное эмпирическое правило состоит в том, чтобы выбрать частоту дискретизации, которая гарантирует, что есть по крайней мере две выборки, взятые из наиболее быстро меняющейся части записи сигнала. Например, на рис. 3.1 (а) наиболее быстрым событием в сигнале является резкий рост непосредственно перед отметкой 6 с от 3–4 В в пределах 0.02 с. Это говорит о том, что следует использовать интервал выборки 0,01 с (100 выборок в секунду) или меньше. При использовании более высоких частот дискретизации ничего не теряется, единственным недостатком является большее количество выборок в оцифрованной записи. Таким образом, если есть какие-либо сомнения относительно приемлемости частоты дискретизации, следует ошибиться в сторону более высоких частот. Ненужные выборки всегда можно отбросить позже, но информация, потерянная из-за недостаточно высокой частоты выборки, уже никогда не будет восстановлена.

Команды аппаратного интерфейса — Документация по векторному пакетному процессору 01

Этот раздел содержит те интерфейсные команды, которые относятся к аппаратному интерфейсу:

Показать мост-домен

Сводка/Использование

show bridge-domain [ bridge-domain-id [detail|int|arp| бд-тег ]]

Описание

Показать сводку обо всех экземплярах домена-моста или подробное представление одного домена-моста.Мост-домены создаются путем добавления интерфейса к мосту с помощью команды set interface l2 bridge .

Пример использования

 Пример отображения всех bridge-доменов:

vpp# показать домен моста

 ID Index Learning U-Forwrd UU-Flood Flood ARP-Term BVI-Intf
 0 0 выкл выкл выкл выкл локальный0
200 1 вкл вкл вкл выкл Н/Д

Пример отображения деталей одного bridge-домена:

vpp# показать детали bridge-domain 200

 ID Index Learning U-Forwrd UU-Flood Flood ARP-Term BVI-Intf
200 1 вкл вкл вкл выкл Н/Д

         Индекс интерфейса SHG BVI VLAN-Tag-Rewrite
 Гигабитный Ethernet0/8/0. 200 3 0 - нет
 GigabitEthernet0/9/0,200 4 0 - нет
 

Декларация и реализация

Объявление: bd_show_cli (src/vnet/l2/l2_bd.c строка 1151)

Реализация: bd_show

Показать аппаратные интерфейсы

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

• краткое : Показать только имя, индекс и состояние (по умолчанию для привязанных
  интерфейсы).
• подробный : Также отображать дополнительные атрибуты (по умолчанию для всех остальных
  интерфейсы).
• подробно : Также отображать все оставшиеся атрибуты и расширенные
  статистика.

Примечание

Чтобы ограничить вывод команды связанными интерфейсами и их
ведомых интерфейсов используйте необязательный параметр ‘ bond ’.

Сводка/Использование

 показать аппаратные интерфейсы [кратко|подробно|подробно] [связь] [<интерфейс> [<интерфейс> [. .]]] [ [ [..]]].
 

Примеры

Пример отображения данных по умолчанию для всех интерфейсов:

 vpp# показать аппаратные интерфейсы
              Название Оборудование Idx Link
GigabitEthernet7/0/0 1 вверх GigabitEthernet7/0/0
  Адрес Ethernet ec:f4:bb:c0:bc:fc
  Интел е1000
    Несущая скорость полного дуплекса 1000 mtu 9216
    rx очереди 1, rx desc 1024, tx очереди 3, tx desc 1024
    сокет процессора 0
GigabitEthernet7/0/1 2 вверх GigabitEthernet7/0/1
  Адрес Ethernet ec:f4:bb:c0:bc:fd
  Интел е1000
    Несущая скорость полного дуплекса 1000 mtu 9216
    rx очереди 1, rx desc 1024, tx очереди 3, tx desc 1024
    сокет процессора 0
VirtualEthernet0/0/0 3 вверх VirtualEthernet0/0/0
  Адрес Ethernet 02:fe:a5:a9:8b:8e
VirtualEthernet0/0/1 4 вверх VirtualEthernet0/0/1
  Адрес Ethernet 02:fe:c0:4e:3b:b0
VirtualEthernet0/0/2 5 до VirtualEthernet0/0/2
  Адрес Ethernet 02:fe:1f:73:92:81
VirtualEthernet0/0/3 6 вверх VirtualEthernet0/0/3
  Адрес Ethernet 02:fe:f2:25:c4:68
local0 0 вниз local0
  местный
 

Пример отображения подробных данных для интерфейса по имени и индексу программного обеспечения
(где 2 — индекс ПО):

 vpp# показать аппаратные интерфейсы GigabitEthernet7/0/0 2 подробный
               Название Оборудование Idx Link
GigabitEthernet7/0/0 1 вверх GigabitEthernet7/0/0
  Адрес Ethernet ec:f4:bb:c0:bc:fc
  Интел е1000
    Несущая скорость полного дуплекса 1000 mtu 9216
    rx очереди 1, rx desc 1024, tx очереди 3, tx desc 1024
    сокет процессора 0
GigabitEthernet7/0/1 2 отключено GigabitEthernet7/0/1
  Адрес Ethernet ec:f4:bb:c0:bc:fd
  Интел е1000
    Несущая скорость полного дуплекса 1000 mtu 9216
    rx очереди 1, rx desc 1024, tx очереди 3, tx desc 1024
    сокет процессора 0
 

Очистить аппаратные интерфейсы

Очистить расширенную статистику для всех или списка заданных интерфейсов
(статистика, связанная с командой show hardware-interfaces ).

Сводка/Использование

 очистить аппаратные интерфейсы [ [ [..]]] [ [ [..]]].
 

Примеры

Пример очистки расширенной статистики для всех интерфейсов:

 vpp# очистить аппаратные интерфейсы
 

Пример очистки расширенной статистики для интерфейса по имени и индексу ПО
(где 2 — индекс ПО):

 vpp# очистить аппаратные интерфейсы GigabitEthernet7/0/0 2
 

Поворотные регуляторы для современных аппаратных интерфейсов

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

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

Рисунок 1 : Поворотный элемент пользовательского интерфейса. Изображение предоставлено Shutterstock

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

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

Недавний пример тонкой интерфейсной панели показан на рис. 2, где три поворотных регулятора объединены с различными кнопками, индикаторами и дисплеями.

Рисунок 2 : Современная тонкая панель пользовательского интерфейса. Изображение предоставлено ALMAX

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

Проектирование аппаратного пользовательского интерфейса

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

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

Рис. 3 : Пользовательский интерфейс воображаемого продукта.Изображение предоставлено ALMAX

.

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

Как показано на рисунке 4, эти типы клавиатур легко взаимодействуют с обычными микроконтроллерами и доступны в толщине приблизительно 2 мм или меньше. Доступны различные варианты монтажа на панель, в том числе многие из них плотно закрыты и имеют степень защиты IP.

Рисунок 4 : Стандартная пленочная клавиатура. Изображение предоставлено Digikey 

.

Что касается визуального экрана, то за последние годы множество вариантов дисплеев также расширилось, предлагая решения любой формы и размера, начиная от электронных чернил и органических светодиодов (OLED) и заканчивая тонкопленочными транзисторами (TFT) и базовыми жидкокристаллический дисплей (LCD).

Недорогой матричный ЖК-дисплей показан в качестве примера на рис. 5 и включает встроенную подсветку с регулировкой контрастности.

Рисунок 5 : ЖК-дисплей (слева) и схема управления контрастностью (справа). Изображения предоставлены Instructables и Farnell

Этот тип дисплея также довольно тонкий (всего 2 мм) и прекрасно вписывается в ограничения, предъявляемые к продукту, при минимальной стоимости.

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

Варианты поворотного управления

В качестве отправной точки можно рассмотреть почтенный потенциометр, показанный ниже на рис. 6. 

Электрически это можно было бы просто подключить к шинам питания, чтобы создать делитель напряжения.

Кроме того, выход центрального отвода можно использовать для управления V0, а большое значение, например 100 кОм, сведет к минимуму энергопотребление и сложность.

Рисунок 6 : Стандартный потенциометр для монтажа на панель. Изображение предоставлено Digikey 

.

Механически ситуация значительно более проблематична.

Проблема использования понтиметров

Потенциометры страдают от выхода из строя дворников и компонентов цепи, обычно длящихся всего 25-50 тыс. оборотов.

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

Что еще хуже, так это то, что глубина корпуса большинства потенциометров значительно превышает доступное пространство, причем многие из них находятся в диапазоне 9–10 мм. Эти характеристики в совокупности могут сделать потенциометр относительно нежелательным вариантом.

Квадратурные энкодеры как поворотное решение

Для достижения меньшей глубины корпуса и упрощения требований к монтажу следует рассмотреть еще один распространенный поворотный регулятор — квадратурный энкодер.

Как показано на рис. 7, эти энкодеры доступны как для монтажа на печатной плате, так и для монтажа на панель, очень похожие по своей природе на потенциометр.

Рис. 7 : Традиционный квадратурный энкодер и результирующие сигналы. Изображение предоставлено TTElectronics

Однако с электрической точки зрения квадратурные энкодеры вводят целый ряд новых сложностей.

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

Чтобы использовать это для управления напряжением, как в приведенном выше примере контрастности ЖК-дисплея, необходимо использовать промежуточную цепь для преобразования последовательности импульсов в аналоговое напряжение.

Такая схема ни в коем случае не является простой и добавляет дополнительный уровень сложности и стоимости.

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

Преимущества MaxRotors

Чтобы восполнить пробелы в вышеупомянутых недостатках потенциометров и энкодеров, центральное место заняла относительно новая технология: MaxRotor.

Как показано на схеме сборки на рис. 8, MaxRotor состоит из сэндвича механических частей по обе стороны от жесткого или гибкого слоя схемы.

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

Рисунок 8 : MaxRotor в сборе.Изображение предоставлено ALMAX

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

От верхней поверхности ротора до нижней грани всего 5,48 мм, и все это в пределах 25 мм x 25 мм.

После обширных испытаний на несколько сотен тысяч оборотов MaxRotor рассчитан на 100 000 оборотов, что почти вдвое превышает надежность традиционных энкодеров и потенциометров.

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

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

Рис. 9: Глубина панели MaxRotor (крайняя справа) по сравнению с конкурентами. Изображение предоставлено ALMAX

Уровень схемы может быть встроен в готовый MaxRotor или может быть полностью настроен в конечном приложении как часть более крупной схемы PCB или Flex.

Несколько примеров показаны на рис. 10. 

Рисунок 10 : Примеры вариантов схемы MaxRotor.Изображение предоставлено ALMAX

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

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

В случае контрастного датчика ЖК-дисплея можно реализовать очень простую конструкцию, создав выделенный слой схемы и сконструировав «автономный» MaxRotor, как показано на рисунке 11.

Рисунок 11 : MaxRotor реализован как автономное устройство. Изображение предоставлено ALMAX

Эта автономная конфигурация позволяет легко установить MaxRotor рядом с клавиатурой, не интегрируя его в ту же печатную плату.

На рис. 12 внизу показана окончательная реализация регулятора контрастности, что свидетельствует о простоте и возможностях MaxRotor.

Рисунок 12 : Реализация управления контрастами MaxRotor.Изображение предоставлено ALMAX

Использование MaxRotor в качестве ротационного решения

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

Благодаря использованию нескольких готовых компонентов и гибко конфигурируемого MaxRotor интерфейс можно реализовать толщиной менее 6 мм с минимальной сложностью конструкции и высокой надежностью.

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

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

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

Заинтересованы в решении MaxRotor? Узнайте больше на веб-сайте ALMAX.

Отраслевые статьи — это форма контента, которая позволяет отраслевым партнерам делиться полезными новостями, сообщениями и технологиями с читателями All About Circuits способом, для которого не подходит редакционный контент.Все отраслевые статьи подчиняются строгим редакционным правилам с целью предоставления читателям полезных новостей, технических знаний или историй. Точки зрения и мнения, выраженные в отраслевых статьях, принадлежат партнеру и не обязательно принадлежат All About Circuits или его авторам.

Поток генерации интерфейса HW/SW на основе абстрактных моделей системных приложений и аппаратных архитектур

Amin El Mrabti ¹ , Фредерик Руссо ¹ , Hamed Sheibanyrad ¹ , Fredéric Ptrot ¹ , Romain Lemaire ² , Jérome Martin ² , Emmanuel Vaumorin ³ , Maxime Palus ^3
1 Лаборатория TIMA, 46 Ave Felix Viallet, 38031 Гренобль CEDEX, Франция {амин. elmrabti, hamed.sheibanyrad, rederic.rousseau, frederic.petrot}@imag.fr
² CEA, LETI, MINATEC, F38054 Grenoble, France {romain.lemaire, jerome.marti}@cea.fr
³ Magillem Design Services, 4 rue de la pierre levée 75011 Paris, France {vaumorin, palus}@magillem.com

Abstract

Растущая сложность аппаратных архитектур для удовлетворения растущих требований к производительности системных приложений открывает новые возможности. проблемы программирования, в частности, когда мы стремимся использовать одну и ту же аппаратную платформу для разных приложений.В настоящее время, помимо нескольких процессоров общего назначения, система-на-чипе может состоять из набора настраиваемых компонентов IP (интеллектуальные свойства), соединенных сетью-на-чипе (NoC). Программирование такой архитектуры требует определения набора различных, но абсолютно зависимых кодов конфигурации. Это определение очень затрудняет настройку общего потока генерации интерфейсов HW/SW, то есть адаптеров, позволяющих приложению работать на данной архитектуре.

В этой статье мы представляем поток генерации кода для развертывания системных приложений на аппаратных архитектурах на основе абстрактных описаний.Наш подход состоит из двух этапов: внешний этап, который имеет дело с абстрактным описанием приложения, архитектурой (в расширенном IP-XACT), отображением, и внутренний этап, который включает в себя конкретные сведения о платформе, необходимые для HW/ Генерация интерфейса ПО. Также представлен пример развертывания сложного телекоммуникационного приложения 4G на гетерогенной многоядерной платформе.

1. Введение

Постоянно растущая сложность приложений требует сложных аппаратных архитектур для поддержки требований приложений.Развитие технологий способствовало использованию таких архитектур, объединяющих высокопроизводительные вычислительные ресурсы (ЦП, DSP, аппаратный IP и т. д.), а также эффективные коммуникационные ресурсы (NoC, шина и т. д.). Развертывание приложения на таких архитектурах обычно заключается в создании нескольких отдельных задач, которые выполняются на нескольких ресурсах. Это сложная задача, поскольку эффективное использование большого количества архитектурных ресурсов уже не является тривиальной задачей, а также требует разделения вычислительных и коммуникационных функций.Эта трудность возрастает по мере усложнения аппаратной архитектуры и системного приложения.

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

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

Традиционный поток проектирования программного обеспечения для многопроцессорной архитектуры представлен на рис.1. Он принимает в качестве входных данных высокий уровень абстракции моделей приложений, архитектуры и отображения. Цель состоит в том, чтобы сгенерировать исполняемый код для программируемых вычислительных ресурсов (ЦП) и, возможно, информацию для компиляции и компоновки. Генератор программного обеспечения может использовать библиотеки программных компонентов (операционная система, драйверы и т. д.). Для каждого процессора получаем двоичный код, который размещается в участках памяти, принадлежащих адресным пространствам процессора.

Рисунок 1. Процесс генерации программного кода

Теперь кажется, что все архитектуры, развертывающие сложные приложения, основаны не только на многопроцессорной архитектуре, но и на наборе конкретных компонентов обработки IP (интеллектуальных свойств). Платформы FAUST [22] и MAGALI [21] [24] являются реальными примерами таких архитектур, использующих сеть на кристалле (NoC) в качестве коммуникационной инфраструктуры. Интерес к платформе такого типа заключается в возможности настраивать связь и вычислять IP-адреса (т. е. устанавливать значения регистров). Платформа такого типа позволяет запускать сценарии выполнения локально с помощью компонента коммуникационного интерфейса или глобально. В этом случае генерация кода становится генерацией файлов конфигурации, которые будут использоваться для локальной или глобальной настройки IP-адресов и сценариев планирования.Действительно, конфигурация для вычисления IP состоит в предоставлении параметров выполнения для определенной функциональности и, таким образом, в программировании внутренних регистров соответствующего IP. Для коммуникационных ресурсов коды конфигурации представляют конфигурации для коммуникационных интерфейсов, которые связывают IP-адреса с маршрутизаторами NoC. Некоторые другие файлы конфигурации и микропрограммы могут потребоваться для организации сценариев конфигурации, которые представляют общее поведение приложения.

В отличие от традиционной схемы проектирования на рис.1, который больше не соответствует этой архитектуре на основе IP, решение, представленное в этом документе, представляет собой общий поток генерации для интерфейсов HW/SW, который поддерживает различные типы аппаратных архитектур. Мы называем интерфейсом HW/SW набор необходимой информации для работы функций приложения с архитектурными ресурсами. Таким образом, интерфейсы HW/SW представляют собой набор файлов, необходимых для программирования архитектур на основе IP (коды конфигурации, микропрограммы) и многопроцессорных архитектур (исполняемые двоичные коды).Для этих двух типов архитектуры интерфейсы HW/SW могут быть представлены на разных уровнях, которые будут описаны далее в этой статье. Поток основан на абстрактных описаниях приложения, архитектуры и разделения ресурсов. Этот подход напоминает классическую цепочку компиляции, включающую две фазы: переднюю часть и внутреннюю часть.

Этот документ организован следующим образом. В разделе 2 рассматриваются некоторые смежные работы в области автоматизации генерации кода.Раздел 3 знакомит с различными типами интерфейсов HW/SW. В разделе 4 представлен предложенный нами алгоритм генерации интерфейса HW/SW. В разделе 5 объясняется фаза переднего плана потока и соответствующая среда разработки. Раздел 6 подробно описывает этап Back End. В разделе 7 представлен пример развертывания приложения 3GPP-LTE (Long Term Evolution) на базе IP-платформы под названием MAGALI. Раздел 8 завершает этот документ и дает перспективы будущих работ.

2. Связанные работы

Автоматизация генерации интерфейсов HW/SW для легкого развертывания приложений на архитектурах является важной исследовательской проблемой.Использование абстрактных моделей приложений и архитектур в процессе автоматизации значительно сокращает время разработки продукта на рынке. Несколько методов генерации кода HW/SW были разработаны с использованием прикладных моделей KPN и многопроцессорной целевой архитектуры [2][3][4]. В [4] [5] инструмент под названием ESPAM (синтез платформы на уровне встроенной системы и сопоставление приложений) использует модель приложения KPN, модель платформы с многопроцессорной архитектурой и описание сопоставления вместе с компонентами RTL, импортированными из библиотеки IP, для создания синтезируемого VHDL. и код C/C++ для прикладных задач, сопоставленных с ядрами.DSX [3] для Design Space eXplorer использует абстрактные модели, помогающие отображать многопоточное приложение на многопроцессорную архитектуру, смоделированную с помощью компонентов SocLib [6]. DOL [2] означает «уровень распределенных операций», моделирующий приложения как сети процессов. Семантика связи представляет собой канал «точка-точка» по принципу «первым пришел – первым обслужен» (FIFO). Спецификация архитектуры в DOL представляет собой многопроцессорную архитектуру и содержит структурные данные и информацию о производительности. Цель использования DOL — добиться эффективного выполнения приложения в гетерогенной архитектуре MPSoC путем итерации процесса сопоставления. Язык сопоставления в DOL специфичен для сопоставления приложения KPN с многопроцессорной архитектурой. В [7] [8] предложен процесс разработки программного обеспечения для создания встроенного программного обеспечения для моделирования и оценки производительности. Модель архитектуры системы аннотируется параметрами приложения и архитектуры, которые могут влиять на общую производительность конечной системы. Gaspard2 [9] представляет собой инструмент, реализующий поток проектирования на основе MDA (архитектура, управляемая моделями). Это позволяет моделировать, моделировать, тестировать и генерировать код программного и аппаратного обеспечения.Поток Gaspard фокусируется на приложениях с интенсивной обработкой сигналов. Авторы [10] предлагают алгоритм отображения модели приложения SDF (Synchronous Data Flow) на архитектуру на основе NoC [11]. Отображение рассчитывается с учетом ограничений пропускной способности. SDF используются для моделирования мультимедийных приложений, ограниченных по времени. Модель архитектуры представляет собой шаблон плитки, соединенной через NoC. Тайл должен содержать один процессор, одну память и сетевой интерфейс. Syndex [12] (Synchronized Distributed EXecutives) — это инструмент САПР системного уровня.Алгоритм детерминированной обработки изображений описывается как Data Flow Graph (DFG). Граф архитектуры описывает набор взаимосвязанных процессоров. Отображение состоит в распределении и планировании различных частей алгоритма приложения по архитектуре и предоставлении временного графика. Затем инструмент генерирует общие исполнители, которые представляют собой набор микровызовов. Макропроцессор M4 [13] преобразует микровызовы в компилируемый код для конкретной цели. PeaCE (расширение Ptolemy как Codesign Environment) [14] — это среда разработки кода, ориентированная на мультимедийные приложения.Он начинается со спецификации приложения с использованием формальных моделей, таких как модели потоков данных и FSM. Также описывается исследуемая архитектура (заранее определенная аппаратная платформа или новая платформа с использованием библиотеки компонентов). PeaCE генерирует код разделения для каждого элемента обработки.

Подход, который мы представляем в этой статье, концентрируется на создании интерфейсов HW/SW для различных типов архитектур (архитектуры с несколькими ЦП, архитектуры с настраиваемыми элементами обработки, такими как аппаратные IP-адреса), в то время как большинство представленных связанных работ сосредоточены на случаях многопроцессорной архитектуры.Мы принимаем во внимание сложное приложение потока данных, которое KPN и SDF не могут выразить (раздел 5.2). Мы также предлагаем гибкое определение отображения, в то время как большинство представленных связанных работ определяют конкретный язык отображения, который зависит от типа приложения и архитектуры.

Некоторые потоки проектирования используют проприетарные языки для описания приложений, архитектуры и отображения. Спецификация метамодели Metropolis [15] используется для моделирования функциональности, архитектуры и отображения.SystemC также может использоваться для описания архитектуры и приложения. В нашем подходе мы предлагаем входные данные на основе XML для моделирования приложения и архитектуры, а также для описания некоторой дополнительной информации, называемой метаданными (например, количество данных в потоке). Метаданные не могут быть легко представлены на таком языке, как SystemC, предназначенном для выполнения. Наше использование нотации XML основано на стандарте IP-XACT [16] и потому, что это интересный формат для анализа, создания и хранения структуры и параметров системы [17].Нотация XML уже использовалась в некоторых связанных работах [2] [10].

3. Уровни интерфейса HW/SW

3.1 Уровни интерфейса HW/SW для многопроцессорных архитектур

В многопроцессорных архитектурах (рис. 2.b) интерфейсы HW/SW моделируются как набор уровней программного обеспечения ( Рис. 2а). Прикладной уровень представляет собой набор взаимодействующих задач. Для их обработки используется Task API. Слой API задач включает в себя примитивы параллельного программирования задач (Posix Pthread API, MPI и т. д.).Реализация примитивов параллельного программирования задач основана на примитивах уровня операционной системы (ОС). Коммуникационный уровень предоставляет набор коммуникационных примитивов, которые будут использоваться на прикладном уровне для обработки связи между задачами. Коммуникационные примитивы — это в основном примитивы для чтения и записи данных и для синхронизации задач. ОС используется для планирования задач через процессор и предоставляет услуги по управлению аппаратными ресурсами.

Рисунок 2.Аппаратно-программный интерфейс для многопроцессорной архитектуры

Уровень аппаратной абстракции (HAL) содержит набор реализованных сервисов, предоставляемых архитектурой для ее абстрагирования и обработки. Уровень API HAL является интерфейсом уровня HAL и содержит набор примитивов, соответствующих службам HAL. Например, switchcontext (oldContext типа CXT, newContext типа CXT) — это примитив, являющийся частью HAL API компонента ЦП, который позволяет переключать контекст и может использоваться при планировании задач операционной системой. Примитивы и службы, предлагаемые ОС, построены на основе примитивов HAL API. В [25] [26] представлены потоки проектирования для генерации двоичного кода, реализующего уровни интерфейса HW/SW для многопроцессорных архитектур.

3.2 Уровни интерфейса HW/SW для IP-архитектур

как набор слоев, состоящий из конфигурационного кода и микропрограмм.Уровень «Глобальное планирование» описывает поведение приложения на основе оркестровки элементарного поведения настраиваемых IP-адресов, определенных на уровне «Планирование ресурсов». Стек конфигурации (рис. 3.c) абстрагирует настраиваемый IP и разделяет вычислительные и коммуникационные функции [1] на два отдельных уровня (соответственно уровни COM и HAL). Уровень «Планирование ресурсов» определяет поведение IP путем планирования набора вычислительных и коммуникационных конфигураций. Уровень связи содержит элементарные конфигурации связи, описывающие информацию об отправке и получении данных и о синхронизации глобального потока данных. Уровень HAL отличается от уровня, представленного для многопроцессорных архитектур. Он по-прежнему представляет элементарные услуги и функции, предоставляемые аппаратными ресурсами. Уровень HAL в данном случае представляет собой набор задач, которые могут выполнять IP-адреса. Каждая задача, предоставляемая IP, определяется набором параметров, которые инициализируют регистры IP для выполнения четко определенной функции.

3.3 HW/SW интерфейс для платформы MAGALI

MAGALI [21] [24] является примером архитектуры на основе IP.В этой платформе на основе NoC каждый маршрутизатор может быть подключен к пяти узлам (4 маршрутизатора и один ресурс).

Рисунок 4. Аппаратно-программный интерфейс для платформы MAGALI

Каждый узел состоит из сетевого интерфейса (NI), «контроллера конфигурации и связи» (контроллера CC), который обеспечивает взаимодействие между IP-адресами и NoC и один IP. Каждый контроллер CC может включать до четырех контроллеров ввода (ICC) и четырех контроллеров вывода (OCC) для целей связи. NI подключен к контроллеру CC, а контроллер CC к IP. Платформа также содержит один ЦП, который обеспечивает координацию связи и вычислений всех узлов. Платформа запрограммирована с несколькими файлами конфигурации (рис. 4.B), которые составляют интерфейс HW/SW:

(1) «Глобальное планирование» реализовано в файле с именем «cpu.sno», который представляет собой глобальный сценарий приложение. Оркестровка IP-конфигураций реализуется с помощью микропрограмм с использованием таких примитивов, как загрузка конфигурации ресурсов (LOAD_RES).Загружаемые конфигурации идентифицируются идентификатором ресурса, который должен соответствовать параметру «source_id» в конфигурации ресурса (файл res.sno: уровень планирования ресурсов).

(2) Уровень «Планирование ресурсов» определяет поведение IP в MAGALI, вызывая элементарные конфигурации связи (уровень связи) и конфигурации вычислений (уровень HAL) IP. Этот уровень реализован в файле с именем «ip.sno» для каждого IP-адреса.

(3) Платформа MAGALI реализует этот уровень с помощью каталогов ICC и OCC, в которых собраны основные конфигурации для связи, и микропрограмм, которые их планируют. Конфигурации связи связаны с элементами CC архитектуры. ICC сконфигурирован для получения данных от OCC, а элемент OCC сконфигурирован для отправки данных в ICC.

Конфигурация OCC, определенная в файле «occ.cfg», объясняет, как отправлять данные с IP-адреса, непосредственно подключенного к OCC, который мы хотим настроить, на другие IP-адреса. Конфигурация OCC содержит такую ​​информацию, как количество передаваемых данных, путь прохождения через NoC, значение счетчика кредитов и идентификатор ICC, который будет получать данные.Конфигурация ICC, определенная в файле «icc.cfg», объясняет, как получать данные по IP-адресу, напрямую подключенному к ICC, который мы хотим настроить. Конфигурация ICC содержит такую ​​информацию, как количество принимаемых данных, значение счетчика кредитов и идентификатор OCC, который их отправляет. Файл с именем «ctx.cfg» используется для планирования конфигураций ICC и OCC для IP с использованием таких примитивов, как RC: конфигурация запроса, LL: локальный цикл, GL: глобальный цикл.

(4) Уровень HAL в платформе MAGALI реализован в «ядре.cfg» для каждого IP-адреса, который инициализирует параметры IP. Другой файл «ip.str» также определяется для каждого IP-адреса и содержит параметры для настройки NoC, чтобы IP-адрес поддерживался (например, количество ICC и OCC). Файл «ctx.cfg», тот же самый, который мы упоминали на коммуникационном уровне, планирует базовые конфигурации, определенные в файле «core.cfg», для описания поведения IP. В MAGALI конфигурация (core.cfg, icc .cfg, occ.cfg) всегда индексируется идентификатором, на который ссылается микропрограмма (ctx.конфиг).

Эта сложность ручной настройки MAGALI для развертывания приложения связана с большим количеством разрабатываемых файлов конфигурации (конфигурация вычислений и связи, 80 файлов в примере, подробно описанном в разделе «Эксперимент»), большим количеством параметров для инициализации в каждый файл и зависимости между всеми этими файлами. Зависимости между параметрами в различных конфигурационных файлах делают отладку приложения, описываемого как набор конфигурационных файлов в MAGALI, узким местом, поскольку отслеживание зависимостей между параметрами в нескольких файлах затруднено и требует времени. Кроме того, добавление нового IP на платформу требует разработки новых конфигурационных файлов и модификации других. Это подчеркивает интерес к разработке метода и инструментов для автоматического создания интерфейсов HW/SW для такого рода платформ.

4. Обзор процесса создания интерфейсов HW/SW

Основная цель этой работы — определить поток создания интерфейсов HW/SW, предназначенных для различных типов платформ. Мы хотели бы гибко описать сопоставление с этими несколькими платформами и разработать генераторы для различных типов интерфейсов HW/SW.

В классических Y-методологиях проектирования SoC языки описания сопоставления обычно зависят от типа архитектуры (многопроцессорная, на основе NoC, на основе аппаратного IP и т. д.). Язык сопоставления всегда предоставляется вместе с языком моделирования архитектуры как способ изучения архитектуры. Предлагаемый поток достаточно гибок, чтобы поддерживать различные модели архитектур и определять соответствующие правила отображения. Он определяется, как и в цепочке компиляции, двумя частями: front-end и back-end.Подобный компиляции подход способствует созданию гибких инструментов генерации, которые легко поддерживать. Рис. 5. Процесс создания аппаратного/программного интерфейса с возможностью арбитража. Язык описания архитектуры, называемый ARDL (язык описания архитектуры), содержит два основных нововведения.Первый касается описания физических путей связи для изучения архитектуры. Второй — описание низкоуровневого программного уровня, предоставляемого архитектурой. Эти две модели могут быть написаны отдельно двумя разными людьми (дизайнером приложений и дизайнером архитектуры). Решение для сопоставления, которое мы представляем в нашем потоке, состоит из двух шагов для поддержки сопоставления для этих различных архитектур. Ограничения сопоставления определяются на предыдущем шаге, называемом мета-сопоставлением.Он определяет ограничения на сопоставление компонентов APDL и ARDL. Это специализация классического отображения на заданную архитектуру. Само сопоставление соответствует ограничениям и правилам, представленным на этапе мета-сопоставления. Затем создается общая промежуточная модель (GIM), которая описывает приложение, развернутое на ресурсах архитектуры. Он поддерживает представление аппаратных, программных и гибридных компонентов. Гибридные компоненты — это компоненты, которые связывают компоненты APDL с ресурсами ARDL, как определено в отображении.На этом уровне информация об интерфейсе, который мы хотели бы сгенерировать, недоступна.

Во внутренней части (рис. 5.B) конкретная промежуточная модель (SIM) содержит информацию, специфичную для платформы. Он вычитается из GIM Front-End части с дополнительными сведениями о целевой платформе. Например, мы можем указать информацию об адресных пространствах или прерываниях (тип, адрес вектора прерывания), которые зависят в основном от платформы. SIM предоставляет описание генерируемых элементов, составляющих интерфейс HW/SW.Он содержит всю необходимую информацию для создания конфигурации или двоичного кода для моделирования или прототипирования.

В этой модели гибридные компоненты, описанные в GIM, дополнены подробностями, показывающими, как соответствие между частью APDL и частью ARDL может быть конкретно выражено на целевой платформе. По сути, мы описываем, как программировать целевую платформу (структура конфигураций, способ описания участков памяти в случае многопроцессорных архитектур, адреса прерываний для устройств и т.д.).Использование такой модели может упростить генерацию кода, которую трудно реализовать с помощью GIM, не содержащего информации о целевой платформе.

5. Внешний интерфейс: Модели высокого уровня для генерации кода

5.1 ARDL: Уровень описания архитектуры

В качестве входных данных для нашего потока проектирования нам нужна абстрактная модель платформы. Один из способов выразить модель платформы — использовать IP-XACT. Стандарт IP-XACT представляет собой язык на основе XML для описания аппаратного обеспечения с целью интеграции IP.Он был разработан в основном для уровня RTL (описание проводных портов) и не соответствует нашим требованиям. Таким образом, мы определили новый язык описания оборудования, способный представлять различные типы платформ на высоком уровне абстракции. Этот новый язык является расширением стандарта IP-XACT. Мы будем использовать этот формат для использования TGI API, предоставляемого стандартом, для извлечения проектных данных и использования разработанных инструментов, работающих в соответствии со стандартом. ARDL — это предлагаемый язык для описания абстрактных архитектурных моделей (рис.6).

Рис. 6. Основные компоненты ARDL

Архитектура моделируется как набор иерархических систем. Система в ARDL представляет собой набор вычислительных компонентов, компонентов связи, компонентов хранения и устройств. Вычислительные элементы — это блоки обработки, которые являются абстракцией ЦП, ЦСП или настраиваемых аппаратных IP-адресов. ARDL может моделировать коммуникационные компоненты в дизайне на основе NoC или в проекте на основе шины. Если связь осуществляется с помощью NoC, мы можем указать в ARDL дополнительную информацию, касающуюся топологии NoC, размера и алгоритма маршрутизации. Две основные новинки представлены в ARDL по сравнению с такими языками, как [19] [10], для повышения автоматизации развертывания приложений:

(1) Моделирование API HAL (Hardware Abstraction Layer), который представляет собой примитивы для обработки аппаратных компонентов. Эта информация может использоваться, например, для параметризации драйверов в операционной системе или для параметризации поддержки связи.

(2) Моделирование архитектуры физических каналов связи.Мы хотим описать на высоком уровне информацию, которая может быть полезна, например, для выделения памяти или для реализации коммуникационных примитивов (чтение, запись) в случае приложения, работающего в архитектуре на основе ЦП. В некоторых аппаратных архитектурах количество каналов связи достаточно велико, чтобы затруднить работу проектировщика архитектуры. Канал связи между источником и ресурсом назначения описывается как набор ресурсов, задействованных для его реализации, а также некоторая другая необходимая информация (режим доступа: чтение/запись, протокол и т. д.).

Рисунок 7. ARDL «comLinkInterconnection»

Пример «коммуникационного канала» представлен на рисунке 7 и детализирует запись данных (строка 1) из «mem_src» (строка 3) в «mem_dest» (строка 4). через ЦП «cpu_ref» (строка 5) и шину «bus_ref» (строка 6). В случае архитектуры на основе IP эта информация будет использоваться для настройки IP-адресов.

5.2 APDL: уровень описания приложения

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

Описание приложения с помощью XML-нотации позволяет описать метаданные приложения. Эту информацию трудно извлечь из реализации C или SystemC. В прошлом было предложено много языков системного уровня для поддержки описания приложений с помощью нотации XML [3] [2] [10], но только для представления KPN или SDF.Новшеством в нашем предложении, называемом APDL, является возможность моделировать сложные передачи данных между задачами (рис. 8), чтобы описание приложения не ограничивалось моделями KPN или SDF. Этот язык описывает набор задач, которые выполняются параллельно, а также каналы, обеспечивающие передачу данных между задачами. Приложение, описанное с помощью APDL, состоит из двух разных компонентов: задач и каналов.

Рисунок 8. Основные компоненты APDL

Задача APDL определяется именем, ссылкой на исходный файл, а также информацией о языке программирования.Он обращается к каналам через порты задач. Порт задачи определяется именем, направлением, размером данных, передаваемых через порт, и номером процесса отправки и получения данных, выполненного из порта. Порт задачи моделирует вызов коммуникационного примитива (чтение или запись) в реализации задачи. Каналы представляют собой средство связи между задачами. Канал APDL представляет собой канал с несколькими входами и несколькими выходами. Он может моделировать каналы FIFO или каналы на основе общей памяти.

Канал APDL может планировать доступ к входам (соотв.выходы) благодаря входному (соответственно выходному) арбитру. Арбитром канала может быть входной или выходной арбитр. Это позволяет планировать доступ к каналу, устанавливая порядок доступа для портов канала. Порядок доступа определяется входной или выходной матрицей. Использование арбитров в описании канала необязательно. Этот язык поддерживает моделирование известных семейств приложений потоков данных, таких как KPN и SDF. Он определяется двумя схемами XML: «apdl_library.xsd», которая определяет синтаксис основных понятий в APDL, таких как задача, канал, арбитр и порт.Файл «apdl.xsd» включает эту библиотеку и определяет синтаксис языка.

Рис. 9. Канал APDL с входным арбитром

На рис. 9 показан пример входной матрицы канала APDL. В этом примере 3 задачи отправляют данные на канал с несколькими входами. Мы должны описать, благодаря входной матрице, порядок записи данных из задач в канал. Матрица (рис. 9.а) состоит из двух столбцов. Каждый столбец представляет собой сценарий записи данных из задач в канал.Последний элемент каждого столбца, т. е. последняя строка матрицы, указывает, сколько раз будет выполняться сценарий. В данном примере первый столбец указывает, что задача T1 запишет 10 данных, за которыми следуют 10 данных из T2 и T3. Этот сценарий повторяется дважды. Затем второй столбец входной матрицы начинается, когда заканчивается сценарий первого столбца. Это указывает на то, что задача T3 запишет 10 данных в канал. Поэтому данные упорядочены в FIFO канала, как на рис.9.б. В этом примере APDL предполагает, что объем данных, передаваемых между задачами, известен заранее.

5. 3 Мета-сопоставление и сопоставление

В большинстве существующих потоков проектирования язык сопоставления зависит от типа приложения и архитектуры, поскольку он связывает компонент приложения с ресурсами архитектуры. Отображение выполняется специально для приложений KPN или SDF в многопроцессорной архитектуре [2] [10]. Применяемые правила сопоставления могут отличаться от одного типа архитектуры к другому.Чтобы поддерживать несколько типов архитектур в нашем потоке генерации, мы ввели сопоставление в два этапа: первый шаг служит для настройки сопоставления с типом архитектуры и приложения путем определения правил сопоставления (шаг мета-сопоставления). Второй шаг заключается в применении этих правил при отображении компонента приложения на ресурсы архитектуры.

Модель мета-отображения в нашем потоке определяет, какой тип компонента APDL может быть отображен на какой тип компонента ARDL. Это может отличаться от одной архитектуры ARDL к другой.Мы также называем модель мета-отображения «контрактом отображения». Мета-отображение определяет набор ограничений. Мы находим два типа ограничений: (1) общие ограничения, касающиеся общих правил отображения. Например, общее ограничение может разрешать сопоставление канала APDL с настраиваемым IP-адресом или запрещать сопоставление задачи с ЦП, если оно зарезервировано для конфигурации ресурсов. Задачи в этом случае будут сопоставлены с аппаратными IP-адресами. (2) Особые ограничения касаются некоторых компонентов архитектуры.Например, если в нашей архитектуре есть два процессора A и B, мы можем захотеть, чтобы процессор A выполнял только одну задачу, а процессор B выполнял остальную часть приложения. Это может быть выражено на этапе мета-отображения и учтено во время отображения. Мета-отображение выполняется вручную и представляет собой первый шаг в процессе исследования.

В [20] авторы выделили три сценария проектирования по степени зависимости между отображением с одной стороны и архитектурой и моделями приложений с другой.Наше предложение по мета-сопоставлению поддерживает эти сценарии, предлагая гибкий способ описания различных правил сопоставления. Язык мета-отображения определяется также как XML-схема.

После выполнения мета-отображения можно описать развертывание компонентов приложения APDL поверх компонентов ARDL архитектуры, соблюдая ограничения, определенные на этапе мета-отображения. Отображение определяется «Привязкой задачи» и «Привязкой канала». Привязка задач позволяет сопоставлять задачи приложения APDL с процессорными блоками ARDL.Привязка каналов позволяет отображать каналы APDL через каналы связи ARDL. Это сопоставление детализируется путем определения соответствия между подкомпонентами канала APDL (арбитр, FIFO) и ресурсами ARDL, указанными как «AccessType» в определениях канала связи. Язык отображения также определяется как XML-схема.

Общая промежуточная модель (GIM) создается при выполнении файла сопоставления. Это XML-файл, описывающий ресурсы архитектуры (ресурсы ARDL), на которых развертывается приложение (компоненты APDL) в соответствии с ограничениями мета-отображения и определения отображения.

5.4 Обзор среды проектирования Front End

Интерфейсная часть потока проектирования разработана как расширение существующего инструмента промышленного дизайна под названием Magillem [18].

Рис. 10. Интерфейсная среда выполнения

Набор инструментов Magillem представляет собой полную среду проектирования IP-XACT, включая функции отладки и возможность запуска генераторов. Интерфейсная часть потока разработана в виде плагина Eclipse (рис.10). Основными функциями этого плагина являются возможность создания нового приложения, архитектуры, мета-отображения и моделей отображения с помощью соответствующих мастеров (рис. 10.а). Предлагаются средство просмотра метамэппинга (рис. 10.b) и проводник проекта Front-End (рис. 10.c). Преобразование для создания GIM выполняется компонентом «генератор IP-XACT», выполняемым по схеме ARDL и имеющим в качестве параметра файл приложения, файл мета-отображения и определение отображения. Этот генератор реализован в среде Magillem, так как ARDL реализован как расширение стандарта IP-XACT.

6. Серверная часть: Конкретная промежуточная модель и средства создания интерфейса HW/SW

6.1 Конкретная промежуточная модель (SIM) целевая платформа. Он моделирует все необходимые компоненты, которые должны быть реализованы в интерфейсе HW/SW, чтобы обеспечить развертывание приложения на целевой платформе.

На рис. 11.в показаны элементы SIM, соответствующие платформе MAGALI.IPScenario является основным компонентом, который вызывает элементы конфигурации и контекста из уровня связи и уровня HAL. Коммуникационный уровень содержит компоненты конфигурации, позволяющие описать передачу данных с/на IP (ICCConfig/OCCConfig).

Рисунок 11. Определение SIM-карты для IP-архитектуры

Уровень HAL содержит конфигурации для определения функций, которые будет выполнять IP. Более подробно о конфигурациях мы сообщим в разделе эксперимента.

6.2 Средства генерации интерфейса HW/SW

Инструменты для генерации окончательного кода интерфейса HW/SW извлекают информацию из SIM. На этом уровне процесса инструменты имеют информацию о грамматике кода для генерации (Makefile, грамматика файла конфигурации, шаблоны SystemC и т. д.). Эти инструменты еще не интегрированы в инструмент промышленного дизайна и зависят от целевой платформы или типа платформы. Использование таких моделей облегчает разработку генераторов, повышает производительность и способствует развитию и обслуживанию инструментов.

7. Эксперименты

7.1 Описание архитектуры

В этом эксперименте мы рассматриваем платформу MAGALI, которая была разработана для телекоммуникационных приложений со сложным потоком данных. «top_magali» (рис. 12.b) — это подсистема, которая содержит подмножество аппаратных IP-адресов MAGALI. Он включает IP-адреса для конкретных функций (mep, asip, rx_bit) и IP-адреса, которые моделируют программируемые устройства хранения (SME для Smart Memory Engine). «top_3gpp» (рис.12.a) — это основной проект, используемый для тестирования подсистемы «top_magali». Он содержит процессор для оркестрации конфигураций и два компонента для генерации и записи данных (recgen_00w, recgen_00s).

На рис. 12.c представлено графическое представление ARDL узла MAGALI (mep_10), разработанного в среде Magillem. Маршрутизатор подключен к сетевому интерфейсу, а сетевой интерфейс к набору основных контроллеров. Для выполнения приложений через MAGALI интерфейс HW/SW, состоящий из файлов конфигурации (как показано в 3.3) необходимо развивать.

Рисунок 12. Архитектура MAGALI, смоделированная с помощью ARDL

7.1.1 Физические каналы связи в MAGALI

В MAGALI разрешены все доступные физические каналы связи через NoC и между ресурсами. Они перечислены в сгенерированном файле с именем «comlink.cl» во время загрузки модели ARDL. «comlink.cl» содержит около 400 уязвимых каналов связи для архитектуры, описанной на рис. 12.Канал связи в MAGALI описывается как пара, состоящая из одного OCC, соответствующего ресурсу отправителя, и одного ICC, соответствующего ресурсу получателя: IP_sender OCC ICC IP_receiver. Рис. 13. Физические каналы связи в платформе MAGALI 13.б). «mep_10» объявлен как исходный компонент в ссылке (тег sourceInterface рис.13.c строка3) и «sme_21» в качестве компонента назначения (тег destinationInterface рис. 13.c строка4). Этот физический канал связи осуществляется через компонент OCC «occ0» (рис. 13.d) ресурса «mep10» и компонент ICC «icc0» (рис. 13.e) ресурса «sme_21» (тег AccessType Рис. 13.в строка 5,6).

Сгенерированный файл «comlink.cl» также содержит другие каналы связи между «mep_10» и «sme_21», где в качестве элементов «AccessType» используются другие ICC/OCC. Между «mep_10» и «mep_21» создано четыре канала связи: mep_10 occ0 icc0/icc1 /icc2/icc3 sme_21.Описание этих связей в архитектурной модели помогает в создании и инициализации некоторых коммуникационных конфигураций (icc.cfg, occ.cfg, ctx.cfg) для программирования и запуска приложения через NoC.

7.1.2 Описание HAL API в MAGALI

HAL API представляет собой набор примитивов, используемых для работы с аппаратными компонентами. Эти примитивы описываются как программные службы для таких компонентов, как DMA (dma_start и т. д.), ЦП (load_context, switch_context и т. д.) и т. д. Для аппаратного IP примитив HAL описывается как набор параметров, инициализированных для запуска определенной функции на ИП.Рисунок 14. Описание HAL (уровня аппаратной абстракции) в MAGALI выборки выходного радиоканала/частоты), которые будут использоваться в рассматриваемом приложении 3GPP-LTE. Этот IP предлагает два примитива, называемых «send_pilot» (рис. 14.b) и «send_data». «send_pilot» позволяет отправлять пилот-символы OFDM для оценки канала передачи.

Примитив «send_data» (рис. 14.c) позволяет отправлять символы данных OFDM, которые содержат данные полезной нагрузки для передачи через NoC. Описание этих примитивов в модели архитектуры полезно при создании конфигурационных файлов (core.cfg, ctx.cfg).

7.2 Описание приложения: Приложение 3GPP-LTE

Приложение, которое мы хотим сопоставить с архитектурой, представляет собой цифровую цепь демодуляции основной полосы частот для беспроводной связи, поддерживающую многоантенные (MIMO) и методы OFDMA. Структуры кадров и системные параметры основаны на реализации проекта OPUS [23] долгосрочной эволюции (LTE) сотовой системы третьего поколения (3G), в настоящее время нормализованной 3GPP (Проект партнерства 3G) (рис. 15).

Рисунок 15. Приложение 3GPP-LTE, смоделированное с помощью APDL

На рис. 15.a показан пример использования канала APDL в описании этого сложного приложения потока данных. Канал включает входной арбитр (рис.15.б). Матрица ввода определяет один сценарий ввода данных (номер столбца матрицы), который повторяется 24 раза.

Проведение сценария определяется записью 4 данных в FIFO канала из первого порта канала, поступающего от задачи «sme_21_coef13», затем 4 данных записывается в FIFO через второй порт, поступающего от «sme10_coef24» задача. Мы описали приложение с 16 задачами APDL и 19 каналами APDL, включая 11 каналов с одним входом и одним выходом, 2 канала с одним входом и несколькими выходами и 6 каналов с несколькими входами и одним выходом.

7.3 Описание мета-отображения и отображения

Мета-отображение для MAGALI соответствует определению того, на какой элемент MAGALI может быть отображен каждый элемент модели приложения. На рис. 16 показаны два ограничения отображения. Первый касается возможности сопоставления задачи APDL с ARDL HWIP (Hardware IP) (рис. 16.a, строки 3..6). Второе ограничение связано с отображением элемента CC, который определен как устройство ARDL. Мета-отображение позволяет отображать арбитра канала APDL или порт задачи APDL через устройство CC (рис.16.в 16.б строка 7..11).

Пример файла сопоставления приложения 3GPP-LTE через MAGALI показан на рис. 17. Это сопоставление соответствует ограничениям, определенным в мета-сопоставлении. Мы видим, что задача «sme10_coef24» (строка 1) сопоставляется с HWIP с именем «sme_10w» (строка 3) (ограничение 1). Порты задач одной и той же задачи соответственно отображаются на устройства ARDL «icc3_sme_10w» (строка 6) и «occ3_sme_10w» (строка 9).

Рисунок 16.Метадаппинг для платформы MAGALI

Метаданные, касающиеся трафика данных, определенных в портах задач и в арбитрах, используются для создания конфигурации связи (icc.cfg , occ.cfg).

Рисунок 17. Пример сопоставления для платформы MAGALI

7.4 Генерация файлов конфигурации

Файлы конфигурации, созданные для MAGALI с использованием предложенного нами алгоритма генерации, представляют собой конфигурации вычислений и связи, подробно описанные в 3.3. На рис. 18 мы отображаем сгенерированные файлы конфигурации для ресурса «recgen_00s». Файл «occ.cfg» (рис. 18.a) детализирует передачу данных, определяя путь прохождения через NoC (EAST EAST RES: sme_21), объем передаваемых данных (7600), размер каждого пакета. (8) и идентификатор ICC, который будет получать эти данные (num_icc 0). Эта конфигурация вызывается микропрограммой, определенной в файле «ctx.cfg» (рис. 18.b).

Примитив RC (запрос конфигурации) вызывается для выполнения упомянутой конфигурации, подробно описанной в «occ. конфиг». Для этого ресурса нет сгенерированного файла «icc.cfg», потому что IP-адрес «recgen_00s» только отправляет данные, не получая их. Файл «recgen_00s.load» (рис. 18.c) детализирует путь, по которому процессор взаимодействует с ресурсом (ЮГ). Функции, выполняемые «recgen_00s», определяются как набор инициализированных параметров. Проиллюстрируем конфигурации функций «отправить пилот-сигналы» и «отправить данные», которые определены в файле «core.cfg» (рис. 18.d). Эти конфигурации вызываются микропрограммой, определенной в файле «ctx.cfg» через примитив RC. Микропрограмма вызывает один раз «отправить пилоты», затем также один раз вызывает функцию «отправить данные».

Рисунок 18. Конфигурации связи и вычислений в MAGALI

Файлы конфигурации генерируются для всех IP-адресов платформы MAGALI, выполняются и проверяются на имитационной модели платформы SystemC/TLM. Количество файлов конфигурации, которые необходимо сгенерировать для запуска приложения 3GPP-LTE через MAGALI, составляет около 80 файлов конфигурации. Этот эксперимент использовался для проверки методологии, предлагаемых языков (APDL, ARDL, мета-отображение и отображение) и инструментов.

8. Заключение

В этой статье мы представляем общий алгоритм генерации кода интерфейса HW/SW на основе абстрактного описания приложения, архитектуры и разделения. Мы представляем APDL и ARDL как языки для описания абстрактных моделей приложений и архитектур. Мы предлагаем новый способ определения правил сопоставления и способа развертывания приложения в архитектуре.В примере мы покажем, как смоделировать сложное приложение под названием 3GPP-LTE с APDL и сложную архитектуру под названием MAGALI с ARDL. Мы показываем преимущества нашего шага мета-сопоставления для поддержки сопоставления такого сложного приложения с платформой MAGALI. Чтобы доказать актуальность нашего решения, мы представляем часть окончательно сгенерированных файлов конфигурации для запуска приложения 3GPP-LTE через MAGALI. Наши будущие работы будут сосредоточены на создании интерфейсов HW/SW с многоуровневым подходом, чтобы мы могли отлаживать и проверять сгенерированный код на каждом уровне абстракции. Мы постараемся проверить предложенный нами процесс для других платформ на основе ЦП.

9. Ссылки

[1] K. Keutzer, S. Malik, R. Newton, J. Rabaey, and A. Sangiovanni-Vincentelli, «System-Level Design: Orthogonalization of Concerns and Platform-Based Design» , IEEE Transactions по САПР схем и систем, том. 19 нет. 12, Dec. 2000

[2] Л. Тиле, И. Бачиваров, В. Хайд, К. Хуанг, «Отображение приложений на мозаичные многопроцессорные встраиваемые системы», Применение параллелизма к проектированию систем, ACSD 2007, стр.29-40.

[3] Н. Пуйон, А. Грейнер. DSX. URL = https://www.asim.lip6.fr/trac/dsx/, 2006–2008 гг.

[4] Х. Николов, Т. Стефанов, Э. Депреттер, «Проектирование многопроцессорных систем с помощью ESPAM», CODES 2006, стр. 211-216

[5] М. Томпсон, Х. Николов, Т. Стефанов, А. Д. Пиментел, К. Эрбас, С. Полстра, Э. Ф. Депреттер, «Структура для быстрого исследования, синтеза и программирования мультимедийных MP-SoC на системном уровне», CODES 2007, стр. 9-14

[6] Консорциум SoCLib.Projet SoCLib: Платформа для моделирования и моделирования интегрированных систем. https://www.soclib.fr/  

[7] К. Поповичи, X. Герен, Ф. Руссо, П.С. Паолуччи, А.А. Джеррая, «Поток разработки программного обеспечения на основе платформы для гетерогенных MPSoC», ACM TECS. Том 7 Выпуск 4 — Статья № 39 – 2008

[8] К. Хуан, С. И. Хан, К. Поповичи, Л. Брисолара, X. Герен, Л. Ли, X. Ян, С. Че, Л. Карро , АА Джеррая, «Поток проектирования MPSoC на основе Simulink: пример использования Motion-JPEG и H.264», DAC 2007, стр. 39 – 42

[9] P. Boulet, JL Dekeyser, C. Dumoulin, P. Marquet, «MDA for SoC Design, Intensive Signal Processing Experiment», FDL 2003,

[10 ] С. Стейк, MCW Гейлен, Т. Бастен, «SDF3: SDF For Free» ACSD 2006, стр. 276-278, Турку, Финляндия, июнь 2006 г.

[11] С. Стейк, Т. Бастен, М.К. В. Гейлен, Х. Корпорал. «Распределение многопроцессорных ресурсов для синхронных графов потоков данных с ограничением пропускной способности», DAC 2007, стр. 777-782

[12] М.Рауле, Ф. Урбан, Дж. Ф. Незан, К. Мой, О. Дефорж, Ю. Сорель, «Быстрое прототипирование гетерогенных многокомпонентных систем: поток MPEG-4 по каналу связи UMTS», журнал EURASIP по прикладной обработке сигналов, 2006 г., № 14

[13] Проект GNU M4: http://www.gnu.org/software/m4/

[14] S. Ha, C. Lee, Y. Yi, S. Kwon, Y. Joo, «Аппаратно-программное проектирование встроенных мультимедийных систем: мир», RTCSA 2006, стр. 207–214

[15] А. Даваре, Д. Денсмор, Т.Мейеровиц, А. Пинто, А. Санджованни-Винсентелли, Г. Ян, Х. Цзэн, К. Чжу, «Структура проектирования следующего поколения для платформенного проектирования», Конференция по использованию языков проектирования и проверки оборудования (DVCon) , 2007

[16] Веб-сайт консорциума SPIRIT: http://www.spiritconsortium.org [17] Г. Мартин, «Обзор проблемы проектирования MPSoC», DAC 2006, стр. 274-279

[18] Magillem Design Service, веб-сайт: www.magillem.com  

[19] Р. Маркулеску, Дж. Ху, Ю.Й. Ограс, «Ключевые проблемы исследования в области проектирования NoC: целостная перспектива», CODES+ISSS, сентябрь 2009 г.2005, стр. 69-74

[20] Д. Денсмор, Р. Пассероне, А. Санджованни-Винсентелли, «Таксономия на основе платформы для проектирования ESL», IEEE Design and Test of Computers, vol. 23, нет. 5, стр. 359-374, 2006

[21] E. Vaumorin, M. Palus, F. Clermidy, J. Martin: «Инструмент проектирования SPIRIT IP-XACT Controlled ESL, применяемый к платформе «сеть-на-чипе», Статьи по дизайну и повторному использованию, http://www.design-reuse.com/articles/18613/ip-xact-esl-noc.html

[22] D. Lattard, E. Beigne, F.Клемиди, Ю. Дюран, Р. Лемер, П. Виве, Ф. Беренс, «Реконфигурируемая платформа основной полосы частот на основе асинхронной сети на кристалле», IEEE Journal of Solid-State Circuits, Vol 43, Issue 1, Jan. 2008, стр. 223-235

[23] DT Phan Huy, R. Legouable, D. Kténas, L. Brunel, M. Assaad, «Downlink B3G MIMO OFDMA Link and System Level Performance», VTC Spring 2008. IEEE, стр. 1975-1979

[24] Ф. Клемиди, Р. Лемер, Ю. Тоннарт, X. Попон, Д. Кнетас, «Открытая и реконфигурируемая платформа для телекоммуникаций 4G: концепции и применение», 12-я конференция Euromicro по цифровым технологиям. System Design (DSD’2009), 27-29 августа 2009, Патры, будет опубликовано.

[25] X. Герен, К. Поповичи, В. Юссеф, Ф. Руссо, А.А. Джеррая, «Гибкое создание прикладного программного обеспечения для гетерогенной многопроцессорной системы на кристалле», COMPSAC (1) 2007, стр. 279-286

[26] Г. Ширнер, Р. Домер, А. Герстлауэр, «Высокий уровень разработка, моделирование и автоматическое создание аппаратно-зависимого программного обеспечения», «Принципы и практика аппаратно-зависимого программного обеспечения», Springer 2009, глава 8, стр. 203-231

аппаратных интерфейсов | СпрингерЛинк

Действия

‘)
var buybox = документ. querySelector(«[data-id=id_»+ метка времени +»]»).parentNode

;[].slice.call(buybox.querySelectorAll(«.вариант-покупки»)).forEach(initCollapsibles)

функция initCollapsibles(подписка, индекс) {
var toggle = подписка.querySelector(«.цена-варианта-покупки»)
подписка.classList.remove(«расширенный»)
var form = подписка.querySelector(«.форма-варианта-покупки»)

если (форма) {
var formAction = форма.получить атрибут («действие»)
form.setAttribute(«действие», formAction.replace(«/checkout», «/cart»))
document.querySelector(«#ecommerce-scripts»).addEventListener(«load», bindModal(form, formAction, timestamp, index), false)
}

var priceInfo = подписка.querySelector(«.Информация о цене»)
var PurchaseOption = toggle. parentElement

если (переключить && форма && priceInfo) {
переключать.setAttribute(«роль», «кнопка»)
toggle.setAttribute(«tabindex», «0»)

toggle.addEventListener («щелчок», функция (событие) {
var expand = toggle.getAttribute(«aria-expanded») === «true» || ложный
toggle.setAttribute(«aria-expanded», !expanded)
form.hidden = расширенный
если (! расширено) {
покупкаВариант.classList.add («расширенный»)
} еще {
покупкаOption.classList.remove(«расширенный»)
}
priceInfo.hidden = расширенный
}, ложный)
}
}

функция bindModal (форма, formAction, метка времени, индекс) {
var weHasBrowserSupport = window. fetch && Array.from

функция возврата () {
var Buybox = EcommScripts ? EcommScripts.Ящик для покупок: ноль
var Modal = EcommScripts ? EcommScripts.Modal : ноль

if (weHasBrowserSupport && Buybox && Modal) {
var modalID = «ecomm-modal_» + метка времени + «_» + индекс

var modal = новый модальный (modalID)
modal.domEl.addEventListener («закрыть», закрыть)
функция закрыть () {
форма.querySelector(«кнопка[тип=отправить]»).фокус()
}

форма.setAttribute(
«действие»,
formAction.replace(«/checkout», «/cart?messageOnly=1»)
)

form. addEventListener(
«Отправить»,
Buybox.interceptFormSubmit(
Буйбокс.fetchFormAction(окно.fetch),
Buybox.triggerModalAfterAddToCartSuccess(модальный),
консоль.лог,
),
ложный
)

document.body.appendChild(modal.domEl)
}
}
}

функция initKeyControls() {
документ.addEventListener(«keydown», функция (событие) {
if (document.activeElement.classList.contains(«цена-варианта-покупки») && (event.code === «Пробел» || event.code === «Enter»)) {
если (document.activeElement) {
событие. preventDefault()
документ.activeElement.click()
}
}
}, ложный)
}

функция InitialStateOpen() {
var buyboxWidth = buybox.смещениеШирина
;[].slice.call(buybox.querySelectorAll(«.опция покупки»)).forEach(функция (опция, индекс) {
var toggle = option.querySelector(«.цена-варианта-покупки»)
var form = option.querySelector(«.форма-варианта-покупки»)
var priceInfo = option.querySelector(«.Информация о цене»)
если (buyboxWidth > 480) {
переключить.щелчок()
} еще {
если (индекс === 0) {
переключать.щелчок()
} еще {
toggle. setAttribute («ария-расширенная», «ложь»)
form.hidden = «скрытый»
priceInfo.hidden = «скрытый»
}
}
})
}

начальное состояниеОткрыть()

если (window.buyboxInitialized) вернуть
window.buyboxInitialized = истина

initKeyControls()
})()

Аппаратные интерфейсы

— SEA

Следующие интерфейсные карты работают с системой сбора данных M300/M200.Система сбора данных M300 также поддерживает другие интерфейсные карты от разных производителей. Справочник по типам сбора данных содержит полный список поддерживаемых типов сбора данных. В таблице платы показаны все различные поддерживаемые типы интерфейсов.

Особенности Стандарт

• 16 Дифференциальные входные каналы.
• Разрешение 16 бит.
• Время преобразования 20 мкс.
• Дифференциальный усилитель инструментального класса на канал.
• 1, 2, 4 и 8 усиления.
• Аналого-цифровое преобразование, выполненное удаленно с объединительной платы,
  нет интерфейса часов.
• узла A/D могут быть расположены удаленно от системы M300/M200 (до 100 м).
• 9 — 36 В постоянного тока, 1 А.
• Ширина 8,4 дюйма, высота 1,7 дюйма, глубина 8 дюймов.

Серый спектрометр ISA 2D

Характеристики

• Все необходимые сигналы датчика предоставлены для одного датчика Грея 2D.
• 100% совместимость с датчиком PMS.

90 133 Размеры по осям X и/или Y для каждой частицы.

• 16-битный тракт данных для максимальной скорости передачи данных.
• Режим запроса передает 32 бита за один цикл прямого доступа к памяти для минимального воздействия на ЦП.
• Встроенный тактовый генератор истинной воздушной скорости (от 15 Гц до 6,0 МГц).
• Часы истекшего времени с разрешением 0,25 мкс, 2,5 мкс или 25 мкс.
• Прошедшее время (от включения до полного) измерено до 29 часов с разрешением 25 мкс.
• Время, прошедшее с начала изображения (32 бита).
• Прошедшее время с начала буфера (32 бита).
• Пройденное расстояние.
• Общее количество минимальных, средних и максимальных пикселей для каждой частицы.
• Суммарная площадь минимальной, средней и максимальной тени для каждой частицы.
• Буфер изображения получен за 5,2 мс (скорость сдвига битов 2 МГц, изображение 64 x 64 пикселей).
• Однослотовый 16-битный полноразмерный интерфейс ISA.
• Порт вывода состояния диагностики.
• До трех интерфейсов на систему.
• Настраиваемые каналы прямого доступа к памяти (5, 6, 7).
• Настраиваемые каналы IRQ (10, 11, 12).
• Настраивается для минимального количества срезов на изображение.
• Настраивается для минимального количества пустых срезов между изображениями.
• Возможность хранения данных зонда.

Предоставляется

• спектров размера в реальном времени
  386, 486 и Pentium совместимы.
• Скорость сдвига битов при выгрузке регулируется в диапазоне от 2 МГц до 0,125 МГц.
• Счетчик срезов частиц (16 бит).

Интерфейс монохроматического 2D-спектрометра

Характеристики

• Все необходимые сигналы датчика предоставлены для одного датчика 2D Mono.
• 100% совместимость с датчиком PMS.
• Путь данных шириной 16 бит для
  максимальная скорость передачи данных.
• Режим запроса передает 32-битный фрагмент, в
  один цикл прямого доступа к памяти с минимальным воздействием на ЦП.
• Встроенная истинная скорость воздуха
  тактовый генератор.
• Прошедшее время (от включения до полного состояния), измеренное до 29 часов
  с разрешением 25 мкс.
• Пройденное расстояние (рука до упора).
• Нормальная и закрытая Тень
  ИЛИ при условии.
• Данные по хранению зонда.
• Представлены спектры размера в реальном времени.
• Получен буфер изображения
  за 23 мс (скорость сдвига битов 2 МГц).
• Настраиваемые каналы прямого доступа к памяти (5, 6, 7).

Характеристики

• Использованы все 255 меток данных ARINC.
• Счетчик обновлений поддерживается
  отдельно для каждой этикетки ARINC.
• Самое последнее значение данных для каждого
  метка сохраняется в памяти для доступа системой M300/M200.
• Включает
  гнездо для 4 синхро/цифровых преобразователей для таких входов, как
  курс, шаг, крен, пеленг и т. д.

Модель

• для данных ARINC 429.
• 2 порта Rx, 1 порт Tx

Интерфейс ARINC 429 (половина размера)

Характеристики

• Используются все 255 меток данных ARINC.
• Счетчик обновлений поддерживается
  отдельно для каждой этикетки ARINC.
• Самое последнее значение данных для каждого
  метка сохраняется в памяти для доступа системой M300/M200.

Модель

• для данных ARINC 429.
• 4 порта Rx, 2 порта Tx
• Половинный размер.

Характеристики

• Использованы все 255 меток данных ARINC.
• Счетчик обновлений поддерживается
  отдельно для каждой этикетки ARINC.
• Самое последнее значение данных для каждого
  метка сохраняется в памяти для доступа системой M300/M200.
• Включает
  гнездо для 4 синхро/цифровых преобразователей для таких входов, как
  курс, шаг, крен, пеленг и т. д.

Модель

• для данных ARINC 565.

Интерфейс спектрометра облачных аэрозольных осадков

Характеристики

• Все необходимые сигналы датчиков предоставлены для одного датчика CAPS.
• 100% совместимость с датчиком CAPS.
• Путь данных шириной 16 бит для
  максимальная скорость передачи данных.
• Режим запроса передает 32-битный фрагмент, в
  один цикл прямого доступа к памяти с минимальным воздействием на ЦП.
• Каналы изображения CIP и последовательных данных CIP.
• Канал последовательных данных CAS/CDP.
• Представлены спектры размера в реальном времени.
• Настраиваемые каналы прямого доступа к памяти (5, 6, 7).

Характеристики

• 24 счетчика каналов.
• 32-битные счетчики.
• Режим счета для переднего фронта, заднего фронта и обоих фронтов.
• Порог срабатывания ЦАП (от 0,0 до 3,3 В).
• Минимальная длительность импульса 20 нс.
• Ограничение по одному фронту 5 МГц.
• Интерфейс шины ISA (16 бит).
• Другие конфигурации возможны при обновлении прошивки.

Расширенный интерфейс FSSP/ASASP/1D

Характеристики оборудования

• 16-битный тракт данных с автоматическим аппаратным подсчетом
  очистка для значительного сокращения времени сбора данных.
• 100% совместимость с датчиком PMS.
• 16/32/64/128/256 Размер каналов,
  32 бита на каждый канал.
• 1 Канал общего счета, 32 бита.
• 1 Суммарный стробоскопический канал,
  32 бита.
• 1 Канал активности, 16 бит.
• 2 запасных канала, 32 бита
  каждый канал.
• Данные по хранению зонда.
• Встроенная 256-канальная частица
  космический монитор (PSM).
• Ширина корзины монитора интервалов регулируется от 0,25
  мкс до 10 мс каждый.
• 1 опорный канал и 7 вспомогательных аналого-цифровых преобразователей,
  12 бит, ±5
  mv до ±10 вольт с помощью перемычки.

Доступна версия

• CAMAC.
• Время сбора данных 1,5 мкс
  для каждого размера канала всего 384 мкс для всех размеров 256
  каналов (максимум 2,6 кГц).
  Общее время сбора данных 780 мкс для полностью активной установки (256
  каналов размера, 256 каналов стробоскопического интервала (PSM активен), все вспомогательные
  счетчики активны).
• Регистр управления для команды диапазона (FSSP) и насоса
  контроля (АСАСП и ПСАСП).
• Данные по ведению домашнего хозяйства, восемь каналов.
• Восемь аналоговых входов
  дифференциальные каналы (с защитой входа). Опорное напряжение
  плюс семь служебных аналоговых каналов (12 бит, ±5 В
  или ±10 В выбирается перемычкой, коэффициент усиления 1, 10 или 100 выбирается
  перемычкой, время сбора данных 40 мкс на канал).
• Интегрированный
  Системный интерфейс для автономной работы (настраивается пользователем).
• Одноместный
  слот 16-битный полноразмерный интерфейс ISA.
• До восьми интерфейсов на
  система.
• Совместимость с 386, 486 и PENTIUM.

Функции программного обеспечения

• Размерные спектры в реальном времени, концентрации, объемы для нескольких
  зонды.
• Полностью конфигурируемый командный байт для датчика 1D.
• Количество
  размер каналов настраивается в настройках платы.
• Количество интервалов стробирования
  канал настраивается в таблице сбора данных (PSM может быть отключен).

Базовый интерфейс FSSP/ASASP/1D

Характеристики

• 100% совместимость с датчиком PMS.
• 15 каналов размера, 16 бит на канал.
• 1 Канал общего счета, 16 бит.
• 1 Полный строб-канал, 16 бит.
• 1 Канал активности, 16 бит.
• 2 резервных канала, по 16 бит на каждый канал.
• Опорный аналого-цифровой канал, 8 бит, 0–10 вольт.
• Общее время сбора данных 260 мкс для всех 21 канала.

Доступна версия

• CAMAC.

Базовый интерфейс FSSP/ASASP/1D (половина размера)

Характеристики

• 100% совместимость с датчиком PMS.
• 15 каналов размера, 16 бит на канал.
• 1 Канал общего счета, 16 бит.
• 1 Полный строб-канал, 16 бит.
• 1 Канал активности, 16 бит.
• 2 резервных канала, по 16 бит на каждый канал.
• Опорный аналого-цифровой канал, 8 бит, 0–10 вольт.
• Общее время сбора данных 260 мкс для всех 21 канала.
• Половинный размер.

Характеристики

• Включает один чип синхронизации для направления.
• Этот интерфейс может быть интерфейсом ISA ARINC 429 или ISA ARINC 565 с оборудованием только для синхронизации (без поддержки ARINC).

Характеристики

• Используются все 255 меток данных ARINC.
• Счетчик обновлений поддерживается
  отдельно для каждой этикетки ARINC.
• Самое последнее значение данных для каждого
  метка сохраняется в памяти для доступа системой M300/M200.

Модель

• для данных ARINC 429.
• 4 порта Rx, 2 порта Tx
• Шина PC104.

Характеристики

• Требуется для подключения системы аналогового ввода SEA к системе M300/M200.
• Требуется для подключения контроллера мультиплексора давления SEA
  к системе M200/M300.
• Возможность подключения до 256 приборов
  к M300/M200 по цифровому кабелю.
• Секция встроенной системной платы (используйте либо системную плату, либо интерфейс SEA Bus для M300/M200).
• Обеспечивает системные прерывания (IRQ 3) для режима сбора данных в реальном времени.
• Высокоточный кристалл.
• Счетчики задержки и длительности IRQ.