Raven

Насколько я понимаю, адрес инструкции, вызвавшей exception, будет находиться в mepc.

У вас тактовый сигнал ILA и тактовый сигнал наблюдаемой логики - разные? В этом случае надо принимать в расчет возможность разницы в наблюдаемых диаграммах (проявление неопределенности/метастабильности при сэмплировании наблюдаемых сигналов другим клоком). Кстати, в настройках ILA есть параметр на кол-во стадий DFF синхронизатора на входе (по умолчанию он 0, выключен).

А код тестбенча можете привести?

Вот что говорит об этом Сазерленд в "SystemVerilog for Design" (6.2.1, part "always_comb versus always @*"), основные мысли: 1. always @* does not have combinational logic semantics - и из-за этого много чего может отличаться между результатами симуляции и синтеза 2. @* might infer an incomplete sensitivity list - возможен неполный список чувствительности со всеми вытекающими последствиями (неожиданные latches, отличия между симуляцией и синтезом, а может и вовсе не собраться дизайн): function decode; // function with no inputs begin case (sel) 2'b01: decode = d | e; 2'b10: decode = d & e; default: decode = c; endcase end endfunction The following infers only @(data): always @* begin a1 = data << 1; b1 = decode(); ... end The below infers @(data, sel, c, d, e): always_comb begin a2 = data << 1; b2 = decode(); ... end

Может быть - с произвольными выборками?

Сохраняйте захваченный набор диаграмм в файл. Там есть некоторые неочевидности (как и многое в 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).