dxp

В ОО языках программирования. В гибридных (вроде С++) - только виртуальные функции-члены.

С параметром ещё можно завести псевдоним типа и использовать его при объявлении объекта. localparam DATA_W = 14; ... typedef logic[DATA_W-1:0] data_t; ... data_t data; Предпочитаю такой стиль. А использование макросов стараюсь минимизировать. Основное их место -- условная компиляция. И передача параметров через командную строку.

Т.е. для AXI могут быть 32 или 64. Или 16. Или 128. Но не могут быть, например, 40. Или 24. А вот для AXIS могут. Возвращаясь к исходному вопросу, ширина шины для AXI в корках получается 32 или 64 (или любая другая, но равная количеству байт по степени двойки, т.е. не произвольная).

Это AXIS. А для AXI? И как закодировать ширину, отличную от количества байт в степени двойки, с помощью сигнала AWSIZE?

По спеке AXI (не AXI-Stream) ширина может быть задана только в кратном 2 количестве байт (задаётся сигналом xSIZE, где x -- A, R). Блоки могут быть любыми, но шина только такой. Вы подразумеваете aresetn как асинхронный? Он не асинхронный, он самый что ни на есть синхронный. А буква a в начале пусть не смущает -- она обозначает, видимо, AXI, а не асинхронность. У них и клок называется aclk. Первый вопрос не понял.

С трассировкой покамест справляется один человек. Разделять тоже можно, если очень надо -- например, разделить зоны ответственности на плате, и каждый делает свою часть: один процессор с памятью, другой -- источники питания. На конечном этапе это можно объединять и доводить до финального вида. Некоторые САПРы поддерживают коллективную разработку непосредственно. Но и без этого оно делается, когда люди в контакте и есть взаимопонимание и работа на результат общего дела. Это важнее технических фич ПО. Со схемой коллективная работа даже проще, т.к. она легко фрагментируются на страницы.

Нету общего рецепта в том, что лучше -- совмещать схематику и разводку или разделять. Когда имеешь дело, например, с небольшой платой чувствительного фотоприёмника, проще самому её и делать (размещение, трассировка), чем объяснять даже квалифицированному PCB инженеру, как и что на ней размещать, где какие цепи критичные и т.п. Но вот на нынешней работе люди делают платы класса материнских с кучей DDR4 3200, QDR, PCIe, 10Gbe, 100GbE, и это таки разные люди для схемы и платы. Потому что это весьма трудоёмко и специализированно, чтобы в одного это эффективно делать. Там и схема неслабая с кучей нюансов, которые надо все иметь в виду, и плата со сложным стеком, контролем импедансов, выравниванием задержек, антипадами и прочим, что требует в том числе и моделирования высокоскоростных трасс. Да, схемотехник умеет платы разводить, как и PCB'шник умеет читать схемы и даже их рисовать. Но специализация (акценты) у них всё-таки сильно различаются. И вдвоём они хорошо друг друга дополняют. Да, сидят они рядом за соседними столами.

Это общие слова. Хотелось бы конкретики. И что значит "для МК"? Правильно ли я понимаю, что, например, для application processors это вполне эффективная система команд? Это в обоих случаях руками написанный на асме код? Или таки через компилятор пропущенный? Вот странно. У меня сведения про эффективность именно ISA и то, как она эффективно приводит к более компактному и быстрому кремнию как раз обратные. Например, у ARM индексы регистров в опкодах меняются от команды к команде, что приводит к появлению мультиплексоров в тракте, а у RISC-V эти индексы всегда одинаковые (это сделано намеренно), что позволяет устранить мультиплексоры совсем. Это приводит к меньшим задержкам в тракте, уменьшает объём кремния, снижает энергопотребление. И таких фишек в RISC-V полно. Я не специалист в этой теме, мой товарищ плотно занимался темой и сделал свой вариант для FPGA, который мы используем. RISC-V -- да, это продолжение развития MIPS, но это уже совсем не MIPS. Это глубоко переработанный вариант, результат анализа десятков и сотен процессорных микроархитектур, при котором были выявлены недостатки и достоинства, что нашло отражение в ISA RISC-V. Вот этот косяк с индексами регистров, который допустил ARM, как раз был выявлен и устранён на уровне ISA. ISA молодая, микроахритектур мало (в сравнении с ARM), инструментарий тоже ещё не дорос (под ARM компиляторы уже вылизаны давно). Но это дело времени. Из первых рук (SiFive) доходила инфа, что их ядро стоит в SoC на базе PolarFire (Microchip нынче), по "калибру" это аналог Cortex-A53. При этом компактнее (следовательно дешевле по кремнию) и экономичнее на 15% при приблизительно равной производительности.

В чём уступает? RISC-V -- это ISA. Кортекс -- ARMv6/7/8, тоже ISA. В чём ISA RISC-V заметно уступает ISA ARM? Можно конкретно, в чём "треш"? В чём "система команд неэффективна, хуже чем у ARM"? Тоже конкретно.

Простейший БИХ может сработать: out += in*k, где k < 1. k нужно подобрать, исходя из частоты сэмплирования и постоянной времени фильтра. По "физике" это аналог RC фильтра первого порядка (интегрирующая цепочка). Т.к. k < 1, если не хочется лезть в плавучку, вычисления можно свести к fractional арифметике.

Виксинтом.

Для любителей Matlab есть эффективная замена: Julia. Синтаксис совместим с Matlab, но при этом штука заточена на эффективность вычислений -- JIT и всякое такое.

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

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

Кому как. Tcl так-то на любителя язык, write-only, более-менее на нём живётся, когда он постоянно в работе, иначе "пишу и читаю со словарём с гуглом". При этом надо в Tcl скрипте как-то указывать, какой именно файл надо парсить (аналог source <file>.tcl). Если оный файл имеет какие-то особенности кодирования (напишет в него кто-нибудь чуть более сложное, чем умеет парсер), то парсер легко может не справиться. Сам парсер тоже надо где-то с собой таскать. Исполняемую среду надо выбрать -- на чём генерить: синтезаторной консолью, симуляторной или вообще из ОС взять. Если нравится Tcl, то на нём же проще эти пару файлов генерить, нежели парсить. Но если уж идти по этому пути, то тут можно и жизнь себе облегчить использованием какого-нить более дружелюбного ЯП (вроде Python) и формата хранения исходных параметров. Имхо.

Насколько я понял, вам необходимо навести некую синхронизацию в проекте между HDL и Tcl. Для этого можно (мы так делаем) генерировать пару файлов -- например, .vh/.svh (Verilog/SystemVerilog) и .tcl/.do для симуляторов, синтезаторов. Содержимое по смыслу одинаковое, но по синтаксису, естественно, разное: // Verilog `define SLON 5 `define MAMONT 10 ... # Tcl set SLON 5 set MAMONT 10 ... Далее в своём tcl/do файле делаете source этого тиклевого файла и анализируете значение переменных. Для удобства использования и чтобы не наделать ошибок, оба упомянутых файла генерируются автоматически сборочной системой (это не суть важно, можно хоть каким-нибудь скриптом) из единого источника -- файла на любом удобном языке (мы используем yaml). Таким образом, поменял в источнике, автоматом пересоздались эти два файла. Синхронизация достигнута.

Проверил. Работает!

Ага, вот в чём дело! Оказывается, оно хочет именно логин. Почта не прокатывает. Зачем тогда эту опцию предлагать? В очередной раз большое спасибо вам за помощь и оперативность!

Попробовал через профиль. Результат тот же:

Ну, так передавайте ВВВ через внешний подключаемый (source <file>) файл, в котором будут все необходимые определения.

Латиницу. Потому и пытался, что не пускает после логаута. Через профиль сейчас попробую, отпишусь.

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

CIS разве не есть вещь плотно завязанная на OrCAD? И может я отстал о жизни, но разве есть нативный порт OrCAD Capture на Linux?

Вот мы пробовали это. Именно интересовал серьёзный инструмент, нативно работающий на линукс. Allegro 17.4, сообщили, переписан на Qt и стал кроссплатформенным. Ориентировано это всё под Redhat и его младшие браться, т.ч. запускать на Ubuntu даже не пытались. Вполне успешно получилось запустить через lxc (контейнер) на Centos7 с пробросом видеокарты, т.ч. работало сносно, особо не тормозило. Делали по этой инструкции: https://github.com/yaminov/allegro-centos7-lxc/wiki. Всё получилось, и Allegro успешно запускалась и работала. Но со схематиком оказалось всё тухло. Расхваливаемый System Capture оказался дном. Может я тупой и что-то не понял, может там какие-то скрытые инструменты есть. Но то что я видел, это убожество и примитив - OrCAD Capture на его фоне выглядит как фотонный звездолёт. Задавал вопросы про него на этом форуме где-то с год+ назад, ничего подробного не сообщили, похоже, что никто тут с ним не работает. А работают все с OrCAD Capture. А это Windows-only. Ну, и вся затея потеряла смысл. С тех пор вяло слежу за темой - вдруг что-то поменялось. Пока вывод такой: нет под линукс приличного схематика для Allegro. К сожалению.

Это всё прекрасно работает там, где надо отладить алгоритм. Но, например, при отладке работы периферии это делается исключительно путём включения этой периферии в железе и проверки того, как оно работает реально. А это изрядная доля работы с МК. Никакими юнит-тестами это не закрыть, особенно если учесть, что периферийные модули имеют "особенности", зависимые от семейства и ревизии чипа - баги. Другой случай, где я с трудом могу представить себе сугубо программное тестирование: доводилось писать GUI на "голом железе" (МК/Blackfin). Очень хорошо легло на ООП С++: event loop, иерархия классов, методы и т.п. Проверяется это путём запуска: что-то добавил-поправил, скомплилось, залилось в проц, тыкаем на кнопки, наблюдаем правильную (или неправильную) работу. Вполне быстро и эффективно получается. Программный тест, который будет осуществлять нажимание кнопок и анализ отклика GUI, это просто на порядке более сложное и трудоёмкое ПО. Таких примеров можно ещё привести немало, и именно из области низкоуровневого программирования, близко завязанного на железо. Да, в мире HDL ситуация несколько иная - там акценты очень сильно сдвинуты в сторону тестирования, и там это 100% оправдано. Даже при работе с ПЛИС (про ASIC и говорить нечего - цена ошибки огромна, поэтому параноидальное тестирование на всех этапах). За это говорит и наличие и популярность в этой области HDL симуляторов, которые являются весьма недешёвым инструментом, но при этом очень популярным - нет без них жизни в этой сфере. В типовом проекте на ПЛИС 99% (а может и 99.9%) проблем выявляется на симуляторе. Все модули, которые возможно, покрываются верификацией. Финальный проект, который собирает все модули в единую систему тоже прогоняется на симуляторе, но это скорее функциональное тестирование, которое проверяет, что всё подключено, ничего не забыто, не перепутано. На полном проекте уже не реально выловить какие-то хитрые баги. Но они, как правило, есть. И запуск в железе уже выявляет какие-то хитрые кейсы, которые крайне сложно воссоздать на симе. У нас был случай, когда возникала ошибка при прогоне в железе. С помощью ILA и "ловушек" в коде удалось локализовать место - это происходило из-за несогласованности на стыке двух модулей, приём проявлялось только при совпадении четырёх или пяти условий. Модули были по отдельности оттестированы и работали правильно. Воссоздать ситуацию на симе не удалось - для этого нужно было подавать на вход пакеты-задания (там через PCIe скачивались данные для обработки на ускорителе вычислений, реализованном на ПЛИС) с определёнными задержками для отдельных пакетов и их групп. И иногда возникало хитрое наложение, т.ч. на стыке модулей возникала несогласованность и терялось последнее слово пакета. В итоге, чтобы убедиться, что это именно то место, просто сделали останов в симе в нужной временной точке и с помощью force активировали сигнал, который предположительно и приводил к сбою. Всё подтвердилось. Внеслись правки, сим повторили с этими же условиями, корректировка кода показала устойчивость к возникшей ситуации, после прогон в железе подтвердил, что ошибка ушла. Наверное, и методами верификации можно отловить подобное - для этого надо гонять на верификации не только отдельные модули, но и их связки. Но это уже увеличение трудоёмкости по экспоненте. Тем более, что заранее не знаешь, какая связка может оказаться проблемной. В проекте десятки модулей, комбинаций их тоже не меньше. Для ASIC дизайна это, возможно (а то и наверняка), оправдано. Но для ПЛИС, имхо, нет. Достаточно довести на симе проект до более-менее стабильно работающего состояния (верификация отдельных модулей, функциональное тестирование всего проекта), после добить уже на проверками на реальном трафике. При прогоне в железе просто пролетают миллиарды пакетов в совершенно непредсказуемых сочетаниях. Никакими тестами на симе это не покрыть. Да и модель хоста на симе описать тоже можно только очень приблизительно, а она очень сложна - у хоста своя "жизнь". Другая крайность, встречал таких неоднократно, - когда люди отрицают полезность симуляторов и программного тестирования, пишут код и отлаживают в железе (SignalTap, ILA). На это больно смотреть. Ну, и излишне говорить, что сложность проектов там где-то околоначальная. Для МК же ситуация качественно иная. Уже забыл, когда в последний раз видел симулятор и его использование. Всё отлаживается либо прогоном на реальном железе, контролируемом через эмуляторы и/или отладочную печать - это касается проверки работоспособности программы в целом и всего, что касается периферии, либо отдельные алгоритмические части тестируются в своём отдельном окружении, зачастую это делается даже на другой целевой платформе - РС, т.к. это удобнее и быстрее. Процент такого да, имхо, весьма небольшой для проектов на МК. Пример, наверное, не очень удачный. Тут больше похоже на ошибку проектирования: в критичных системах целесообразно полностью исключать такие ситуации - фрагментация рано или поздно приведёт к отказу, и спрогнозировать (предсказать) этот случай не реально. Даже если проверять значение указателя, при возврате 0 что делать, когда нажата педаль тормоза и препятствие неотвратимо приближается? Такой ситуации в программе просто не должно быть от слова совсем.