dxp

Какой-то смысл есть. ADI вложили прилично усилий в uCLinux для своего Blackfin, у которого нет MMU (хотя в остальном проц вполне для своего времени норм -- быстрый, кэши и т.п.). Позиционировали они его в том числе и как мультимедийный процессор для построения на его основе разного рода музыкальных и видео плейеров. Если всё это делать на baremetal, то это путь портирования кучи софта, который уже есть, который отлажен и исправно работает -- это разного рода кодеки, конвертеры форматов. А имея Linux -- пусть даже в кастрированной версии uCLlinux, весь этот зоопарк софта заезжает туда практически без изменений. Плюс поддержка файловых систем из коробки. Плюс полноценные сетевые возможности. Плюс GUI. И т.д. Главная проблема uCLinux как системы без поддержки MMU в том, что она очень уязвима для сценария, когда на ней запускают сторонние приложения, когда любое приложение может в случае ошибки завалить всю систему. Поэтому в пользовательские OC uCLinux не пошла. Но для сценария, когда на ней строят закрытую платформу, не предназначенную для запуска стороннего софта, когда к коду ОС и приложений имеет доступ только ограниченный круг разработчиков дивайса, картина существенно меняется. Да, на этапе разработки ошибки приложений будут по-прежнему заваливать ОС, но это обычное дело -- когда пишут драйвера (модули ядра) полноценного Linux, ситуация точно такая же. А когда разработка закончена, ПО оттестировано, у потребителя уже никаких дополнительных рисков нет -- он использует дивайс в рамках, предоставленных производителем. Другое дело, что профита от мощных процов без MMU при нынешнем развитии микроэлектроники (чипдизайна и технологий производства) почти нет -- стоимость MMU исчезающе мала на фоне остального, а преимущества, которое оно даёт, очень большое, начиная от поддержки разных моделей памяти (Normal, Device, Strongly-ordered, в терминологии ARM) и заканчивая аппаратной трансляцией адресов (защищённый режим работы памяти). Поэтому по факту uCLinux уже отошёл в историю.

Разве можно MMU отключать, если он есть? Или речь про отключение только трансляции адресов?

Matlab/Python не для моделирования в смысле симулятора (Matlab-то тоже не симулятор, не про Simulink речь), а для моделирования алгоритма. Ну, средствами языка программирования -- высокоуровневые ЯП для этого удобны.

Насколько понял, смысл следующий: Идеальные компоненты дают возможность моделировать именно принцип, алгоритм, но уже детально. При этом паразитные параметры, которые учитываются моделью, тут не мешают. Отладив алгоритм, можно перейти к реальным моделям в другом мощном бесплатном симуляторе, имея референсную идеальную модель, и в нём уже подбирать компоненты так, чтобы их неидеальные свойства портили картину в пределах допустимого. Идеальные (сиречь, упрощенные) модели позволяют существенно увеличить скорость моделирования. А учитывая, что и модели специальные, то они тоже оптимизированы для сокрости. Т.е. это инструмент первой пробы. Когда от расчётов осуществляется переход к моделированию, то на первом этапе вот такой симулятор может оказаться очень кстати. P.S. Сам не пользовался. 🙂 Может просто не дорос -- пока хватало моделирования с помощью Matlab/Python.

Имеется в виду, что клок -- это сигнал, который присутствует всегда, независимо от того, идут данные или нет -- например, сигнал SCK в SPI -- это не клок, а просто сигнал синхронизации. Поэтому к начальной фазе клока привязаться нельзя, а только к тому или иному фронту. Поэтому инвертирование для клока по барабану -- дальнейшая логика "привяжется" к нужному фронту или PLL (если она там) зацепится за как надо. Я про 600 ppm выше и писал -- это как бы и указывает, что если PCIe физику можно тактировать от разных источников, то про "переполюсовку" тут вообще говорить не приходится. 🙂 Про джиттер тоже, вроде, были чиселки в спеке, "но это не точно" (с ходу не вспомню).

Ну, так это имеет смысл только для данных, не для клока.

А что такое "полярность тактового сигнала"? Это ж просто меандр, где у него полярность? Может начальная фаза имеется в виду, что она должна приходить на устройства, тактируемые от одного источника, в одной фазе? Но если так, то PCIe вообще может работать от разных источников тактовой частоты, которые не разбегаются по частоте больше, чем 600 ppm, какая уж тут начальная фаза может быть, если клоки полностью асинхронные.

rebase -- мощная штука при правильном использовании: позволяет держать историю красивой (когда она состоит из комитов слияния, где чётко видна этапность добавления фич и фиксов, по такой истории легко ориентироваться -- быстро находится добавление той или иной фичи, а по комитам слитой ветки видна локальная история разработки фичи, ничего не смешивается) при работе группой. Где пригождается rebase, лучше показать на примере. У нас процесс построен так (он рекомендованный, насколько знаю): есть общая ветка разработки, она постоянная, она содержит только целостные комиты, т.е. состояние проекта таково, что он собирается и работает. Основной смысл этого в том, чтобы любой участник команды мог взять крайний комит за основу для разработки своей фичи, и у него всё будет собираться, не будет чужих ошибок, которые будут ему мешать развивать и собирать своё. Для этого создаётся временная ветка (feature branch -- FB). Сливать в общуюю ветку может только её мейнтейнер, у остальных таких прав нет (это обеспечивает целостную базу как отправную точку для всех участников проекта независимо от их дисциплинированности -- главное, чтобы ментейнер не был раздолбаем и добросовестно проверял перед слиянием -- это несложная работа, её вообще можно автоматизировать, но у нас руки пока не дошли, не обременительно запускать сборку/тесты руками). Работа участниками проекта ведётся параллельно. Когда фича готова к слиянию, её автор создаёт pull/merge request на слияние этой FB в общую. Перед этим он делает rebase на общую ветку, чтобы объединить свою фичу с кодом общей, которая за время работы над FB могла уйти вперёд (как правило так и происходит). Мейнтейнер проверяет целостность кода, запуская сборку, тесты. Если всё успешно, FB сливается в общую с комитом слияния (git merge --no-ff). Результатом будет чётко видная в истории ветка FB со всеми своими комитами, слитая в общую через комит слияния. Делать объединение общей ветки с FB обязательно -- на этом этапе вылезают всякие конфликты, ошибки и т.п. Объединять можно двумя способами: через merge и через rebase. Если делать через merge, то это нарушает описанную выше "красивость" истории (которая нужна далеко не только из эстетических аспектов, но является мощным подспорьем для ретроспективы кода). rebase позволяет держать локальную историю разработки фичи компактно и целостно, не смешивая с комитами других веток. Да, это изменяет историю развития проекта в смысле строгой хронологии, но для работы с кодом гораздо важнее вид с точки зрения добавления фич и фиксов, когда видны этапы работы, а не вид с точки зрения последовательных дат комитов. Получается, что хотя работа участниками проекта во временном аспекте ведётся параллельно, в истории комитов результаты их работы (фичи/фиксы) добавляются строго последовательно, что убирает путаницу: вид такой, как будто все работали друг за другом по цепочке, дожидаясь результата (слияния) от предыдущего члена команды. В описанном процессе rebase пригождается не толькло при работе командой. Ровно то же самое и когда работаешь один, если приходится параллельно вести больше одной FB (например, при разработке фичи отвлекаться на правку багов, создавая для них свои ветки).

Насклько знаю, у ртути ветки не такие лёгкие и бесплатные, как в гите. Там даже какую-то нахлобучку добавляли, которая имеет схожую реализацию -- перемещаемые метки. Общего у ртути и гита то, что они обе системы с локальным репозиторием. Про остальные две не знаю, но низкая известность и популярность говорят сами за себя: мало сообщество, качество инструмента напрямую зависит от количества использующих и т.п. Есть Bazaar, тоже одно время интенсивно развивалась/продвигалась, но на сегодняшний день по факту сдулась (она на Python реализована, как я понял, там серьёзные вопросы с производительностью, особенно на больших проектах). Т.ч. систем управления версиями много всяких, это да, и какие-то в чём-то могут безоговорочно превосходить остальные, но мы говорим о выборе рабочего инструмента, на который претендуют только хорошо проверенные в деле, сиречь популярные, системы. По совокупности гит рулит.

Для этого надо делать резервное копирование. Некоторые люди считают, что система контроля версий git служит и для этого, но это заблуждение. Удалённые репозитории для публикации и обмена, а не для хранения резервных копий. Например, вы можете публиковать далеко не все ветки, которые есть у вас. И эти локальные ветки в случае утери локального репозитория потеряются безвозвратно. А пушить всё подряд на удалённый сервер -- так себе практика, оно не для этого предназначено. Кстати, именно поэтому git -- это система управления версиями с локальным репозиторием, а не с распределённым, как её частно называют. Никакой распределённости репозитория реально нет, а есть только локальные, которые могут обладать уникальным содержимым, которое не может быть восстановлено в случае утраты из репозиториев других участников проекта. Кроме того, в рабочих материалах могут находиться какие-то временные файлы, которые не удостоины того, чтобы попасть в истоирию, но которые в моменте важны, их утеря может создать препятствия в работе. Поэтому регулярное резервное копирование рабочих материалов и решает все эти проблемы. У меня оно делается автоматически каждую ночь по расписанию (комп вы выключается).

Раз такой открытый обмен мнениями, то позволю себе. Оценка будет жёсткая (любителям svn не понравится), но зато правдивая: если сравнивать git vs svn в контексте именно управления версиями, то git является системой управления версиями как таковой, а svn нет. svn, cvs, Perforce и все подобные системы с центральным репозиторием являются скорее системами инкрементального архивирования с функциями менджмента кода (особенно Perforce). Главное, что отличает git от перечисленных и делает его эффективным имеено как систему управления версиями -- это способность лёгкого, быстрого создания веток и их эффективного слиния хоть методами merge, хоть rebase. Именно такие ветки (которые по сути ветками и не являются -- это традиционное, устоявшееся название, а по сути это просто перемещаемые вместе с "головой" (HEAD) метками) и позволяют бесплатно (ничего не внося в код, не плодя копий) вести отслеживание изменений кода. git позволяет делать реально атомарные комиты -- т.е. когда в комит входят изменения, касающиеся только чего-то одного. Это очень важная штука: такие комиты можно легко таскать между ветками, их можно отменять, не ломая других фич. Вот эта схема с индексом (stage) именно для этого и предназначена (когда в начале не понимал этого, тоже раздражало, что вместо просто commit надо ещё в add в индекс делать, хорошо, что хоть опция -a там была 🙂) : нередко бывает, что изменения кода в одном файле относятся к разным по смыслу фичам/фиксам, и пихать это в один комит неправильно -- потом его ни отменить (нечасто это надо, но бывает), ни перетащить изменения в другую ветку, где они актуальны уже сейчас (а другие изменения и этой ветки, где комит, пока не нужны, они ждут своего слияния в общую ветку). Так вот, git позволяет добавить в индекс выборочно правки из файла, не трогая другие. И так, накидав в индекс, изменения, связанные по смыслу, из разных файлов, можно получить, закомитив, тот самый атомарный комит. Делается это командой git add -i. Существует вполне удобный GUI инструмент для этого -- git-cola, в ней можно прямо выделять в файле нужные строки изменений и добавлять в индекс (или удалять из индекса добавленное по ошибке). Push после каждого комита тоже делать совершенно не нужно. git -- это система с локальным репозиторием, самый главный реп -- это тот, с которым вы работаете, который лежит у вас рабочем проекте. Push -- это просто способ опубликовать ваши изменения (серверов для публикации может быть сильно больше, чем один 🙂 ). Публиковать надо тогда, когда это необходимо, и не ранее. Пока всё лежит локально, можно менять историю изменений, устраняя ошибки при комитах. Это позволяет легко держать историю проекта красивой и удобной для ретроспективы. Это крайне важная штука -- по такой истории можно быстро эффективно найти практически всё (пример такой истории можно посмотреть по ссылке ниже), по ней легко разобраться, когда что происходило и быстро "вспомнить" нюансы ушедшего в прошлое процесса разработки. К сожалению, тот же svn не позволяет ничего из вышеперечисленного. Ветвление в нём -- это боль. Поэтому типовая история проекта в svn (cvs или Perforce) -- это ровная цепочка комитов, глядя на которую, не понятно, где когда что делалось -- нужно ползать по всем звеньям цепочки и искать, вчитвываясь в комментарии. И комиты там редко бывают атомарными, обычно комит в svn -- это целый список несвязанных между собой изменений. Да, конечно, и в svn можно стараться делать короткие атомарные комиты, но это технически непросто делать, когда разные по смыслу изменения присутствуют в одном файле. Есть пара моментов, где системы svn/Perfoce сильнее, чем git: связь с внешними репозиториями; работа с нетекстовыми файлами большого размера. Оба преимущества проистекают из того, что svn/Perforce основаны на нативной файловой системе: единицы слежения за изменениями -- это файлы, ветки -- это директории. Это позволяет легко цеплять сторонние репозитории как директории (хоть целиком, хоть фрагменты) через svn:externals в svn или mapping в Perforce (этот в этом вопросе вообще очень крут). В git же единицей слежения является не файл, а слепок проекта, т.к. совокупность файлов. Директории в нём вообще ничего не значат и учитываются просто в путях файлов, за счёт чего и поддерживается файловая структура с директорими (но закомитить пустую директорию не получится, т.к. для git директория не является ценностной единицей). А submodules в git -- это не самая приятная штука, особенно, когда дело доходит до того, чтобы их удалять/переносить. Уже не впервые высказываюсь на эту тему. Вот тут подробнее про использование: Исходя из вышесказанного, можно сделать определённый вывод: если требуется гибкое и удобное версионирование, то git тут вне конкуренции. Это относится в первую очередь к разработке кода. А вот, например, для схематики/PCB отлично подходит svn, т.к. там обычно никакого ветвления (и слияния, которое в случае с нетекствыми файлами очень затруднительно) не требуется, а нужно инкрементально сохранять последовательные изменения проекта.

Не-не, на том сервере 5 PCIe Gen3 x8 торчало непосредственно из CPU (4 выходили слотами в сторону морды (19" стоечное исполнение) -- для подключения NIC, 1 по райзер плату, туда накопители цеплялись). Т.е. PCIe линки были непосредственно подключены к CPU. 29 секунд он думал до выдачи BIOS screen. Это точно до начала опроса внешних периферийных устройств.

Пару слов про требование готовности PCI устройство. Согласно спеке ATX устройство должно быть готово к работе (енумерации аппаратурой хоста) не позднее 100 мс. Это довольно малое время, учитывая сложность современных устройств. В начале работы с PCIe сильно парился по этому поводу, потому что тот же Artix 200 при всём желании не успевал загрузиться за 100 мс чисто физически на максимальной скорости при внешнем тактировании (там что-то порядка 130 мс уходило). Но потом выяснилось, что требование-то это никто не отменял, но реально оно давно не соответствует необходимости. Оно возникло во времена 386 РС, когда PCI внедрялся в эту платформу, тогда процы были маленькими, системные платы относительно простыми, объёмы памяти смешными (по нынешним временам), там процессорная система через 100 мс уже была готова чекать конфигурацию периферийных устройств. Современный РС при подаче питания занимается самодиагностикой (и прочим) несколько секунд! Это настольный. Замерял на серверной платформе (какой-то Xeon, не самый современный), там вообще 29 секунд он находился где-то внутри себя и только после этого только появлялся BIOS screen. Наверное инициировать загрузку по окончании PERST# идеологически неверно (а правильно было бы формировать сигнал конфигурирования из него внутри платы), но учитывая тайминг готовности современных CPU, я бы не опасался, что Artix 25 не успеет загрузиться до начала енумерации.

Сам-то по себе CDR вполне исправно работает -- и при загрузке, и потом при работе не сбивается. Если только: Это вполне бы объяснило. Подытоживая, видятся две причины. Логическая: то, что вы упомянули (выше в цитате) -- BIOS ведёт себя по-разному при "холодном" старте и при "тёплом". Физическая: при перезагрузке присутствует какое-то аномальное поведение цепей питания или сброса (например, длительность импульса или фронтов сигнала некорректные). Причём, не фатально аномальные, но так, что конкретной плате этого хватает. Чёткая повторяемость эффекта (как я понял, это происходит каждый раз при описанной последовательности действий) голосует за первый сценарий. Возможно, при перезагрузке BIOS инициализирует аппаратуру материнки не в полном объёме, как это имеет место при "холодном" старте. Но против этого говорит то, что другие платы в этом сценарии работают, т.е. дело, получается, не в логике работы RC. А ОС какая? Если Linux, может в логе загрузки что-то есть на эту тему?

Непростой случай. Из общего описания очевидно, что тут нет проблем с физикой в смысле передачи сигналов. И тем не менее причина где-то на физическом уровне, раз оно зависит от физического переставления платы в другой слот и от самой физической платы (конкретного экземпляра). Интересно, есть ли повторяемость в другом хосте с MSI материнкой, т.е. это зависит именно от производителя материнки или от конкретного экземпляра. Так же интересно, одна из пяти -- это статистика: 1000 плат и 200 вот таких, или просто есть пять плат и одна себя так ведёт. Из области предположений: такое поведение можно было бы объяснить, если, скажем, грешить на питание или сигнал сброса платы (если он задействован) -- например, при перезагрузке по кнопке там возникает короткая просадка, которая не сбрасывает плату до конца, и внутренняя аппаратура PCIe залипает в каком-то состоянии, которое препятствует успешному линку.

ну, и в итоге в каком состоянии LTSSM залипает?

Возможно, полезно посмотреть на LTSSM -- в каком состоянии оно зависает. Если линк пропадает, наверняка дивайс пытается поднять линк заново, но почему-то ему этого не удаётся. Состояние этого автомата может подсказать ответ или направление поиска. Но это не точно. 🙂

Вы хотели сказать "непакованный массив и пакованный массив"? Вообще-то, разница есть. В непакованном массиве, объявленном традиционным способом (когда младшие по порядку элементы индексируются от 0), такая запись поместит старшие элменты массива (если N равеняется размеру элемента) в старшие биты RHS: А для пакованного массива туда попадут младшие биты -- будет изменён порядок следования, как тут: только тут по 4 бита упаковка ведётся, но суть ясна. Картинки и примеры отсюда: https://www.amiq.com/consulting/2017/05/29/how-to-pack-data-using-systemverilog-streaming-operators/ https://www.amiq.com/consulting/2017/06/23/how-to-unpack-data-using-the-systemverilog-streaming-operators/

Согласен. Но тогда задачу надо было формулировать как: "...коэффициент передачи тока базы транзистора находится в диапазоне 40..120, найти диапазон токов, протекающих через нагрузку...". И по сути она всё равно сводится к исходной, просто вместо одного значения в конечную формулу надо подставить два.

Разумеется, все присутствующие это понимают. Это учебная задача, цель которой выявить понимание схемы и принципов работы её элементов. На практике, конечно, никто именно так схемы не проектирует, обычно требуется обеспечить "не меньше". Но если нужно точно, то схема уже другая (составной БТ или полевик). Ещё и ОУ надо на практике правильно подобрать (напряжение смещения, входные токи, их разность, температурные дрейфы и т.п.). Но это на практике. А для обучения годится и этот вариант с бетой 50 и идеальным ОУ -- это просто частный случай, фрагмент практической реализации. Инженер должен уметь делать декомпозицию задачи на более простые. Если на этом примере обучающийся правильно поймёт принцип работы схемы и способ вычисления тока, то он легко поймёт, что при реальной бете 40..120 (а в диапазоне температур 20..150) ток в нагрузке будет гулять в диапазоне... который можно посчитать, взяв минимальное и максимальное значения беты. Меня больше удивляет, что за решение такой задачи уже обещают оценку 5. Имхо, уровень сложности задачи не соответствует высшему.

Если сопротивление нагрузки будет, скажем, 10к, то ток через неё будет уже совсем не 1.96 мА.

+1. Делал такое ещё на Quartus'е лохматых годов (2005-й), всё прекрасно пробрасывалось из внутреннего по иерархии модуля на топ через inout.

Учитывая номиналы элементов, задача решается в уме, мелкая заковырка только в необходимости учёта тока базы. Автор темы, если хочет иметь специальность по теме, обязан решить её сам, задача элементарнее некуда. А если ему нужен просто документ о ВО, то это совсем другая история, и советы участников форума ему бесполезны.

Вектор -- синтезируемый тип в V. В SV это называется пакованный массив (packed array). (если уж наводить строгость). Ну, отдельного встроенного булевого типа в V/SV нет, имелось в виду, что автоматически приводится к однобитному значению, пригодному для анализа на true/false.

numpy в целом неплох. Но там есть не всё, и кое-что не устроило по быстродействию. Конкретно построение гистрограмм яркостей пикселов -- в numpy функция построения гистограммы навороченная, универсальная, умеет много чего, что нам не нужно было. И скорость работы получалась так себе. В итоге простой цикл на С работал в разы быстрее. Этим и удовлетворился. Matplotlib -- конечно. scipy -- не помню, вроде что-то использовали, но мало (поэтому и не помню). pandas -- нет, не пришлось. Со сменой работы тематики изменились, давно этим не занимюсь. P.S. Сам проект этот лежит где-то на github. Могу поискать, если интересно. Но там поразбираться немного придётся, не всё так просто и на виду.