Поменялось ли что-нибудь при инициализации PCI/PCIe устройств, доступ в регистры устройства через BARы и т.п.
Аллоцирование памяти для DMA: в которую и устройство может писать и читать, и ядро, и пользовательские программы (dma_alloc_coherent, dma_alloc_noncoherent, ...), и ещё с IOMMU. А то у меня при переходе на каждое новое LTS ядро что-то да перестает работать. :(
Я бы еще предложил покрутить режим сглаживания (anti-aliasing) шрифтов. Например, сглаживание с учетом расположения пикселей мне не заходит: хоть буквы и глаже становятся, но цветовая койма бесит. А если у монитора не такое расположение цветов в пикселе как ОС думает, то вообще фигня может выйти. И степень сглаживания тоже индивидуальна.
Скажите, а как батареи переживают зимовку в неотапливаемом доме (-30°С и ниже)?
У старших родственников дом в деревне под ВВ. Электричество в целом приемлемое, но бывает (скажем, раз в неделю) вырубается из-за грозы, упавших деревьев и т.п. Живут в основном с весны по осень. Думаю ставить солнечные батареи еще рано, а вот иметь аккумулятор, который вытянет часов 3-6 отключения (насос, холодильник, интернет) хотелось бы. Можете посоветовать с какой стороны подступиться к этому вопросу? Инвертор + батареи это адекватный первый шаг? И какие батареи лучше под такой режим эксплуатации и хранение зимой? Что почитать?
Я начал активно работать в этой области лет 10 назад, и начал с VHDL, т.к. вокруг были люди, которые его использовали, и которые неодобрительно смотрели на Verilog.
Да, VHDL более многословный. Но не так, как пугают: на заре был более многословных, а сейчас - терпимо. Да и почему-то не любят использовать "нестандартизированные" библиотеки типа ieee.std_logic_unsigned , которые заметно сокращают объем кода.
Я смирился с его многословностью: пишу некоторыми синтаксическими шаблонами, к которым привык. Но ни за что не променяю его типы и строгую типизацию. Поэтому с интересом приглядываюсь с SpinalHDL: имеет строгую типизацию и добавляет то, чего мне не хватает в VHDL: параметризации типов, модулей и т.п. Я пока писал только что-то совсем мелкое, и пока не убедил себя на него перейти: у меня нет проблем со скоростью написания многословного кода, т.к. основное время приходится думать что написать, а не писать ;).
P.S. Да, я пишу практически только синтезируемый код с небольшими тестами. Поэтому на богатство Verilog/SystemVerilog и других инструментов по симуляции смотрю равнодушно.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity ripple_adder is
port (
a : in std_logic_vector(3 downto 0);
b : in std_logic_vector(3 downto 0);
cin : in std_logic;
cout : out std_logic;
s : out std_logic_vector(3 downto 0));
end entity;
architecture rtl of ripple_adder is
signal sum : std_logic_vector(4 downto 0);
begin
sum <= ('0'&a)+('0'&b)+("0000"&cin);
cout <= sum(4);
s <= sum(3 downto 0);
end architecture;
Я начал лет на 15 позже, все успокоились, наверное, т.к. std_logic_unsigned нормально поддерживается всеми используемыми инструментами. Рекомендацию слышал, но писать как предлагает numeric_std вообще не захотелось. Явно это были голоса тех, то продвигали Verilog ;)
Я использу ieee.std_logic_unsigned.all, и тогда std_logic_vector можно складывать без приведения. Да, в VHDL нет расширения до размера результата, а только до максимальной ширины аргументов, но это спорный вопрос что лучше. Больший контроль за разрядностью - меньше ошибок, но чуть больше кода, когда надо разрядность изменить.
P.S. Сразу скажу, что в моих ПЛИС и чипах нет знаковых чисел совсем (вот такие задачи ;)), да и расширения разрядности тоже не вспомню, чтобы требовались, кроме при выдачи в PCIe, где все регистры, видимые из процессора, 32 битные.
Красиво! Но какой-то overkill как "выльем воду из чайника и сведем задачу к предыдущей". FIFO с данными уже имеет внутри себя всю необходимую информацию. Надо только ее достать, что, к сожалению, готовые FIFO не позволяют. Как и многое другое (например, если FIFO стоит перед линией передачи где бывают ошибки, то для переповторов удобно использовать это же FIFO, но тогда нужны 3 счетчика).
P.S. Мой вариант с счетчиком - это по сути и есть FIFO ширины 0, только реализованная руками.
При низкой интенсивности можно вместо уровнем '1' кодировать сменой '0'->'1' или '1'->'0'.
Если интенсивность высокая то, то можно завести счетчик выбранных из FIFO пакетов (в кодировке Грея) и чего инкрементировать. А на приемной конце завести счетчик посланных в FIFO пакетов и кредит - их разность. Только в этом случае обратно не один провод, а шина. В каком-то смысле это и есть адреса в FIFO. Примерно так я и делаю, когда надо через PCIe кредитный трафик гнать.
Мне нужны были и кредиты, и переход между клоками. Делать две FIFO в ПЛИС, где блоков памяти мало, не целесообразно. Поэтому и делал всё на одной FIFO. И т.к. FIFO большая, то экономить ячейки не стоит.
С одной стороны, чтобы работало и не ломалось можно и не считать стадии конвейера. С другой, если нужна максимальная пропускная способность, то посчитать придется, чтобы конвейер не вставал. Так что мне пришлось бы считать в любом случае.
Наверное не очень аккуратно выразился. С двух местах надо указывать размер FIFO: в самом FIFO, и в счетчике. Можно ошибиться ;). Как можно ошибиться с количеством шагов конвейера (тогда схема с подсчетом кредитов в FIFO сломается).
В общем, я не против предложенной схемы. Она разумна и много где подойдет. Я против возведения ее в абсолют, что больше ничего другого знать не нужно. Если и другие схемы, которые в каких-то ситуациях могут быть лучше.
Но и такое решение имеет право на жизнь: в ПЛИС FIFO на 1 шт. блочной памяти будет иметь зачастую больший, чем нужно размер. Или если FIFO двухклоковое, то напрямую кредит как в Вашем рисунке https://habr.com/ru/post/706484/#comment_25030966 не проведешь. Или бывает нужно пропустить кредитный сигнал через регистр для лучший разводимости, тогда в FIFO надо закладывать запас для максимальной пропускной способности. Я у себя для таких потоковых задач (в том числе и с мультиплексорами и демультиплексорами), и для мультиплексоров использую а-ля almost_full сигнал: из FIFO вывожу количество свободных мест, из него вычитаю количество регистров на пути данных от источника до FIFO, так и на пути этого управляющего сигнала от FIFO до источника, и если величина положительна, то можно слать. Тогда всё вычисление кредита локализовано у FIFO (а не находится в двух местах, где надо одновременно менять размер FIFO), а источник по сигналу посылает данные. В общем, специалист должен знать многие варианты и понимать когда что лучше использовать.
А не думали делать замкнутый контур охлаждения? Чтобы воздух с пылью извне не попадал вовнутрь. Внутри вентилятор гоняет воздух через теплообменник, снаружи - другой вентилятор через другую сторону теплообменника.
В качестве теплообменника использовать пару (или двухсторонний) радиаторов, соединенных основаниями? Или даже элемент Пельтье добавить для повышения эффективности. Примерно так делают в небольших винных холодильниках ;).
Абстрактно :) : если на локальном компьютере L делаем ssh -R OP:H:P -p RP RH, то 1) ssh коннектится на удаленный компьютер R по адресу RH на порт RP; 2) на удаленном компьютере R открывает порт OP; 3) поступающие на порт OP компьютера R данные отправляет через компьютер L на компьютер H на порт P (с точки зрения компьютера L).
P.S. Опция -L делает всё наоборот: если на локальном компьютере L делаем ssh -L OP:H:P -p RP RH, то 1) ssh коннектится на удаленный компьютер R по адресу RH на порт RP; 2) на локальном компьютере L открывает порт OP; 3) поступающие на порт OP компьютера L данные отправляет через компьютер R на компьютер H на порт P (с точки зрения компьютера R).
Не совсем. 43022 будет открыт этим ssh'ем на той машине, т.е. на RPI, на которую коннектимся. Всё как описано. Если хотим заходить на RPI:43022 только из локальной сети RPI'я, то и открывать его не нужно.
Соединение явно проходящее через роутер (остальные в нем завернуты) одно: от Vostok на myhome.router.com на порт XXX, указанный в опции -p XXX (или XXX=22 по умолчанию). Его и надо открывать на роутере и пробрасывать на RPI.
Порт ReverseSshServerPort, на который коннектится ssh при запуске команды ssh -tt -i /home/user/.ssh/id_rsa -R 43022:localhost:22 pi@myhome.router.com указывается в опции -p. В данном случае опция отсутствует и порт будет 22.
А порт 22 в параметре -R - это порт на localhost (т.е. на Vostok), на который будут перенаправлены запросы с порта 43022 на RPI.
Т.е. эту команду надо читать так (находясь на Vostok): соединяемся с узлом myhome.router.com на стандартный порт 22 (была бы опция -p - был бы другой порт), на удаленной (remote, -R) стороне (т.е. на myhome.router.com) открываем порт 43022, данные на который перенаправляем на узел localhost на локальной стороне (т.е. с точки зрения Vostok'а) на порт 22.
Да, я думал о такой дуальности, но это немного не то: тогда вместо одной вершины-блока будут несколько ребер, и на каждом придется писать задержку. Что не есть красиво...
Про схемы еще такая мысль пришла в голову. Не удобно определять, если считать длину от вершины графа (элементарного блока) до вершины. А если считать от ребра (шины) до ребра, то уже нормально, хотя и непривычно. Это может быть даже более правильно, т.к. именно ребрам/шинам соответствуют переменные в языка, мы именно ребра/шины именуем. И порты - это частный случай именования ребер.
Понятно. Тогда вопрос: на какого читателя рассчитана книга? С каким научным багажом? Если считать, что на студентов 1-2 курса, только освоивших логику, то задачи "управлять потоками" им еще не понятны. В общем, IMHO перебор сложности на начальном этапе погружения в материал. И, главное, он для дальнейшего понимания материала не нужен.
P.S. Если считать, что читатель уже освоил языки программирования и компиляторы, то, наверное, можно говорить, что арифметические операции будут отображены в такие-то схемы, if-конструкции - в другие. Т.е. описывать одновременно и схемы, и язык программирования/описания схем (а-ля VHDL/Verilog). Только тогда не забыть четко проговорить отличие в семантики таких схем от принятых логических выражений и if-ов в обычных языках (C, Java, Python и т.п.). Но IMHO это более трудный путь.
P.P.S. В общем, я, наверное, повторюсь. По своему опыту не надо стараться внести всё в книгу/статью/диссертацию. Это утяжеляет книгу, не дает неподготовленному читателю понять суть, которая оказывается скрыта за многими деталями. IMHO.
Поменялось ли что-нибудь при инициализации PCI/PCIe устройств, доступ в регистры устройства через BARы и т.п.
Аллоцирование памяти для DMA: в которую и устройство может писать и читать, и ядро, и пользовательские программы (dma_alloc_coherent, dma_alloc_noncoherent, ...), и ещё с IOMMU. А то у меня при переходе на каждое новое LTS ядро что-то да перестает работать. :(
Спасибо!
А другие главы LDD будут? PCI-устройства, работа с физической памятью?
Фундаментальный подход!
Я бы еще предложил покрутить режим сглаживания (anti-aliasing) шрифтов. Например, сглаживание с учетом расположения пикселей мне не заходит: хоть буквы и глаже становятся, но цветовая койма бесит. А если у монитора не такое расположение цветов в пикселе как ОС думает, то вообще фигня может выйти. И степень сглаживания тоже индивидуальна.
Добрый день! Отличная статья, спасибо!
Скажите, а как батареи переживают зимовку в неотапливаемом доме (-30°С и ниже)?
У старших родственников дом в деревне под ВВ. Электричество в целом приемлемое, но бывает (скажем, раз в неделю) вырубается из-за грозы, упавших деревьев и т.п. Живут в основном с весны по осень. Думаю ставить солнечные батареи еще рано, а вот иметь аккумулятор, который вытянет часов 3-6 отключения (насос, холодильник, интернет) хотелось бы. Можете посоветовать с какой стороны подступиться к этому вопросу? Инвертор + батареи это адекватный первый шаг? И какие батареи лучше под такой режим эксплуатации и хранение зимой? Что почитать?
Я начал активно работать в этой области лет 10 назад, и начал с VHDL, т.к. вокруг были люди, которые его использовали, и которые неодобрительно смотрели на Verilog.
Да, VHDL более многословный. Но не так, как пугают: на заре был более многословных, а сейчас - терпимо. Да и почему-то не любят использовать "нестандартизированные" библиотеки типа ieee.std_logic_unsigned , которые заметно сокращают объем кода.
Я смирился с его многословностью: пишу некоторыми синтаксическими шаблонами, к которым привык. Но ни за что не променяю его типы и строгую типизацию. Поэтому с интересом приглядываюсь с SpinalHDL: имеет строгую типизацию и добавляет то, чего мне не хватает в VHDL: параметризации типов, модулей и т.п. Я пока писал только что-то совсем мелкое, и пока не убедил себя на него перейти: у меня нет проблем со скоростью написания многословного кода, т.к. основное время приходится думать что написать, а не писать ;).
P.S. Да, я пишу практически только синтезируемый код с небольшими тестами. Поэтому на богатство Verilog/SystemVerilog и других инструментов по симуляции смотрю равнодушно.
А если использовать пакет ieee.std_logic_unsigned.all, то кода будет поменьше.
Я начал лет на 15 позже, все успокоились, наверное, т.к. std_logic_unsigned нормально поддерживается всеми используемыми инструментами. Рекомендацию слышал, но писать как предлагает numeric_std вообще не захотелось. Явно это были голоса тех, то продвигали Verilog ;)
Я использу ieee.std_logic_unsigned.all, и тогда std_logic_vector можно складывать без приведения.
Да, в VHDL нет расширения до размера результата, а только до максимальной ширины аргументов, но это спорный вопрос что лучше. Больший контроль за разрядностью - меньше ошибок, но чуть больше кода, когда надо разрядность изменить.
P.S. Сразу скажу, что в моих ПЛИС и чипах нет знаковых чисел совсем (вот такие задачи ;)), да и расширения разрядности тоже не вспомню, чтобы требовались, кроме при выдачи в PCIe, где все регистры, видимые из процессора, 32 битные.
P.P.S. В листинге про 2+2 sum потерялось.
Красиво! Но какой-то overkill как "выльем воду из чайника и сведем задачу к предыдущей". FIFO с данными уже имеет внутри себя всю необходимую информацию. Надо только ее достать, что, к сожалению, готовые FIFO не позволяют. Как и многое другое (например, если FIFO стоит перед линией передачи где бывают ошибки, то для переповторов удобно использовать это же FIFO, но тогда нужны 3 счетчика).
P.S. Мой вариант с счетчиком - это по сути и есть FIFO ширины 0, только реализованная руками.
А какое решение Apple предполагает?
При низкой интенсивности можно вместо уровнем '1' кодировать сменой '0'->'1' или '1'->'0'.
Если интенсивность высокая то, то можно завести счетчик выбранных из FIFO пакетов (в кодировке Грея) и чего инкрементировать. А на приемной конце завести счетчик посланных в FIFO пакетов и кредит - их разность. Только в этом случае обратно не один провод, а шина. В каком-то смысле это и есть адреса в FIFO. Примерно так я и делаю, когда надо через PCIe кредитный трафик гнать.
Всё так, можно было не расписывать ;).
Мне нужны были и кредиты, и переход между клоками. Делать две FIFO в ПЛИС, где блоков памяти мало, не целесообразно. Поэтому и делал всё на одной FIFO. И т.к. FIFO большая, то экономить ячейки не стоит.
С одной стороны, чтобы работало и не ломалось можно и не считать стадии конвейера. С другой, если нужна максимальная пропускная способность, то посчитать придется, чтобы конвейер не вставал. Так что мне пришлось бы считать в любом случае.
Наверное не очень аккуратно выразился. С двух местах надо указывать размер FIFO: в самом FIFO, и в счетчике. Можно ошибиться ;). Как можно ошибиться с количеством шагов конвейера (тогда схема с подсчетом кредитов в FIFO сломается).
В общем, я не против предложенной схемы. Она разумна и много где подойдет. Я против возведения ее в абсолют, что больше ничего другого знать не нужно. Если и другие схемы, которые в каких-то ситуациях могут быть лучше.
Но и такое решение имеет право на жизнь: в ПЛИС FIFO на 1 шт. блочной памяти будет иметь зачастую больший, чем нужно размер. Или если FIFO двухклоковое, то напрямую кредит как в Вашем рисунке https://habr.com/ru/post/706484/#comment_25030966 не проведешь. Или бывает нужно пропустить кредитный сигнал через регистр для лучший разводимости, тогда в FIFO надо закладывать запас для максимальной пропускной способности.
Я у себя для таких потоковых задач (в том числе и с мультиплексорами и демультиплексорами), и для мультиплексоров использую а-ля almost_full сигнал: из FIFO вывожу количество свободных мест, из него вычитаю количество регистров на пути данных от источника до FIFO, так и на пути этого управляющего сигнала от FIFO до источника, и если величина положительна, то можно слать. Тогда всё вычисление кредита локализовано у FIFO (а не находится в двух местах, где надо одновременно менять размер FIFO), а источник по сигналу посылает данные.
В общем, специалист должен знать многие варианты и понимать когда что лучше использовать.
Впечатляет!
А не думали делать замкнутый контур охлаждения? Чтобы воздух с пылью извне не попадал вовнутрь. Внутри вентилятор гоняет воздух через теплообменник, снаружи - другой вентилятор через другую сторону теплообменника.
В качестве теплообменника использовать пару (или двухсторонний) радиаторов, соединенных основаниями? Или даже элемент Пельтье добавить для повышения эффективности. Примерно так делают в небольших винных холодильниках ;).
Абстрактно :) : если на локальном компьютере L делаем ssh -R OP:H:P -p RP RH, то
1) ssh коннектится на удаленный компьютер R по адресу RH на порт RP;
2) на удаленном компьютере R открывает порт OP;
3) поступающие на порт OP компьютера R данные отправляет через компьютер L на компьютер H на порт P (с точки зрения компьютера L).
P.S. Опция -L делает всё наоборот: если на локальном компьютере L делаем ssh -L OP:H:P -p RP RH, то
1) ssh коннектится на удаленный компьютер R по адресу RH на порт RP;
2) на локальном компьютере L открывает порт OP;
3) поступающие на порт OP компьютера L данные отправляет через компьютер R на компьютер H на порт P (с точки зрения компьютера R).
Не совсем. 43022 будет открыт этим ssh'ем на той машине, т.е. на RPI, на которую коннектимся. Всё как описано. Если хотим заходить на RPI:43022 только из локальной сети RPI'я, то и открывать его не нужно.
Соединение явно проходящее через роутер (остальные в нем завернуты) одно: от Vostok на myhome.router.com на порт XXX, указанный в опции -p XXX (или XXX=22 по умолчанию). Его и надо открывать на роутере и пробрасывать на RPI.
Спасибо за интересное описание!
По-моему, у Вас перепутаны два 22-ых порта.
Порт ReverseSshServerPort, на который коннектится ssh при запуске команды
ssh -tt -i /home/user/.ssh/id_rsa -R 43022:localhost:22 pi@myhome.router.comуказывается в опции -p. В данном случае опция отсутствует и порт будет 22.А порт 22 в параметре -R - это порт на localhost (т.е. на Vostok), на который будут перенаправлены запросы с порта 43022 на RPI.
Т.е. эту команду надо читать так (находясь на Vostok): соединяемся с узлом myhome.router.com на стандартный порт 22 (была бы опция -p - был бы другой порт), на удаленной (remote, -R) стороне (т.е. на myhome.router.com) открываем порт 43022, данные на который перенаправляем на узел localhost на локальной стороне (т.е. с точки зрения Vostok'а) на порт 22.
Да, я думал о такой дуальности, но это немного не то: тогда вместо одной вершины-блока будут несколько ребер, и на каждом придется писать задержку. Что не есть красиво...
Про схемы еще такая мысль пришла в голову. Не удобно определять, если считать длину от вершины графа (элементарного блока) до вершины. А если считать от ребра (шины) до ребра, то уже нормально, хотя и непривычно. Это может быть даже более правильно, т.к. именно ребрам/шинам соответствуют переменные в языка, мы именно ребра/шины именуем. И порты - это частный случай именования ребер.
Понятно. Тогда вопрос: на какого читателя рассчитана книга? С каким научным багажом? Если считать, что на студентов 1-2 курса, только освоивших логику, то задачи "управлять потоками" им еще не понятны. В общем, IMHO перебор сложности на начальном этапе погружения в материал. И, главное, он для дальнейшего понимания материала не нужен.
P.S. Если считать, что читатель уже освоил языки программирования и компиляторы, то, наверное, можно говорить, что арифметические операции будут отображены в такие-то схемы, if-конструкции - в другие. Т.е. описывать одновременно и схемы, и язык программирования/описания схем (а-ля VHDL/Verilog). Только тогда не забыть четко проговорить отличие в семантики таких схем от принятых логических выражений и if-ов в обычных языках (C, Java, Python и т.п.). Но IMHO это более трудный путь.
P.P.S. В общем, я, наверное, повторюсь. По своему опыту не надо стараться внести всё в книгу/статью/диссертацию. Это утяжеляет книгу, не дает неподготовленному читателю понять суть, которая оказывается скрыта за многими деталями. IMHO.