nabbla (nabbla1) wrote,
nabbla
nabbla1

Categories:

Как ускорить QuatCore в очередной раз?

Всё-таки медленно программа обнаружения работает - может отстать от "реального времени", чего допустить никак нельзя.

По вчерашнему случаю, что самое смешное, всего 17 тактов не хватило! Причём небольшая доработка программы ещё позволила сэкономить два раза по 3 такта, так что остаётся 11:


Но есть ещё порох в пороховницах, пара идей, как отделаться малой кровью... Что интересно, все они касаются улучшения управляющей логики, тогда как Data Path остаётся практически неизменным.


1. "Успокоить" видеопроцессор
Он у нас имеет два режима: "захват" и "сопровождение". В первом он ищет самый яркий пиксель на отрезке и его координату, во втором - две суммы, из которых можно вычислить яркостный центр пятна с субпиксельной точностью. Кроме того, задаётся конец отрезка, т.е до какой координаты надо считать.

Сейчас, если все задания закончились, видеопроцессор тут же начинает материться: "зажигается" UFLO (Underflow), которое вызывает соответствующее прерывание - и нормальный ход работы уже завершается. На скриншоте мы видим именно такую ситуацию.

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

На скриншоте выше последнее задание закончилось на X=0x2F, после чего видеопроцессор уже начал ругаться. А мог бы с этого момента спокойно дальше работать, и спустя 11 тактов получил бы новое задание до X=0x7F, то есть гораздо выше текущей координаты. И если всё правильно: новое задание именно на захват, и до координаты, до которой мы ещё не дошли - принимаем задание "как ни в чём не бывало", в противном случае - громко ругаемся.

Такая логика в данном конкретном случае выигрывает нам 80 тактов, а в общем случае - "один отрезок", а уж его длина - как повезёт. "Дешево и сердито".

2. Привести АЛУ к философии TTA
Наш процессор не CISC и не RISC, а вовсе даже TTA - Transport-Triggered Architecture, когда команды по сути напрямую управляют пересылкой данных по шине между различными устройствами, такими как АЛУ, контроллер памяти, устройства ввода-вывода, счётчик инструкций и пр.

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

Другое дело, что мы всё-таки ввели блокировки а-ля "горшочек, не вари!", когда одно устройство явно опережает других. Так, если мы спамим UART кучей байт, которые тот не успевает отправить - рано или поздно он нас приостанавливает, пока у него в буфере снова не появится место, та же история с видеопроцессором. Также мы можем остановиться, если запрашиваем данные, которые не готовы.

Особняком до сих пор стоит АЛУ: когда мы "озадачиваем" его операцией, занимающей несколько тактов (а это львиная их часть), всё останавливается, пока АЛУ не закончит свою работу.

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

Но можно пойти ещё дальше, обеспечить конвейерную обработку в АЛУ! "Наметки" этого конвейера уже проглядываются. Собственно, почему на сложение уходит 3 такта. Первый такт - значение поступает в регистр B. Второй такт - оно сдвигается вправо на единичку, возможно с инверсией и расширением знака (если нужно вычитание, а не сложение). Третий такт - это значение прибавляется к аккумулятору и заносится туда.

На третьем такте мы уже можем защёлкивать в регистр B новое значение, т.е следующая команда для АЛУ не обязана дожидаться полного окончания работы!

Но на самом деле регистр B можно ещё разделить на две части, потому как он и так начал занимать по 2 ЛЭ на каждый младший бит из-за логики Bypass: если адресом является сам АЛУ, мы загружаем не только 16 бит с шины данных, но и младшие биты напрямую из аккумулятора, что должно нам заметно повысить точность "сложной математики" вроде разложения Холецкого.

Если так сделать, то длинные цепочки сложений-вычитаний, которых здесь довольно много (загрузить первое значение в аккумулятор, прибавить то, вычесть это) ускорятся почти что ВТРОЕ!

Но как реализовать управляющую логику для этого дела - я пока не очень понимаю... По сути, она должна быть в курсе максимум о трёх разных командах, выполняемых одновременно (на разных стадиях исполнения). Чего-то страшно!


Но сейчас надо всё это отложить в сторону - и заняться всё-таки протоколом информационного обмена. Раздражает меня это - прибора ещё нет, а протокол вынь да положь! Если когда-нибудь всё-таки сделаю рабочую, "лётную" программу, буду очень злиться на себя сегодняшнего, какую хрень туда написал, и теперь её придётся исполнять, ломая всю логику через колено!
Tags: ПЛИС, программки, работа, странные девайсы
Subscribe

  • Ремонт лыжных мостиков

    Вернулся с сегодняшнего субботника. Очень продуктивно: отремонтировали все ТРИ мостика! Правда, для этого надо было разделиться, благо народу…

  • Гетто-байк

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

  • А всё-таки есть польза от ковариаций

    Вчера опробовал "сценарий", когда варьируем дальность от 1 метра до 11 метров. Получилось, что грамотное усреднение - это взять с огромными весами…

  • Так есть ли толк в ковариационной матрице?

    Задался этим вопросом применительно к своему прибору чуть более 2 недель назад. Рыл носом землю с попеременным успехом ( раз, два, три, четыре),…

  • Big Data, чтоб их ... (4)

    Наконец-то стряхнул пыль с компьютерной модели сближения, добавил в неё код, чтобы мы могли определить интересующие нас точки, и выписать…

  • Потёмкинская деревня - 2

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

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 1 comment