Начинаем Эксперименты С Интерфейсом Usb 3.0 Через Контроллер Семейства Fx3 От Cypress.

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

Мы ознакомились со способами доступа к основным компонентам комплекса, научились писать и отлаживать на нем программы для центрального процессора, локально используя либо Linux, либо Windows. Мы научились разрабатывать прошивки для ПЛИС, а также примерно освоили типовой цикл их разработки (написание кода, моделирование, запуск на железе).

Похоже, вот и все.

Но здесь мне пришлось осваивать работу с шиной USB 3.0 через контроллер семейства FX3 от Cypress. Пока воспоминания свежи, я решил задокументировать детали процесса, так как если делать все по описаниям компании, то можно либо ничего не получить, либо получить не совсем оптимальную систему.

И снова вышел целый блок статей.

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

Также создадим базовую прошивку для ПЛИС.



Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.



1 Зачем все это

В ходе практической работы с USB-анализатором я столкнулся с рядом трудностей.

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

Более того, малейшая модификация скрипта увеличивала время передачи данных.

Иногда – дважды.

И получилось, скажем, десять минут вместо пяти.

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

Пришлось отказаться от передачи больших объемов данных через JTAG. Как уже отмечалось в одна из статей цикла , передача данных через выбранный нами чип FTDI по протоколу FT245-SYNC требует потребления внутренней оперативной памяти ПЛИС, а ее и так не хватает. А мне вообще эта микросхема в реальном использовании не понравилась.

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

Данная задача была успешно решена, что позволило завершить разработку комплекса в разумные сроки.

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

Итак, хочу заменить мост. Но для чего? И тут всплывает «Во-вторых».

А во-вторых, когда я играл в USB-анализатор, память на плате быстро заполнялась.

Как давно мне хватало шестнадцати (даже пятнадцати с половиной) килобайт в БКшке? А тут, смотрите, 32 мегабайта мало.

Но оно есть то, что есть (правда, чтобы не бегать много по медленному JTAG, я старался делать буфер 2, 4, максимум 8 мегабайт).

И мы решили перейти на шину USB3. Его производительность такова, что вполне можно гонять поток с ULPI на ПК, не сохраняя его в промежуточный буфер оперативной памяти.

Соответственно, ПК может хранить данные гораздо больших объемов, чем 32М.

Отлично.

Меняем USB2 на USB3, но какой мост использовать для этой шины? Мой знакомый из дружественной организации провел масштабное исследование мостов FTDI серии FT600 и получил небольшие брызги, что в конечном итоге не позволило им работать в целом.

Анализ форумов показал, что там всё очень критично, когда дело касается настройки ГРМ.

Необходимо указать ряд ограничений для компилятора.

И люди до сих пор ищут, как они должны выглядеть в идеале.

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

Сегодня мы говорим только об оборудовании.



2 оборудования



2.1 Плата с контроллером FX3

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

Но есть и более дружелюбная раскладка: CYUSB3KIT-003. Вот ссылка на сайт производителя: CYUSB3KIT-003 Комплект EZ-USB FX3 SuperSpeed Explorer (cypress.com) Имеет обычные двухрядные разъемы с шагом 2,54 мм.

Фото с сайта:

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

На этой же странице есть ссылка на образ диска, содержащий среду разработки и SDK. Данный образ диска скачивается без регистрации.

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

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

AN65974 – Проектирование с использованием ведомого интерфейса FIFO EZ-USB FX3 (cypress.com) На вид - красота! Правда, если бы все было так, как кажется, статьи бы не было.

Но все равно есть над чем потанцевать.



2.2 Плата ПЛИС

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

Имеется ПЛИС EP4CE10F17C8 семейства Cyclone IV. Этот модуль я купил очень давно, когда только собирался серьезно заняться анализатором.

Сегодня взял бы десятый Циклон, но это то, что есть в наличии.



Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.



2.3 Подключение

В документе 001-65974_AN65974_Designing_with_the_EZ-USB_FX3_Slave_FIFO_Interface.pdf Есть замечательная таблица 2, в которой показано, как подключить систему в восьми, шестнадцати или тридцатидвухбитном режиме к ПЛИС.

Для текущей версии выбран шестнадцатибитный режим.

При разработке схемы поначалу возникли небольшие трудности с чтением этой таблицы.

Давайте позаботимся о том, чтобы их больше ни у кого не было.

Вот пару строк оттуда:

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

Их содержимое следует читать следующим образом: Сигнал CS — это ножка GPIO17 контроллера.

На шелкографии макетной платы он обозначен как CTL0. Сигнал SLWR — это ветвь GPIO18; на шелкографии модуля он обозначен как CTL1. Ну и так далее.

Смотрим на сигналы в столбце выбранной разрядности, затем переводим взгляд влево и смотрим, где они соединяются.

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

Именно в таких терминах сигналы обозначаются на макетной схеме и на шелкографии.

Вот какая красивая шелкография, дизайнер просто великолепный!

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

На частоте 100 МГц соединение плат проводами крайне противопоказано.

Только оплата! Не вижу смысла представлять в статье схему нашего соединительного модуля в виде чертежа, но на всякий случай приложу ее и файл с проводкой к раздаточным материалам, вдруг кому-то захочется повторить эксперименты именно с этим железом.

А в целом получилось вот такая кувалда:

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

Как видно по фото, на рукоятке кувалды также имеется модуль WaveShare ULPI. Те, кто давно читает серию, уже догадались, что это следующая версия USB-анализатора.

Поэтому сегодня мы будем перекачивать данные с ПЛИС на ПК и только в этом направлении.

Сегодня нас не интересует обратный поток.



3 Первое знакомство с прошивкой контроллера



3.1 Выбираем, что будем прошивать

На самом деле, судя по всему, с прошивкой контроллера все должно быть в порядке.

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

Теоретически можно взять файл Fx3SlaveFifoSync.img и просто «прошить» его в макетную плату.

Все бы ничего, но из исходников понятно, что это 32-битная сборка, а наше оборудование 16-битное.



Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

То же самое и с текстом.

  
  
   

/* 16/32 bit GPIF Configuration select */ /* Set CY_FX_SLFIFO_GPIF_16_32BIT_CONF_SELECT = 0 for 16 bit GPIF data bus. * Set CY_FX_SLFIFO_GPIF_16_32BIT_CONF_SELECT = 1 for 32 bit GPIF data bus. */ #define CY_FX_SLFIFO_GPIF_16_32BIT_CONF_SELECT (1)

Что может быть проще? Устанавливаем среду разработки, импортируем туда проект, собираем.

Получаем ошибку «Нечего собирать».

Смотрим и видим, что элементы ToolChain не обнаружены (кстати, кто подскажет, как это назвать по ГОСТ 2.105, то есть не «toolchain», а больше по-русски, но чтобы не задеть уши?).

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

Получаем ошибки в заголовках.

Немного поиска в Google и становится ясно, что эти исходники делались для старой версии SDK. Отлично.

Давайте посмотрим на примеры, включенные в SDK. И мы обнаруживаем, что пример Программные файлы (x86)\Cypress\EZ-USB FX3 SDK\1.3\firmware\slavefifo_examples\slfifosync – современный аналог примера из Application Note. Ура? Подождите, приключения только начинаются.

Но так или иначе, мы убедились, что этот проект изначально рассчитан на 16-битный обмен, и успешно его собрали.

То есть пока что мы нашли хороший пример и скомпилировали его без каких-либо правок (когда черновик статьи уже был загружен на Хабр, оказалось, что у этого примера есть серьезный недостаток, но мы посмотрим, как найти и исправим это в отдельной статье).

Позвольте мне также рассказать вам, как добавить его в контроллер.



3.2 Как загрузить полученную «прошивку» в контроллер

Чтобы загрузить проект на макетную плату, нужно заставить контроллер запустить загрузчик.

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



Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

Итак, устанавливаем эту перемычку, после чего либо передергиваем питание, либо нажимаем кнопку Reset (она находится рядом с разъемом USB 3.0).

Все.

Контроллер теперь находится в режиме загрузки.

Запускаем программу Центр управления, которая была установлена вместе со средой разработки.

В нем выбираем контроллер в дереве (мое дерево на экране состоит из корня одного устройства).



Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

И выберите пункт меню Program-> FX3-> RAM, чтобы запустить код в ОЗУ, или Program-> FX3-> I2C EEPROM, чтобы записать код в ПЗУ.

Да, я не ошибся.

Именно I2C EEPROM. Не СПИ.

Так и должно быть!

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

При экспериментах лучше просто заливать в оперативку.

Так быстрее.

И впереди у нас много экспериментов.

Потом, когда все будет отлажено, тогда можно будет перейти на прошивку в ПЗУ.

Чтобы код запустился из ПЗУ, нужно будет снять перемычку J4. При загрузке в оперативную память оборудование трогать не придется; код запустится сам.

Отлично.

Первоначальная прошивка для FX3 готова и даже загружена в контроллер.

В дереве появилось совсем другое устройство с двумя конечными точками типа Bulk:

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

Это наша система.

Но чтобы начать с ним работать, нам необходимо сделать «прошивку» для ПЛИС.

Давайте начнем и прочтем документацию.

И вот нас ждут первые улучшения кода контроллера.



4 Насколько корректна типовая прошивка ПЛИС из примера?



4.1 Недостоверные результаты обследования

Разработчики из Cypress заботливо включили примеры «прошивок» для Xilinx и Altera, причем сразу на двух языках — VHDL и Verilog. Красота! Но приступив к изучению файла \AN65974\Исходные файлы FPGA\fx3_slaveFIFO2b_altera\rtl_verilog\slaveFIFO2b_streamIN.v , я поняла, что не всё понимаю.

Меня смутила необходимость пулемета и вообще флагов.

Машина в документе показана так:

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

Но его суть описана недостаточно ясно.

Назначение флагов в исходном коде описано следующим образом:

input flaga, //full flag input flagb, //partial full flag input flagc, //empty flag input flagd, //empty partial flag

Что-то об этом есть в документе, но это очень запутанно.

Логика мне вообще не понятна.

При этом при описании в документе упоминаются функции CyU3PGpifSocketConfigure() , которые на самом деле используются в примере, включенном в AppNote. Который не собирается.

И они отсутствуют в текущем примере.

Почему их там нет? Откройте дизайн GPIF, который поставляется с AppNote. Мы видим там четыре флага (пара Ready и Watermark для каналов 0 и 3):

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

И вот - тот самый дизайн из проекта, который собирается.

Упс! И флагов всего два! Причём по сути они равнозначны — Готов к выбранному каналу (выбранный канал — тот, номер которого задаётся нашей ПЛИС на адресной шине).



Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

Конечно, эксперты, читающие эти строки, уже ухмыляются.

Мол, я не разобрался в контроллере, но всё равно пишу туда статьи.

Но на самом деле я это понял, я просто нагнетаю ситуацию.

Однако в целом беда в том, что я вообще-то не собирался (и не собираюсь) становиться гуру FX3. Я имел дело с FX2LP 12 лет назад в течение трех месяцев на постоянной основе и знаю это досконально.

Процесс изучения программируемой логики, встроенной в семейство PSoC, я представил в виде двух серий статей: авторской и переведенной.

Но тут нет времени, руководство срочно требует преодолеть проблемы синтезированного RISC-V, все силы брошены туда.

Плюс – я уже старый и медлительный.

Если кому интересно, вот под катом список тех самых оригинальных статей.

Управление RGB-светодиодами через UDB-микроконтроллер PSoC от Cypress Использование Cypress PSoC UDB для уменьшения прерываний работы 3D-принтера Часть 2. Использование UDB Cypress PSoC для уменьшения прерываний работы 3D-принтера ДМА: мифы и реальность Использование инструмента настройки Datapath Особенности формирования тактовой частоты в PSoC 5LP Источники вдохновения при разработке для UDB А вот переводы Часть 1. Введение.

ПЛД.

Часть 2. Datapath. Часть 3. Datapath FIFO. Часть 4. Datapath ALU. Часть 5. Datapath. Полезные мелочи.

Часть 6. Модуль управления и состояния.

Часть 7. Модуль управления часами и сбросом.

Часть 8. Адресация UDB. То есть я просто хотел взять типовой пример и заставить его выполнять типовые функции! У меня нет времени вникать во все тонкости и проводить десятки и сотни экспериментов! Я просто хочу взять готовый и заставить его решать мои частные задачи по освоению совершенно разных вещей.

Не хочу тратить время и нервы на перенос кусков из старых исходников в новые.

Не хочу Не хочу понять, куда вставлять эти функции, понять, для чего нужна эта хитрая машинка в 4 состояния, понять, понять, понять.

Но вы должны кое-что понять.

Давайте прочитаем документ, прикрепленный к AppNote. И там мы видим удивительные вещи.



4.2 Удивительная задержка

В документе есть очень подробное описание флагов.

И это говорит об очень интересной задержке.

Эта задержка также мигрирует от документа к документу.

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

Это задержка.



Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

Рисунок очень общий.

У него тоже есть два флага, но это два разных флага.

В коде используются флаги FLAGA и FLAGB, запрограммированные для функций Full и Watermark одного канала, а на этом рисунке (в документе, поясняющем код) - FLAGA и FLAGB как флаги Full для двух разных каналов, номера которых заданы.

на адресной шине.

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

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

Кто-то спросит, а зачем нам после трёх тактов знать, что буфер уже давно переполнен? Я просто повторю его вопрос.

Я не знаю ответа на этот вопрос.

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

Этот флаг можно запрограммировать на постановку на охрану, когда в буфере осталось N свободных флагов.

элементы .

И потом, с поправкой на задержку, вылетит как раз тогда, когда буфер заполнится (хотя концепция « элемент "Забавно: они 32-битные, для 16-битных слов нужно заданное значение делить на 2, а латентность у нас нечетная, но это мы изучим в следующей статье).

На самом деле автомат в AppNote просто ждет по очереди, чтобы флажки появились.

Действительно, кто вам мешает объединить их по «Я» Но суть не в том, что у нас есть два варианта: Или откройте GPIF II Designer и откройте в нем проект. Программные файлы (x86)\Cypress\EZ-USB FX3 SDK\1.3\library\sync_slave_fifo_2bit.cydsn\sync_slave_fifo_2bit.cyfx и изменить назначение флагов.

Я сделал это:

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

Затем создайте файл заголовка на C, выбрав «Сборка» -> «Создать проект»:

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.

И сравниваем содержимое полученного файла и рабочего файла cyfxgpif_syncsf.h почини это.

Или поверьте мне на слово и просто возьмите этот файл.

cyfxgpif_syncsf.h , который я раздам в раздаточном материале.

Все что нужно в нем я уже сделал.

Поэтому я и сказал, что пока проще заливать «прошивку» не в EEPROM, а в RAM. Это не последнее изменение кода.

Уточним его еще несколько раз и загрузим результаты в контроллер.



5 Проектирование системы для FPGA



5.1 Общий вид

Любой, кто читал серию о комплексе «Редд», знает, что все системы в его рамках выполнены на базе процессорных систем.

Советую другим посмотреть основы идеологии в статье «Разработка простейшей прошивки для ПЛИС, установленной в Redd, и отладка на примере теста памяти» (самая важная особенность заключается в том, что наша система представляет собой блок верхнего уровня, вставленный без каких-либо слоев на машинном языке).

Основные принципы разработки собственных модулей для системы описаны в статье " Разработка собственного ядра для интеграции в процессорную систему на базе FPGA. ", мы будем работать с автобусом АВАЛОН-СТ, о котором вы можете узнать из статьи" Первые эксперименты по использованию потокового протокола на примере связи ЦП и процессора в ПЛИС комплекса Redd ".

Сегодняшняя система будет очень и очень спартанской:

Начинаем эксперименты с интерфейсом USB 3.0 через контроллер семейства FX3 от Cypress.



5.2 ФАПЧ

Примеры от Cypress работают на частоте 100 МГц.

Почему бы нам не попробовать и эту частоту? Но ULPI выводит данные на частоте 60 МГц.

В систему добавлен блок ФАПЧ для преобразования частот. Мы уже достаточно много с ним работали, поэтому детали его настройки показывать нет смысла.

Кто забыл подробности, может посмотреть статью " Ускорение программы на синтезированном процессоре комплекса Redd без оптимизации: замена тактового генератора ", только сегодня входная частота не 50, а 60 МГц, и фазовый сдвиг не нужен.

Частота 60 МГц (фиолетовая линия) синхронизирует источник сигнала и входной порт FIFO. Частота 100 МГц синхронизирует выходной порт FIFO и интерфейсный блок, работающий с FX3.

5.3 Источник данных

Источником сигнала является таймер, с которым мы уже встречались в статье « Практическая работа с ПЛИС, входящими в комплект Redd. Осваиваем DMA для шины Авалон-СТ и переключение между шинами Авалон-ММ ".

Он гонит постоянный поток данных.

Если данные были потеряны, мы заметим обрыв потока.

Однако сегодня я немного изменил его работу.

Во-первых, мы гоняем 16-битный поток данных, поэтому таймер стал 16-битный.

А во-вторых, нам сегодня важно, чтобы таймер работал на изначально пустой очереди буфера FIIFO. Поэтому я добавил правило: если получатель данных от таймера не готов принять поток, то.

после возобновления готовности таймер ждет 8192 такта.

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

Переполнить очередь в этот момент - пустяк.

Поэтому будем ждать.

Через 8 килоциклов очередь с большой долей вероятности появится, если совсем не пустым, то хотя бы будь почти пустым.

Итак, вот текст, реализующий такой модуль.

См.

текст.

module Timer_ST ( input clk, input reset,

Теги: #Программирование микроконтроллеров #Компьютерное оборудование #Системное программирование #FPGA #FPGA #FPGA #FPGA #USB-анализатор #Redd #Контроллер FX3 #FPGA Altera

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.