Да, именно для доступа к управляющим регистрам DMA. Именно к этим регистрам я обращался, чтобы спровоцировать разрывы в работе канала Данные_DMA->шина->буфер. Я надеялся, что иногда шина будет занята прокачкой регистр_DMA->Nios II (поэтому стрелку и в направлении к Nios II надо добавить). Но разрывов в потоке данных не было! Тогда я стал занимать шину тактами записи в PIO. Но и это не испортило картины!!!
Буфер доступен на запись и чтение. DMA туда пишет, затем — Nios II своим JTAG блоком мне спокойно всё перекидывает в отладочное окно. Я разношу эти вещи по времени чисто организационным путём.
То есть, добавляем двунаправленную стрелку доступа к регистрам DMA, делаем двунаправленными стрелки для Buffer и Nios II. Получаем на Вашей схеме то, что задумано.
Когда DMA гонит данные в Buffer, в это время другие устройства на шине могут общаться друг с другом, не мешая процессу. Выяснено опытным путём. Если начать обращения от других устройств к Buffer — там уже начинаются конфликты за шину. У нас такое другое устройство, разумеется, одно — Nios II.
Ну так у Avalon-MM блока шина адреса же работает как шина только для внутренних регистров устройства, то есть сам Avalon-MM не знает своего адреса на шине, а значит же кто то должен этим рулить
Чип Селект же в AVALON-MM устройство приходит. Ну, точнее, персональные RE/WE. На классических шинах этого вполне было бы достаточно. Здесь же, судя по полученным результатам, даже данные коммутируются. И это — здорово (пока ресурсов хватает, разумеется).
Ну, наверное, обернуть всё в класс с универсальным интерфейсом и сделать так, чтобы всё собиралось по #ifdef, в зависимости от ОС. Пользователи класса не будут знать, какой версией пользуются, а сам класс будет собираться — под конкретную ОС.
Или сделать библиотеку с универсальным интерфейсом. Собрать версии библиотеки под каждую ОС и подключать их к проектам. А пользователи, опять же, не будут знать, к кому обращаются. Главное — чтобы интерфейс был универсальным.
Но это — уже выходит за рамки как статьи, так и цикла.
Не совсем взаимо заменяемые. Они совершенно заменяемые в одну сторону и заменяемые с некоторыми усилиями — в другую.
JTAG канал встроен в ПЛИС от её рождения. Описанная тут функциональность — встроена в среду разработки. Как видно, в рамках данной статьи мы не написали ни одной строчки своего кода ни для ПЛИС, ни для ЭВМ. Нам хватило всего встроенного.
FT245-SYNC добавлен в комплекс Redd потому, что мы его выбрали. Мы заложили в схему этого комплекса чип FT2232H. Поэтому чтобы его поддерживать, в статьях, на которые я дал ссылки выше, я сначала проектирую автомат, затем — делаю его реализацию на языке Verilog, затем — оборачиваю его в компонент, затем — вставляю в систему, затем — добавляю немного штатной обвязки, затем — связываю всё это. И в итоге — у меня получается FIFO, к которому имеет доступ только программа для процессора NIOS II. Но так же я могу написать мастера, имеющего доступ к Memory Mapped шине. Но лично я — не буду этого делать. Сил много потрачу. Проще ограничиться FIFO и брать оттуда данные программно, либо программно же класть их туда.
Как видите, технически всё возможно, но реально всё похоже на анекдот:
— Доктор, я после операции буду играть на скрипке?
— Конечно будете!
— Спасибо, доктор, а то я раньше не умел.
Вот если приложить массу усилий, то FT245-SYNC к шине AVALON-MM приладить можно (надо долго учиться играть на скрипке). Зато всё будет идеально. Описанную же в этой статье функциональность сделала для нас «мать-природа» в лице инженеров Альтеры. Но она — смешная по производительности. Зато не надо мучиться.
То есть, технически — всё заменяемо. Но трудозатраты — не сопоставимы. Поэтому я не скажу, что всё взаимо заменяемо. Хотя бы потому, что одна из функций — врождённая в систему, а вторая — нет.
Для Windows есть пример в MSDN. Ищем описнаие _popen, а оттуда есть ссылка.
Но в рамках цикла статей важнее Linux (Debian) вариант. Потому что система запускается на ПЛИС, физически подключённой к ЭВМ с Линуксом. Значит, управляющий код на той ЭВМ и должен исполняться. Так будет производительнее всего.
Не совсем. Если надо быстро прокачивать данные из ОЗУ, подключённого к ПЛИС (в планах следующих статей — сделать анализатор, который будет туда эти данные загонять на высокой скорости). то для этого в аппаратуру комплекса Redd заложен чип FT2232, работающий в режиме FT245-SYNC.
Но как было видно в статьях по ссылкам, данная функциональность несколько сложна в добавлении. Зато скоростная. Если же скорость обмена не критична (например, данных не очень много) — можно воспользоваться работой через JTAG канал, описанный в этой статье. Выигрываем в скорости разработки и в свободной памяти ПЛИС, проигрываем в скорости работы.
А дальше — каждый решает, что ему важнее в данный конкретный момент. Владея обоими методами, можно оптимизировать работу под каждый конкретный случай.
Мастер из процессорного ядра Nios II. Он был впервые применён ещё в самой первой статье цикла и дальше кочует из статьи в статью.
Не очень понятно, а почему вы здесь сравниваете FT245 и JTAG?
Протокол FT245-SYNC заложен, как штатный для сязи ПЛИС с центральным процессором Redd (реализован на чипе FT2232H). Работа с ним была рассмотрена ранее, тогда же сделаны замеры его скорости. Первое рассмотрение — во второй части тут, далее — тут.
Именно с Кейлом? С другими средами разработки проблем нет, но в рамках All-Hardware надо было учиться поддерживать все популярные среды, вот и разбирались со всеми…
Когда JLINK работает по сетке с удалённым сервером средствами Эклипсы и IAR, он не работает средствами Кейла при тех же условиях. Возможно, когда-нибудь я сделаю большую статью на эту тему, мы нашли даже наиболее вероятную причину… Виноваты потери пакетов в UDP. Просто я запускаю сервер на той же машине, что и компилятор — если обращаюсь к localhost — всё работает, если по локальному IP — уже сбои!!! И это в домашней сети при отсутствии других активных устройств и при связи с роутером по кабелю (в реальной конторской сетке — и подавно)! Это именно из Кейла, из других сред всё в порядке.
Причём мы пытались общаться с поддержкой как Segger, так и Кейла. Сделали для них подробное описание, сняли кино с показом, когда работает, когда — нет… Сеггеры сказали, что хоть у нас и подлинный адаптер, но эта модель не подразумевает поддержки. Кейлы сказали, что DLL для связи делали Сеггеры, так что они бы и рады, да ничего сделать не могут. Обращайтесь к Сеггерам.
А через туннельный сервер Сеггеровский — ещё веселей. Вот ответ поддержки Кейла:
But the tunnel server mode doesn't work. The reason is due to that the dialog «Options for Target — Debug — Settings» in uVision you cannot define the serial number of the J-Link, unlike the jlink command line utility by calling ip tunnel:. Thus, even uVision can connect to the segger server, but it cannot connect to your j-link, because serial number is missing.
Исследование велось для Кейла, а он с OpenOCD не дружит. В этом его главная проблема. Из сетевых он дружит с J-LINK, но по факту, работа по сети именно из Кейла с JLINK — абсолютно нестабильная. Постоянные сбои.
Но в первую очередь, Малину можно положить рядом с поделкой, с которой слишком круто оставлять настольную машину. Она маленькая, и цена у неё не такая кусачая (тем более, что по сусекам многие могут наскрести даже не одну валяющуюся без дела Малину).
Плюс иногда RDP подтормаживает. Понятно, что и отладка будет при тех же условиях не идеальной. Но разработка текста идёт дольше по времени, чем связь в процессе отладки.
В общем, RDP — лучше в целом, а этот подход — может пригодиться в особых случаях.
Отличная статья, спасибо!
Очень хороший обзор — и всё очень совпадает с тем, что вижу каждый день в работе.
Вы писали
Дизайн-центров с миллиардными (разумеется, в рублях) значениями выручки в России с десяток, ими успешно налажена кооперация как с зарубежными кремниевыми фабриками на нормах до 28-16 нм (в основном с той же TSMC)
А кого можно отнести к этому десятку? (правда интересны больше разработчики микропроцессоров и микроконтроллеров) — Миландр, Модуль, Байкал, Элвис, МЦСТ, GS Nanotech,… больше и не вспомнить… да и не у всех у них миллиарды даже в рублях
Для переходника USB-UART имеется стандарт CDC или полностью — Universal Serial Bus Class Definitions for Communications Devices. Его можно скачать с сайта usb.org. Примеры его реализации имеются под большинство контроллеров с функцией USB. Если этот пример реализовать — драйвер для его поддержки уже встроен хоть в Windows, хоть в Linux.
Ну, и программный интерфейс — классический, как для обычных UART. Какой бы физический чип ни стоял, какой бы драйвер его ни обслуживал. на PC интерфейс прикладного программиста для UART будет един.
Для переходников USB в I2C/SPI такого шикарного набора готовых решений для PC не наблюдается. А в основе комплекса Redd лежит именно PC.
Теперь насчёт Cypress. Они выпускают отладочные платы для своих контроллеров PSoC. У меня была большая серия статей про эти PSoC, там рассказывается про эти платы. На платах имеются отламываемые контроллеры, реализующие интерфейсы JTAG, UART, SPI, I2C. Соответственно, Cypress выпускает под них готовые драйверы и API. И были найдены «исходники» прошивки. То есть, мы имеем хоть что-то, готовое, отлаженное, где не надо проектировать всё от архитектуры через «прошивки» и драйверы до библиотек пользователя. Но в целом — там даже с лицензией не всё так хорошо. Да и распространённость — смешная.
Вот что-то в этом роде имелось в виду. Мосты FTDI — дорогие, зато обеспечивают полный набор давно отлаженных средств (железо, драйвер, библиотека). Плюс железо — с USB 2.0 HS, а не FS, как у многих контроллеров. Ну, и хоть какой, но всё-таки единый стиль API у всех библиотек FTDI — тоже подкупает. Поэтому в систему были добавлены именно они.
Когда связываете два последовательных порта, как показано на схеме (кроссом для теста), их signal grounds лучше тоже соединить — даже если это два порта одного устройства.
Дело в том, что это не просто два порта одного устройства, а два порта, реализованных в одном и том же чипе. И контакты — на одном и том же разъёме. Но даже если бы чипов было два на одной плате, то паянный контакт через широкую дорожку (а сегодня это физически — отдельный слой на плате) будет намного лучше, чем через провод и сопротивление минимум двух контактов на стыке «разъём-провод».
В управлении розетками было бы чуть лучше, если бы контроллер повторял посланный командный байт: сказали «A» — он и ответил «A», если услышал его. На остальное управление это не влияет, если вообще клиентская часть сделана с учётом реалий — зовёт tcflush(,TCIFLUSH) перед любой посылкой "?".
Достаточно посылать не «A», а «A?». Буфер USB FS — 64 байта, оба байта уйдут в одном и том же физическом пакете. И устройство пришлёт пакет с ответом из трёх байт, в которых на заведомо известной позиции будет стоять эхо. Можно даже посылать пакет вида «AbC?» — это тоже менее шестидесяти четырёх байт. И они тоже уйдут в одном USB пакете. Порт же виртуальный. При разработке протокола эти возможности были учтены.
В итоге каждый может посылать так, как сочтёт нужным. Лично мне нравится без эха. Но добавляем в посылаемую строку знак вопроса, который не даст никаких накладных расходов из-за особенностей протокола USB, получаем то, что нравится тем, кто любит ответы.
Ядро GXB — разумеется, штатное. Правда, эластичный буфер и декодер/кодер 8B/10B потом предпочёл сделать свои, так как встроенные в блок GXB дурили (сейчас уже не вспомню, как). На выходе из GXB (и моих довесков) получался поток данных и примитивов. Все автоматы, которые их обрабатывали и складывали в память (ну и изымали) — были написаны свои. Разумеется, с учётом поведения разных реальных дисков, у них у каждого свои привычки. Примитив CONT — убойная вещь, SAS без него — просто конфетка, а тут — намучился. Кто-то из дисков вставляет HOLD, кто-то нет, кто-то может вставить его за одно слово до конца потока, что всё рвёт и т.п. Давно дело было, в 2012-м. Тогда готовое стоило таких денег, что любые трудозатраты на своё, выходили дешевле. Это сейчас под Xilinx можно взять готовое SATA ядро бесплатно, написанное на LiteX или как там он правильно называется.
Не буду спорить. Но на всякий случай, отмечу, что я как-то всё в синхронном дизайне делаю, завязываюсь на то, чтобы подальше от рабочего фронта переключалось. Если в требуемую частоту уложились, то всё работает и без каких-либо трудностей. Оптимизаторы всё делают на ура. Я иногда даже смотрю, во что умялось всё (например, тут)
Но может, просто у меня задачи простые. Однако и цикл статей в тему, про аппаратуру, которая помогает в отладке и тестировании других больших проектов. Разработка под Redd — вторична и не должна приводить к высоким трудозатратам. Первична разработка того, что этим Redd-ом тестируется.
Но в целом, самое весёлое, что мне доводилось делать — SATA ядро собственное для Cyclone IV GX. Писал с нуля. Оно работало прекрасно. Главное — было именно придерживаться правильной привязки к тактовым импульсам. А остальное — система сама разбиралась, исходя из тактовой в настройках PLL.
В общем, я не спорю, что все эти Constraints — вещь очень полезная. Я просто говорю, что начинающим они могут ещё не скоро понадобиться. Кто собрался вот прямо завтра делать что-то серьёзное, тот не по статьям учиться будет. А остальных надо сначала втянуть, а там — они сами выяснят, как развиваться, и надо ли это делать.
Но не даром же я в статье показал, что допустимая частота у нас 133 МГц, после чего начал делать всё для сотни. Есть у меня такая привычка, не все соки из системы выжимать… Как раз это и даёт пространство для автоматической оптимизации…
В нашем конкретном случае, в ПЛИС всего два блока PLL, так что особо нечему меняться. Максимум два варианта. Линии GCK тоже, кажется, к ногам по возможности привязаны. Если же нет, то всё равно, GCK — особые линии. У них повторяемость высокая.
Вообще, моя задача показать, что ПЛИС — это просто. Не надо пугать читателей. Мало того, для проектов средней руки для современных ПЛИС это утверждение верно. Все соки выжимать — вот понадобится кому-то, пусть они и учатся. Но сначала пусть втянутся. Тем более, что может и не понадобится это никогда кому-то. Задачи — не всегда сверхмощные, а вот ПЛИС нынче — достаточно мощны. Так что и автоматически подставленных средой разработки ограничений, вытекающих из заданных частот PLL вполне может хватить.
Так что прошу читателей не бояться пробовать работать с ПЛИС, будь то Redd или какая недорогая макетка с Ali Express. Будут проблемы — будете осваивать новые методики. Не будет — не будете (это я к читателям обращаюсь)
Буфер доступен на запись и чтение. DMA туда пишет, затем — Nios II своим JTAG блоком мне спокойно всё перекидывает в отладочное окно. Я разношу эти вещи по времени чисто организационным путём.
То есть, добавляем двунаправленную стрелку доступа к регистрам DMA, делаем двунаправленными стрелки для Buffer и Nios II. Получаем на Вашей схеме то, что задумано.
Когда DMA гонит данные в Buffer, в это время другие устройства на шине могут общаться друг с другом, не мешая процессу. Выяснено опытным путём. Если начать обращения от других устройств к Buffer — там уже начинаются конфликты за шину. У нас такое другое устройство, разумеется, одно — Nios II.
Чип Селект же в AVALON-MM устройство приходит. Ну, точнее, персональные RE/WE. На классических шинах этого вполне было бы достаточно. Здесь же, судя по полученным результатам, даже данные коммутируются. И это — здорово (пока ресурсов хватает, разумеется).
Или сделать библиотеку с универсальным интерфейсом. Собрать версии библиотеки под каждую ОС и подключать их к проектам. А пользователи, опять же, не будут знать, к кому обращаются. Главное — чтобы интерфейс был универсальным.
Но это — уже выходит за рамки как статьи, так и цикла.
JTAG канал встроен в ПЛИС от её рождения. Описанная тут функциональность — встроена в среду разработки. Как видно, в рамках данной статьи мы не написали ни одной строчки своего кода ни для ПЛИС, ни для ЭВМ. Нам хватило всего встроенного.
FT245-SYNC добавлен в комплекс Redd потому, что мы его выбрали. Мы заложили в схему этого комплекса чип FT2232H. Поэтому чтобы его поддерживать, в статьях, на которые я дал ссылки выше, я сначала проектирую автомат, затем — делаю его реализацию на языке Verilog, затем — оборачиваю его в компонент, затем — вставляю в систему, затем — добавляю немного штатной обвязки, затем — связываю всё это. И в итоге — у меня получается FIFO, к которому имеет доступ только программа для процессора NIOS II. Но так же я могу написать мастера, имеющего доступ к Memory Mapped шине. Но лично я — не буду этого делать. Сил много потрачу. Проще ограничиться FIFO и брать оттуда данные программно, либо программно же класть их туда.
Как видите, технически всё возможно, но реально всё похоже на анекдот:
— Доктор, я после операции буду играть на скрипке?
— Конечно будете!
— Спасибо, доктор, а то я раньше не умел.
Вот если приложить массу усилий, то FT245-SYNC к шине AVALON-MM приладить можно (надо долго учиться играть на скрипке). Зато всё будет идеально. Описанную же в этой статье функциональность сделала для нас «мать-природа» в лице инженеров Альтеры. Но она — смешная по производительности. Зато не надо мучиться.
То есть, технически — всё заменяемо. Но трудозатраты — не сопоставимы. Поэтому я не скажу, что всё взаимо заменяемо. Хотя бы потому, что одна из функций — врождённая в систему, а вторая — нет.
Но в рамках цикла статей важнее Linux (Debian) вариант. Потому что система запускается на ПЛИС, физически подключённой к ЭВМ с Линуксом. Значит, управляющий код на той ЭВМ и должен исполняться. Так будет производительнее всего.
Но как было видно в статьях по ссылкам, данная функциональность несколько сложна в добавлении. Зато скоростная. Если же скорость обмена не критична (например, данных не очень много) — можно воспользоваться работой через JTAG канал, описанный в этой статье. Выигрываем в скорости разработки и в свободной памяти ПЛИС, проигрываем в скорости работы.
А дальше — каждый решает, что ему важнее в данный конкретный момент. Владея обоими методами, можно оптимизировать работу под каждый конкретный случай.
Спасибо! Буду пробовать!
Протокол FT245-SYNC заложен, как штатный для сязи ПЛИС с центральным процессором Redd (реализован на чипе FT2232H). Работа с ним была рассмотрена ранее, тогда же сделаны замеры его скорости. Первое рассмотрение — во второй части тут, далее — тут.
Причём мы пытались общаться с поддержкой как Segger, так и Кейла. Сделали для них подробное описание, сняли кино с показом, когда работает, когда — нет… Сеггеры сказали, что хоть у нас и подлинный адаптер, но эта модель не подразумевает поддержки. Кейлы сказали, что DLL для связи делали Сеггеры, так что они бы и рады, да ничего сделать не могут. Обращайтесь к Сеггерам.
А через туннельный сервер Сеггеровский — ещё веселей. Вот ответ поддержки Кейла:
Но в первую очередь, Малину можно положить рядом с поделкой, с которой слишком круто оставлять настольную машину. Она маленькая, и цена у неё не такая кусачая (тем более, что по сусекам многие могут наскрести даже не одну валяющуюся без дела Малину).
Плюс иногда RDP подтормаживает. Понятно, что и отладка будет при тех же условиях не идеальной. Но разработка текста идёт дольше по времени, чем связь в процессе отладки.
В общем, RDP — лучше в целом, а этот подход — может пригодиться в особых случаях.
Ещё раз спасибо за обзор.
Очень хороший обзор — и всё очень совпадает с тем, что вижу каждый день в работе.
Вы писали
А кого можно отнести к этому десятку? (правда интересны больше разработчики микропроцессоров и микроконтроллеров) — Миландр, Модуль, Байкал, Элвис, МЦСТ, GS Nanotech,… больше и не вспомнить… да и не у всех у них миллиарды даже в рублях
Ну, и программный интерфейс — классический, как для обычных UART. Какой бы физический чип ни стоял, какой бы драйвер его ни обслуживал. на PC интерфейс прикладного программиста для UART будет един.
Для переходников USB в I2C/SPI такого шикарного набора готовых решений для PC не наблюдается. А в основе комплекса Redd лежит именно PC.
Теперь насчёт Cypress. Они выпускают отладочные платы для своих контроллеров PSoC. У меня была большая серия статей про эти PSoC, там рассказывается про эти платы. На платах имеются отламываемые контроллеры, реализующие интерфейсы JTAG, UART, SPI, I2C. Соответственно, Cypress выпускает под них готовые драйверы и API. И были найдены «исходники» прошивки. То есть, мы имеем хоть что-то, готовое, отлаженное, где не надо проектировать всё от архитектуры через «прошивки» и драйверы до библиотек пользователя. Но в целом — там даже с лицензией не всё так хорошо. Да и распространённость — смешная.
Вот что-то в этом роде имелось в виду. Мосты FTDI — дорогие, зато обеспечивают полный набор давно отлаженных средств (железо, драйвер, библиотека). Плюс железо — с USB 2.0 HS, а не FS, как у многих контроллеров. Ну, и хоть какой, но всё-таки единый стиль API у всех библиотек FTDI — тоже подкупает. Поэтому в систему были добавлены именно они.
Дело в том, что это не просто два порта одного устройства, а два порта, реализованных в одном и том же чипе. И контакты — на одном и том же разъёме. Но даже если бы чипов было два на одной плате, то паянный контакт через широкую дорожку (а сегодня это физически — отдельный слой на плате) будет намного лучше, чем через провод и сопротивление минимум двух контактов на стыке «разъём-провод».
Достаточно посылать не «A», а «A?». Буфер USB FS — 64 байта, оба байта уйдут в одном и том же физическом пакете. И устройство пришлёт пакет с ответом из трёх байт, в которых на заведомо известной позиции будет стоять эхо. Можно даже посылать пакет вида «AbC?» — это тоже менее шестидесяти четырёх байт. И они тоже уйдут в одном USB пакете. Порт же виртуальный. При разработке протокола эти возможности были учтены.
В итоге каждый может посылать так, как сочтёт нужным. Лично мне нравится без эха. Но добавляем в посылаемую строку знак вопроса, который не даст никаких накладных расходов из-за особенностей протокола USB, получаем то, что нравится тем, кто любит ответы.
Но может, просто у меня задачи простые. Однако и цикл статей в тему, про аппаратуру, которая помогает в отладке и тестировании других больших проектов. Разработка под Redd — вторична и не должна приводить к высоким трудозатратам. Первична разработка того, что этим Redd-ом тестируется.
Но в целом, самое весёлое, что мне доводилось делать — SATA ядро собственное для Cyclone IV GX. Писал с нуля. Оно работало прекрасно. Главное — было именно придерживаться правильной привязки к тактовым импульсам. А остальное — система сама разбиралась, исходя из тактовой в настройках PLL.
В общем, я не спорю, что все эти Constraints — вещь очень полезная. Я просто говорю, что начинающим они могут ещё не скоро понадобиться. Кто собрался вот прямо завтра делать что-то серьёзное, тот не по статьям учиться будет. А остальных надо сначала втянуть, а там — они сами выяснят, как развиваться, и надо ли это делать.
Но не даром же я в статье показал, что допустимая частота у нас 133 МГц, после чего начал делать всё для сотни. Есть у меня такая привычка, не все соки из системы выжимать… Как раз это и даёт пространство для автоматической оптимизации…
Вообще, моя задача показать, что ПЛИС — это просто. Не надо пугать читателей. Мало того, для проектов средней руки для современных ПЛИС это утверждение верно. Все соки выжимать — вот понадобится кому-то, пусть они и учатся. Но сначала пусть втянутся. Тем более, что может и не понадобится это никогда кому-то. Задачи — не всегда сверхмощные, а вот ПЛИС нынче — достаточно мощны. Так что и автоматически подставленных средой разработки ограничений, вытекающих из заданных частот PLL вполне может хватить.
Так что прошу читателей не бояться пробовать работать с ПЛИС, будь то Redd или какая недорогая макетка с Ali Express. Будут проблемы — будете осваивать новые методики. Не будет — не будете (это я к читателям обращаюсь)