Raven

Сохраняйте захваченный набор диаграмм в файл. Там есть некоторые неочевидности (как и многое в Vv :-) ), но все решаемо, и после некоторых проб и ошибок вы это освоите. Мне доводилось это делать, чтобы сохранить иллюстрацию проблем в дизайне для клиента.

Попробуйте поизучать остальные параметры и qualities объектов "labtools" и вашего "current_hw_target" (это JTAG-адаптер) - возможно, там можно что-то нащупать. Кстати, а почему вас вообще напрягает эта проблема? Зачем вообще снимать питание с платы при проведении конкретной серии отладки на ней? Можно ведь зафиксировать результаты (сохранить в файл), и тогда уже выключить. Потом данные можно опять загрузить для просмотра.

Вчера буквально пробегало мимо: Intermittent configuration failures can occur when the FPGA is power cycled and the programming cable is connected Ситуация та же, но рассматривается как другая проблема. Тем не менее, там есть такой интересный фрагмент, подсказывающий решение по топику: Potential Work-arounds include the following: 1) Set the following parameter to disable the power up detection set_param labtools.auto_update_hardware 0 Note: You need to create a Vivado_init.tcl script and add the above parameter in it.

Насколько я понимаю, дешевизна объясняется тем, что главный чип - б/у, после выпаивания. Продаван вроде как проверяет платы после изготовления. Так что, если плата предназначена для опытов в лаборатории - то можно рискнуть. Если окажется нерабочей - можно добиться возврата денег.

Проект FPGA будет? Или предлагаете все додумать самим?

А зачем все вызывать из Квартусовского Tcl-shell через прокладку exec? Может, попробовать вызвать нативнее - прямо из командной строки Win (вроде как jtagconfig.exe - исполняемый файл), или из Квартусовской CygWin-среды? Последнее лучше запустить как "Nios II Command Shell.bat" (там уже все хорошо обустроено, хотя в довесок идет ниосовский обвес), но и если просто запустить Cygwin.bat - тоже должно пойти.

Работаем с сетевыми адаптерами через Pcap-драйверы Но иногда требуется не просто работать с сетью, а делать это с предопределёнными параметрами, будь то расстояние между пакетами либо какое-то нестандартное их содержимое. Понятно, что речь идёт не о повседневной жизни, а об отладке либо тестировании проектов. В этом нам поможет работа через Pcap-драйверы. Например, через драйвер Npcap, устанавливающийся вместе с программой Wireshark.

Это не загрузка флэш. Показан лог программирования, "прошивки" флэш bit-файлом FPGA (для последующего автоматического конфигурирования FPGA этим проектом после включения питания). Надо все-таки аккуратнее быть с терминологией, а то непонятно, о чем идет речь. Кстати, а после этой прошивки вы производили загрузку FPGA из флэш? Это можно сделать либо выключив-включив питание платы, либо в этом же инструменте, выбрав в контекстном меню что-то вроде "Boot from configuration FLASH".

Ну, для начала, это не мои статьи и не мой сайт. Статьи размещены на сайте уважаемого KeisN13 . Я просто ответил. "Все грузится" - что здесь имеется в виду? FPGA грузится, или Microblaze запускается? Он все-таки стартует, грузится и даже зажигает светодиод? Или нет? Если да, значит, с ресета снимается, но потом что-то идет не так. Нет, блок "Processor System Reset" не мог соптимизироваться, уже хотя бы потому, что к нему подключены другие источники ресетов: clk_wiz_1 и mdm_1. Причина неработоспособности первого варианта в другом. Если хотите докопаться до сути, поисследуйте соотношение сигналов ресетов (входных и генерируемых блоком формирования системных ресетов), моментов их снятия и начала оперирования Microblaze на шине с помощью ILA. Например, если в системе есть блок SDRAM, то он довольно долго инициализируется, а обратной связи от него к блоку ресетов на приведенном фрагменте я не вижу. Но возможно, что причина какая-то еще более простая. Умение находить корень проблемы - важная составляющая навыков любого инженера. А тут еще такой удобный инструмент есть - ILA. Так что время не будет потрачено зря. Дополнение. А точно в варианте 1 блок xlconstant_0 генерирует лог.1? Может, все-таки 0? Проверьте в свойствах блока.

Входы ext_reset_in и aux_reset_in как раз для того изображены с кружочками, чтобы показать их инверсную логику (т.е., что они active low). Так что подача на них лог.1 - это подача пассивного уровня, чтобы эти входы не болтались в воздухе (т.е., не были floating). Вернее, это для того, чтобы была определенность с сигналами на этих входах (ведь иначе это сделает Vivado, а зачем же нам лишняя произвольность в таком чувствительном вопросе, как reset).

Мысль была лишь в том, что предъявлять претензии по производительности к SCR1 в сравнении с Cortex-M3 - это некорректно. Разные весовые категории.

GCC for ARM - вещь уже устоявшаяся, там особых улучшений ждать не приходится. Другое дело - GCC for RISC-V, тут еще большое пространство для улучшений, ведется работа, и каждый новый релиз добавляет что-то заметное. В общем, надо использовать свежатину. Супротив Cortex-M3 надо было выставлять SCR3, по крайней мере (а может - и SCR4, надо смотреть их микроархитектурные параметры), а не SCR1 - ядро начального уровня.

Да, интересный материал. Они вообще проверяли на GCC 7.x, что для 2019-2020 уже несколько странно (вероятно, он был выбран из-за доступных метрик по ARM). Но уже даже при таком раскладе многие компании сочтут плату в +11% code size вполне приемлемой при существенном уменьшении стоимости роялти за ядро. Да и вообще, разница в 11% не выглядит подавляющей. И это при том, что оптимизация по размеру влияет также почти на все остальные важные характеристики кода: производительность, потребление и т.п. (и в презентации тоже это отмечают). Так что надо, ко всему прочему, еще и общий системный баланс рассматривать.

Со времен GCC 8 поддержка в нем RISC-V улучшилась, так что сравнивать надо на чем-то более свежем.

А какие констрейнты применены?