Перейти к содержанию
    

dxp

Свой
  • Постов

    4 515
  • Зарегистрирован

  • Посещение

  • Победитель дней

    9

dxp стал победителем дня 23 ноября 2023

dxp имел наиболее популярный контент!

Репутация

31 Очень хороший

5 Подписчиков

Информация о dxp

  • Звание
    Adept
    Гуру

Информация

  • Город
    Array

Retained

  • Звание
    Array

Посетители профиля

12 255 просмотров профиля
  1. Ну, так это ж application процессор. Он быстрый, но неповоротливый, прерывания для него -- дорогая штука. Основные задержки, полагаю, там в контроллере прерываний GIC: толстая штука с поддержкой 1000+ источников прерываний. С такими процами просто и подход исходно другой: они применяются обычно как управляющее ядро SoC, а SoC -- это система, состоящая из достаточно самостоятельных устройств, обладающих приличной "автономностью", т.е. способных без вмешательства процессора выполнять сложные цепочки операций. Процессор там в основном участвует для настройки аппаратуры, мониторинга процесса работы и корректировки, ну, и конечно, для организации интерфейса пользователя (хоть CLI, хоть GUI, хоть веб-интерфейс). Ну, и поскольку системы сложные, устройства непростые, там потенциально возможно большое количество прерываний, что налагает требования на контроллер прерываний. С другой стороны, поскольку устройства достаточно "самостоятельные", метаться по прерываниям на каждый чих не нужно. Вот и причина, почему такой сдвиг акцента: количество разменивается на скорость. Но при таких "неприятных" значениях задержки на практике всё не так печально -- абсолютное-то время всё равно получается вполне приемлемым за счёт высокой частоты. Я сам озабочен подобными описанным вами вопросами -- предсказуемость времени реакции. Поэтому тоже ковыряю Zynq-7000 на предмет baremetal. Моё намерение: разместить программу в OCM, которой там 256к (для моих задач достаточно, что-то не критичное можно и в SDRAM закинуть), и это уровень L2, т.е. при промахе кэша L1 дальше этого уровня запрос не пойдёт (в отличие от случая, когда программа в SDRAM -- там возможен промах L2 кэша, дальше задержка обращения в SDRAM, в которой пасётся много кто -- та же FPGA часть -- в общем, тут задержка вместо нескольких тактов до OCM может вырасти до пары тыщ (видел отчёт несколько лет назад в Сети). Но baremetal на application процессорах -- это то ещё "удовольствие". В основном это касается, конечно, запуска, потом-то всё вполне обычно. Но старт весьма нетривиален.
  2. А вот как раз на Zynq-7000 это и было. 🙂 Прерывания пробовал разные -- от внешней ноги и от таймера.
  3. А где говорилось про FreeRTOS? Эта RTOS самая тормозная из всех подобных, есть решения побыстрее. И даже если попасть на прерывание, критическую секцию, это даст пару сотен нс "джиттера", совершенно не критично и того же порядка величины. Т.ч. вполне можно говорить о какой-то детерминированности (гарантированности) времени реакции на событие. Обработчики прерываний в этом подходе, разумеется, нужно делать как можно более короткими, выполняющими самый минимум работы: получил событие -- взвёл сигнал, пихнул в очередь и т.п. Расскажите это, например, Cortex-A9 с GIC, у которого вход в IRQ занимает пару сотен тактов (на тактовой CPU 400 МГц задержка от внешнего события, до попадания в обработчик прерывания от него занимает порядка 450 нс -- специально исследовал этот вопрос, снимал времянки осциллографом, очень удивлялся поначалу, пока не понял, почему так).
  4. Если нужна прямо такая лютая риалтаймовость, то почему просто не выполнять этот код (4 мкс) прямо в обработчике прерывания? К тому же, на фоне 200 МГц тактовой проца 10 мкс выглядят не так уж мало, а тормознутость RTOS -- понятие растяжимое. Если не обременяться сложными планировщиками, не цеплять толстые хуки на процессы переключения контекстов, то там время передачи управления вполне себе не страшное -- например, на Cortex-M4 при 168 МГц время передачи управления (не просто переключение контекстов, а именно от возникновения события до получения управления кодом потока) порядка 900 нс. Это для самого приоритетного потока. Можно распихать этот требующий риалтайма код по приоритетным потокам (которые будут сами нагло отбирать управление у менее приоритетных, когда им надо) и не придумывать ничего.
  5. Сама по себе PCIe корка с AXI4-Stream портами небольшая -- там же аппаратный блок основную функциональность тащит. Насколько помню, PCIe x4 выходила в таком виде порядка 1000 лутов. А BRAM тоже зависит от заявленного размера буферов, по минимуму там было 8 или 9 штук.
  6. Какие разрядности и частоты вам нужны? Какая ПЛИС?
  7. Как оно поможет? Чем это лучше: logic cnt = 0; always_ff @(posedge clk) begin cnt <= cnt + 1; end ? Ваш вариант будет работать точно не быстрее. В лучшем случае он сведётся к приведённому. Скоростные многоразрядные счётчики делаются совсем не так.
  8. Не считается: ламп нет, конденсаторов с диэлектриком из соплей девственниц нет, про проводники на плате из бескислородной меди тоже ничего не сказано.
  9. Ubuntu PCIe remount - как?

    А что, 100 мс нынче -- это реальная проблема? Это требование на ATX системах тянется из старых версий стандарта, когда процы были простыми и поднимались шустро. Сегодня же даже дескоптный процессор -- это сложнючая система на кристалле, которая стартует долгие секунды (это можно наблюдать при включении компа), а уж на серверах это вообще запредельно долго -- специально замерял время от включения до подъёма линка на каком-то Xeon'е, довольно старом уже, там оно составляло 29 секунд! Выглядело так: включил питание, на мониторе (подключил VGA к серверу) чёрный экран, висит всё это долгие секунды, потом появляется приглашение BIOS и в ту же секунду поднимается линк. Т.е. енумерация там пролетает почти мгновенно, а основное время процессор находится "в себе", что-то проверяет, память тестирует. Кроме этого я ещё осциллографом посмотрел тайминги поднятия питания и сигнала сброса. Там времена от Power Good до сброса PCIe существенно больше 100 мс. Т.е. если загрузка FPGA происходит сразу после подачи питания, то эта задержка + гарантированные 100 мс дают достаточно времени для прихода устройства в готовность (там речь шла об Artix-7). Я так подробно это смотрел, потому что тоже запаривался насчёт требования 100 мс готовности, и Artix-7 xc7a200t (самый толстый то есть) никак не успевал загрузиться за 100 мс. Даже при внешнем клоке (EMCLK) с оптимизацией времянок по QSPI всё равно выходило существенно больше 100 мс (то ли 130, то ли под 200, не помню уже). Но производитель не парится на эту тему, и понятно почему. Тандемной загрузки у этой FPGA нет, она начинается у Kintex. Но оказалось, что реальной проблемы на современных x86 нет -- сложная система приходит в готовность несоизмеримо дольше, чем 100 мс. Я понимаю, что это не инженерный подход, что никто не гарантирует работоспособность. Наверное, правильным было бы пересмотреть требования стандарта, т.к. не только процессоры, но и сами периферийные устройства стали значительно более сложными, требующими куда больше времени на приведение к готовности, нежели пресловутые 100 мс. Но по всей видимости, проблемы реально не существует -- практический любой современный процессор по факту даёт времени для готовности с огромным запасом в силу собственной сложности и неповоротливости, поэтому никто и не парится по этому поводу.
  10. Вам нужно именно С в питон перегнать или можно из питона вызвать C/C++ реализацию? Насчёт трансляторов сомневаюсь. В питоне просто некоторые вещи реализованы принципиально иначе -- например, С/C++ массив не очень транслируется в питоновые типы, это лучше заменять numpy массивами, которые помимо хорошей эффективности ещё и тянут за собой приличного размера библиотеку (в т.ч. реализацию тех же BLAS/LAPACK). В общем, там в каждом случае надо оценивать, во что выливается транслированное значение. Если же просто требование запускать код на питоне, то я бы C/C++ оформил в виде некоего API, которое "пробросил" на уровень Python, откуда просто вызывать эти функции/объекты. Существует энное количество способов это сделать: https://realpython.com/python-bindings-overview/. Я использовал boost-python. Технически код на C/C++ компилируется в динамическую библиотеку (dll/so), которая в коде Python просто импортируется стандартным образом (import <module-name>). например, в C/C++ исходнике: // slon.c compiled to shared library slon.so int a; int b; int fun_add(int x, int y) { return x + y; } BOOST_PYTHON_MODULE(slon) { using namespace boost::python; //-------------------------------------------------------------------------- // // exposed variables // scope().attr("c_var_a") = a; scope().attr("c_var_b") = b; //-------------------------------------------------------------------------- // // exposed functions // def("c_fun_add", fun_add); } //------------------------------------------------------------------------------ В Python: import slon from slon import c_var_b from slon import с_fun_add as add a = slon.c_var_a result = add(10, 20) - a + c_var_b <...> Таким образом можно гибко распределить код между языками, это будет по гибкости и удобству Python, а по эффективности C/C++.
  11. Какая специфика разработки под ASIC делает Perforce предпочтельнее Git, учитывая, что с именно версионированием (возможностью легко и непринуждённо вести параллельно несколько веток -- версий) у Perforce всё достаточно печально. Нужно бинарники большого объёма сохранять под контролем?
  12. Зависит от конструкции мотора. Точнее, от величины реактивного момента. Например, у ШД с 200 шагов на оборот этот момент весьма ощутимый, и двигатель стремится встать в одно из устойчивых положений. Но бывают (их меньше) движки с практически неощутимым реактивным моментом (вал крутишь, никаких "залипаний" не ощущается, как будто коллекторный двигатель), у таких никакого притяжения к ближайшему полюсу нет, и если механика никуда его не тянет, он остаётся в том же положении. Шагов на оборот у таких ШД обычно немного -- порядка 20, и управляются они с дроблением шага (sin-cos), какие-то от Maxon использовали (к сожалению, сейчас это практически недоступно). Такие движки более динамичные (реактивный момент как раз мешает динамике), но и управлять ими сложнее.
  13. Это не самый обычный, а какой-то ноунейм непонятный. Я же предложил рядовую модель от известного бренда Сигейт Барракуда. И сравнивать надо на одной площадке -- при чём тут Озон? Там торгует хрен знает кто хрен знает чем, поэтому и цены на одно и то же могут отличаться в разы. Если Алиэкспресс посмотреть, то там такие причудливые варианты находятся. Мы же говорим про комплектующие для работы, а не чтобы как можно дешевле. Вот вы бы купили себе такой SSD? Что бы вы предпочти для 2ТБ хранилища -- этот ноунейм или тот Сигейт?
×
×
  • Создать...