dxp

первым делом смотреть состояние потоковых портов — что с ними, готовы принимать-отправлять или tready в нуле. Например, если второе, то скорее всего почему-то затык внутри — кредиты кончились, например, по какой-то причине. Можно повесить счётчик и определить, сколько передано до зависания. Может там на первом же пакете всё падает.

а нету доступа удалённого до хоста, с которого можно к ПЛИС прицепиться по JTAG?

Так хост/железка вам не доступны? Если виснет гарантировано сразу, самое оно ILA подключить и посмотреть состояние PCIe ядра. 5GT/s -- это Gen2 дивайс?

256 — достаточно большой MPS, обычно такое на серверах, на настольных хостах как правило 128. Тут нет ошибки? Что lspci говорит про реальный MPS?

Есть. Их обязательно использовать? А если сравнивать по этой теме, то надо на С реализовать тот же функционал и тогда сравнивать. И при чём тут велосипед и спорткар? Сколько сэкономить? В 2-4 раза или 10%?

Любой профессиональный подход требует основательности, скрупулёзности и упорства. ЯП тоже является инструментом, который необходимо глубоко знать. И вложение в изучение ЯП, который является куда более универсальным инструментом, чем конкретный ассемблер, намного эффективнее. Ассемблер содержит кучу информации частного характера, которая за пределами конкретного процессора не пригодится. А тот же С является по сути портабельным макроассемблером, как тут уже сказали. Это очень низкоуровневая концепция, там просто неоткуда взяться большому оверхеду. И если в прежние времена ещё можно было отнести неэффективность на слабость (тупость) компилятора, то с развитием вычтехники стали появляться и оптимизирующие компиляторы (а это уже где-то вторая половина 1990-х), генерирующие код, обойти руками который было очень непросто. Я по молодости соревновался с IAR v1.40 для AVR, сам тогда пришёл от железа и ассемблера, и был сильно удивлён, что "тупая железка" (РС) генерит точно такие же инструкции, как я бы и сам написал. С этого и возник интерес к С (до этого считал его ЯП высокого уровня, куда, дескать, ему там в такие малыши как AT90S2313 и даже AT90S8515). Настройка опций компилятора делается обычно один раз (потом уже по месту что-то корректируется, если надо) и занимает очень незначительное время по сравнению с написанием кода. А то, что Borland лохматых версий пихал кучу лишнего, не может быть основанием для выводов об ущербности технологии. Кстати, и современные тоже нередко пихают кучу лишнего, просто щас на этого никто не смотрит — ресурсов стало вдосталь (памяти, дискового пространства). И только на ембедде приходится обращать на это сугубое внимание. Да и то далеко не везде (на ембеддед линуксах уже тоже мало кто заморачивается) — преимущественно это осталось в мире МК. * * * Соревноваться на уровне ассемблера вы можете достаточно эффективно на простых процессорах — 8/16-битниках типа AVR, MSP430, PIC. Когда перед вами дивайс вроде того же Blackfin, будете удивлены тому, какой код генерит компилятор: глядя на него в первый момент возникает мысль, что это какой-то наркоман писал — инструкции все поперемешаны. Но когда начинаете писать ровный (по-человечески чтобы выглядело) код сами, то прилетают сообщения о простое конвейера, что, де, вот это значение Р-регистра (регистр-указатель) не может быть использовано в следующей инструкции, т.к. оно не доехало до стадии Execute на конвейере, и т.п. и чтобы избежать простоя, перемещаете загрузку указателя раньше в потоке инструкций... И обнаруживаете, что начинаете писать такой же "наркоманский" код, где команды, составляющие связанную группу действий (например, чтение-изменение-запись переменной в памяти), начинают размазываться по коду и перемешиваться с командами из других групп действий. И тут доходит, что компилятор-то именно это всё и делает. Он "знает" про свойства конвейера процессора и пытается избежать простоев. Т.е. уже на старте компилятор обходит неподготовленного, знающего только ассемблер, человека. Чтобы дорасти до компилятора, тут нужна практика и опыт, который тоже нужно поддерживать. И обойти компилятор тут очень непросто. И даже писать такой перемешанный код тоже весьма утомительно, не говоря уже о его сопровождении. Это пример про относительно простой процессор, в котором просто длинный конвейер. А если взять современные суперскаляры с внеочередным исполнением инструкций и переименованием регистров, где на аппаратном уровне идёт загрузка нескольких вычислительных юнитов, где продвинутые предсказатели ветвлений и т.п., то прокачать владение ассемблером хотя бы до того уровня, который вложили компиляторописатели в инструмент, потребует просто жить в этом мире. А завтра выйдет процессор с другой, обновлённой микроархитектурой (ARM их плодит как горячие пирожки), и всё по-новой, изучать особенности поведения, экспериментировать, исследовать... Когда процессоров было три штуки на всё, в этом, возможно, и был какой-то смысл. В нынешнее время это просто непозволительное расточение времени и сил. При сомнительном результате.

По существу сказать ничего не можете (примерами доказывайте кривизну С/С++ компиляторов), на личности перешли. Ожидаемо.

Нету никаких 2-4 раз. С++ даёт ровно такой же оверхед как и С, а С проигрывает ассемблеру максимум 10-15%, и то смотря где и как. На современных больших процессорах ещё надо постараться написать код эффективнее компилятора: компиляторописатели знают особенности аппаратуры целевого процессора обычно получше рядового программиста, поэтому чтобы оный смог на асме написать эффективный код, надо потратить на это время. Никто в здравом уме этим давно не занимается — сейчас процессоры пекут быстрее, чем их успевают осваивать. А при оптимизации по размеру и на МК сложно конкурировать с хорошим компилятором — он делает неслабую работу по выявлению одинаковых кусков кода, организовывает это в подпрограммы, делает вызовы на них и т.п., руками это делать быстро устанешь. Т.ч. 10-15% в худшем случае. А то и наоборот на практике получается нередко. А если у кого-то бинарник раздуло всяким мусором, так просто надо уметь пользоваться инструментом. К языку и технологии это отношения не имеет.

Это указывает на профнепригодность авторов С++ варианта, не более.

Копайте глубже. Полностью коммерческая. Среди клиентов есть и бюджетные организации, т.к. альтернативы в РФ такого класса продуктов просто нет — прогажено так же как и микроэлектроника. Клиенты не указаны потому, что их очень много, напрямую работают только с очень крупными (типа Газпрома какого-нить), их перечислять смысла нет. Остальные работают через партнёрские организации (интеграторов), коих тоже немало.

Например, тут: https://www.usergate.com/ru

Занудство: скважность — отношение периода к длительности импульса. У меандра скважность 2. Обратная величина скважности — коэффициент заполнения (duty cycle), он у меандра 50%. 🙂

Так если скриптом исполнять, то и там же транслятор запускать. Транслятор написать хоть на Python, не должно быть сложно (парсить с помощью re, формировать выходные строки ещё проще).

Ну, тогда хотя бы до Procise цепочку автоматизировать, а уже финальный шаг в нём. Сильно полегче должно быть.

А почему нельзя это внешним скриптом делать -- от запуска Vivado до финала?