Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
Хороший материал по Nios, на ближайшей сходке fpga-шников в Питере хотим рассказать там тоже некоторые интересности про разработке с его использованием.
По материалам к использованию Nios кстати еще хорошие есть выкладки на Марсоходе.
С этим пока не сталкивался, все что пробовали — хорошо заводилось, все просто старое: забавно видеть там упоминания sopc builder и нулевые годы с нерабочими ссылками.
Уже пробовали использовать trace и profiling для анализа и отладки?
По материалам к использованию Nios кстати еще хорошие есть выкладки на Марсоходе.
На самом деле, нерабочие шаблоны — фирменный стиль Квартуса.
С этим пока не сталкивался, все что пробовали — хорошо заводилось, все просто старое: забавно видеть там упоминания sopc builder и нулевые годы с нерабочими ссылками.
Уже пробовали использовать trace и profiling для анализа и отладки?
Они не со зла. Просто в данном конкретном примере — они не ожидали, что кто-то может сделать систему без средств вывода хоть куда-то. В результате, их шаблонный код стал неработоспособным — шаблон считает, что хоть какой-то вывод, а есть. Вот и пришлось убрать соответствующую функцию. Аналогично — и другие проблемы. Всё от того, что они не всегда учитывают возможное отсутствие тех или иных вещей. Почему у меня вещей не было — статья и так распалась от тяжести на две части. Мне показалось, что не стоит пытаться объять необъятное и здесь грузить читателя ещё одной новой для него вещью. Вставил только самое необходимое, чтобы новых сущностей было как можно меньше. Отладочный вывод можно будет ввести позже, когда новички уже освоятся.
Но как бывший профессиональный тестер, всё-таки отмечу, что код у них получился неработоспособным. А могли бы и предусмотреть такой вариант.
Блок трассировки довелось активно применять на ARM ядре, чтобы понять, где же всё тормозит. После изучения растактовки, выводы были такими, что пока что мы отказались от использования Cyclone V SoC в наших задачах (подробнее об аргументации было в прошлой статье и чуть-чуть — в ответе ниже). Как бы я без него решил проблему, когда вливаешь код на SDшку, включаешь, а он вылетает в исключение — ума не приложу. А так — берём трассу в режиме с точностью до команды, и смотрим, как же код докалился до такой жизни. Но всё это было на Cyclone V SoC с тем ядром.
Но как бывший профессиональный тестер, всё-таки отмечу, что код у них получился неработоспособным. А могли бы и предусмотреть такой вариант.
Блок трассировки довелось активно применять на ARM ядре, чтобы понять, где же всё тормозит. После изучения растактовки, выводы были такими, что пока что мы отказались от использования Cyclone V SoC в наших задачах (подробнее об аргументации было в прошлой статье и чуть-чуть — в ответе ниже). Как бы я без него решил проблему, когда вливаешь код на SDшку, включаешь, а он вылетает в исключение — ума не приложу. А так — берём трассу в режиме с точностью до команды, и смотрим, как же код докалился до такой жизни. Но всё это было на Cyclone V SoC с тем ядром.
Не то, чтобы это было совсем отлично, но всяк лучше, чем 4 МГц при тактовой частоте 925 МГц для Cyclone V SoC…
Это было дерганье ножками HPS части или через PIO модуль FPGA части?
Ножку дёргал в FPGA части. С HPS частью ограничился работой с UART. Когда на трассе JTAG отладки увидел, сколько тактов занимает постановка байта в FIFO штатной API функцией, проверяющей его переполнение — мне стало плохо. При том, что очередь была заведомо пуста. Функция, не проверяющая переполнения, до инфаркта не доводила, но всё равно была не ахти, ведь FIFO придумали, чтобы туда бросил байт и забыл. Сотни тактов на эту операцию — ужас.
В общем, я во всём виню латентность (много одиночных записей подряд и на Cyclone V SoC не очень плохо бегают, а когда процессору надо дождаться считанных данных — они придут только когда закончатся все отложенные записи). Запрос там проходит через слишком большое количество мостов, это следует из документации. В HPS аппаратуру — поменьше, в FPGA — побольше. Для больших объёмов данных в едином пакете латентность не страшна, для одиночных обращений — плоха, для смешанных одиночных чтений и записей — вообще убийственна.
В общем, я во всём виню латентность (много одиночных записей подряд и на Cyclone V SoC не очень плохо бегают, а когда процессору надо дождаться считанных данных — они придут только когда закончатся все отложенные записи). Запрос там проходит через слишком большое количество мостов, это следует из документации. В HPS аппаратуру — поменьше, в FPGA — побольше. Для больших объёмов данных в едином пакете латентность не страшна, для одиночных обращений — плоха, для смешанных одиночных чтений и записей — вообще убийственна.
К слову о доступе к FPGA части на Cyclone V SoC. После кучи опытов, я выяснил, что там по тактам будет быстрее ловить прерывание от своего FPGA компонента, чем опрашивать его регистр состояния. После перехода на прерывания, система стала работать веселей, но всё равно асимметрия тактов на запись, на вторую и последующие записи в серии и на чтение, заставила сильно усложнять код. Когда условностей стало слишком много, я плюнул и переделал ту разработку на PSoC с его слабеньким Cortex M3. Код стал линейным и простым. Надо было думать о логике, а не о тонкостях возникающих задержек.
В общем, ПЛИС с ядром Cortex A, на мой взгляд — не для управления, а для обработки больших потоков данных. Там им равных я не вижу. Но в рамках рассуждений о комплексе Redd — нужно управление.
В общем, ПЛИС с ядром Cortex A, на мой взгляд — не для управления, а для обработки больших потоков данных. Там им равных я не вижу. Но в рамках рассуждений о комплексе Redd — нужно управление.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка простейшей «прошивки» для ПЛИС, установленной в Redd. Часть 2. Программный код