Tik31

Проблема решилась. Причина: подтяжка линии MISO была к 0, d то время как AWBoot ожидает dummy байты как 0xFF

Приветствую. В отлаживаемой плате необходимо выполнить загрузку Linux из SPI NAND памяти (25W01GVZEIG Winbond). Само ядро собрано и протестировано путем запуска из ОЗУ. Проблема возникла при загрузки из NAND. AWBoot выдал следующее сообщение: [I] AWBoot starting [E] SPI-NAND: unknown mfr:0x00 dev:0x00ef [E] SPI-NAND: flash not found [F] SPI-NAND: loading failed При этом 0xef - это MFR для Winbond (Сверили в исходниках на AWBoot и DS на микросхему). При подключении к процу через xfel, микросхема NAND определеяется, читается и пишется. Возможно кто-нибудь сможет предложить дальнейшее решение проблемы.

Здравствуйте! Продолжаю разбираться с написанием констрейнтов для текущего проекта (Polarfire Microchip). В этот раз проблема связана с ограничениями для SPI ядра (частота шины - 50 МГц, SPI - 25 МГц). Мною (на основе примера) был подготовлен следующий файл с ограничениями. ################################################################# # Определение частоты ################################################################## # Частота системной шины - 50 МГц. Максимальная частота SPI - 25 МГц set clkSysPeriod 20 set clkSpiPeriod 40 create_generated_clock -name SCK \ -divide_by 2 \ -source [get_pins proc_cluster_i/coreSPI_wrap_i/corespi_i/USPI/UCC/spi_clk_out/CLK] \ [get_ports sck] ################################################################# # Задание входных и выходных задержек ################################################################# set trace_delay_clock 0 set trace_delay_mosi 0 set trace_delay_miso 0 set trace_delay_ss 0 set mosi_setup 2.0 set mosi_hold 2.0 set ss_setup 3.0 set ss_hold 3.0 set mosi_max_delay [expr {$trace_delay_mosi + $mosi_setup - $trace_delay_clock}] set mosi_min_delay [expr {$trace_delay_mosi - $mosi_hold - $trace_delay_clock}] set ss_max_delay [expr {$trace_delay_ss + $ss_setup - $trace_delay_clock}] set ss_min_delay [expr {$trace_delay_ss - $ss_hold - $trace_delay_clock}] # Задание Tco для MISO (см. datasheet) set Tco_Max 8.0 set Tco_Min 0.0 set miso_max_delay [expr $Tco_Max + $trace_delay_clock + $trace_delay_miso] set miso_min_delay [expr $Tco_Min + $trace_delay_clock + $trace_delay_miso] # Данные из FPGA изменяются по заднему фронту частоты SCK и защелкиваются по переднему во Flash set_output_delay -clock [get_clocks {SCK}] -clock_fall -max $mosi_max_delay [get_ports {mosi}] set_output_delay -clock [get_clocks {SCK}] -clock_fall -min $mosi_min_delay [get_ports {mosi}] set_output_delay -clock [get_clocks {SCK}] -clock_fall -max $ss_max_delay [get_ports {ss}] set_output_delay -clock [get_clocks {SCK}] -clock_fall -min $ss_min_delay [get_ports {ss}] # Данные из Flash изменяются по заднему фронту частоты SCK и защелкиваются по переднему в FPGA set_input_delay -clock [get_clocks {SCK}] -clock_fall -max $miso_max_delay [get_ports {miso}] set_input_delay -clock [get_clocks {SCK}] -clock_fall -min $miso_min_delay [get_ports {miso}] ################################################################# # Multi-Cycle ################################################################# set multiCycleCount [expr {int(ceil($clkSpiPeriod/$clkSysPeriod))}] set_multicycle_path -setup $multiCycleCount \ -to [get_ports {mosi}] set_multicycle_path -hold [expr {$multiCycleCount - 1}] \ -to [get_ports {mosi}] set_multicycle_path -setup $multiCycleCount \ -to [get_ports {ss}] set_multicycle_path -hold [expr {$multiCycleCount - 1}] \ -to [get_ports {ss}] set_multicycle_path -setup $multiCycleCount \ -through [get_ports {miso}] \ -to [get_clocks {clk50}] set_multicycle_path -hold [expr {$multiCycleCount - 1}] \ -through [get_ports {miso}] \ -to [get_clocks {clk50}] Системная частота задается в другом файле и имеет вид: # Входная тактовая частота create_clock -name {clk} -period 20 -waveform {0 10 } [ get_ports { clk } ] # Входная частота JTAG create_clock -name {tck} -period 166.67 -waveform {0 83.33 } [ get_ports { tck } ] # Частоты SYS_PLL create_generated_clock -name {clk125} -multiply_by 5 -divide_by 2 -source [ get_pins { pll_0/PF_CCC_C0_0/pll_inst_0/REF_CLK_0 } ] -phase 0 [ get_pins { pll_0/PF_CCC_C0_0/pll_inst_0/OUT1} ] create_generated_clock -name {clk50} -multiply_by 1 -divide_by 1 -source [ get_pins { pll_0/PF_CCC_C0_0/pll_inst_0/REF_CLK_0 } ] -phase 0 [ get_pins { pll_0/PF_CCC_C0_0/pll_inst_0/OUT2} ] После P&R и Timing Verify я получил нарушение по Hold В данном очтете мне не понятно откуда берется +20 нс (Multicycle), если я задал: set_multicycle_path -hold [expr {$multiCycleCount - 1}] \ -to [get_ports {mosi}] Libero корректно воспринял конструкции как -setup 2 -hold 1. Ориентировался я на картинку ниже

Пишу для Microchip. Нашел в UG: производитеь рекамендует использовать set_clock_group.

Спасибо за ответы. Единственное, как мне кажется, это применение фальш путей вместо асинхронных групп позволит выявить при анализе пути не проведенные через CDC.

Здравствуйте! Имеется мультиклоковый проект с передачей данных из одного домена в другой. Необходимо сформировать файл ограничений. Для синхронизации сигналов, передаваемых между доменами, применяется стандартный 2FF синхронизатор. module sync #( parameter int unsigned STAGES = 2 ) ( input clk_i, input rst_ni, input serial_i, output serial_o ); logic [STAGES-1:0] reg_q; always_ff @(posedge clk_i, negedge rst_ni) begin if (!rst_ni) begin reg_q <= 'h0; end else begin reg_q <= {reg_q[STAGES-2:0], serial_i}; end end assign serial_o = reg_q[STAGES-1]; endmodule В качестве ограничений изначально я хотел использовать команду вида: set_false_path -to [ get_pins { */sync_inst/reg_q[0]/D} ] Однако во время изучения вопроса я обнаружил, что некоторые источники указывают, что нужно применять конструкцию вида: # Период принимающего домена set BCLK 10 set_max_delay $BCLK -to [ get_pins { */sync_inst/reg_q[0]/D} ] Сейчас у меня сформировалось следующее мнение: Если я передаю отдельный сигнал, не связанный с другими, то мне следует использовать set_false_path. Если же я передаю, например, пару сигналов (DATA, WE), то нужно использовать set_max_delay, чтобы сигналы достигли приемника в пределах одного такта (Мне почему-то кажется, что я не верно это понимаю). Прошу подтвердить или опровергнуть корректность моих суждений.

Спасибо. Решение было следующее: послу загрузки программы в ddr необходимо выполнить в openocd команду soft_reset_halt. После данной процедуры все работает соответствующим образом

Доброго времени суток! Столкнулся со следующей проблемой, в разрешении которой и прошу помощи: Необходимо вести отладку ПО в DDR, т.е. объем eSRAM маловат, а отлаживаться в eNVM не хочется. Проект сконфигурирован так, что MDDR замапан на адреса 0x00000000. Файл программы слинкован соответствующим образом с помощью стандартного скрипта. Перед загрузкой выполняются скрипты инициализации (обнуление регистров, настройка MDDR). Они так же стандартные. Далее программа успешно грузится в DDR и запускается, но не генерируются ни прерывания, ни исключения. Таблицу векторов проверил, она лежит в 0x00000000, все четко. Ссылки на адреса обработчиков корректные. Значение VTOR 0x00000000. Не могу понять в чем проблема. Стоит только замапать в 0x00000000 в eNVM и слинковать в eSRAM так все становиться ок. Если подытожить, то получается, что исключения и прерывания не генерируются при звмапаной в 0x00000000 MDDR PS: Чип M2S150TS, отладка Advanced development kit

Доброго времени суток. Не удается реализовать конструкцию, позволяющую сгенерирвать массив с интерфейсами, каждый из которых может быть настроен с помощью своих параметров. По задумке необходимо подключить слейвы/мастера к интерконнекту. В проекте предполагаются абоненты с разными параметрами интерфейсов (в частности разрядность шины). Передавать шины в интерконнект хочется массивом, а внутри уже подключать нужный к нужному. Возможно есть interface BUS #( parameter int asize = 32, parameter int dsize = 32 ); logic [asize-1:0] addr; logic [asize-1:0] data; endinterface; module top; BUS #( .asize (), .dsize () ) buses [0:1] (); interconnect inter_i ( .slaves(buses) ); slave1 slv1_i ( .slave(buses[0]) ); slave1 slv1_2 ( .slave(buses[1]) ); endmodule

Здравствуйте. Возник вопрос связанный с верификацией, основанной на проверке случайными значениями. Собственно вопрос: как привести (сконфигурировать) DUT к состоянию, позволяющему верифицировать тот или иной пункт? Для конфигурации необходимо загрузить определенные значения в определенные регистры. Т.е. если я, допустим, хочу проверить работу по прерываниям, то я должен сгенерировать на на шине такую транзакцию, которая установит соответствующие биты в верифицируемом ядре. Далее прогоняем случайные значения. После этого нужно снова сгенерировать некоторую транзакцию для установки некоторого бита, а затем снова гнать случайные данные. Реализовать ограничения для генерации универсальных пакетов не представляется (на мой взгляд) возможным. Видится следующее решение, но на мой взгляд оно как-то не вписывается в концепцию: 1) Включили ограничения для конфигурации N 2) Загрузили конфигурацию 3) Выключили ограничения для конфигурации N 4) Выполняем тестирование со стандартными ограничениями 5) Включили ограничения для конфигурации M и т.д.