cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rkfournier
Adventurer
Adventurer
430 Views
Registered: ‎05-09-2018

MSI Interrupts Stopped Working After Enabling the IP Config CTRL Interface

Jump to solution

I have a working Artix-7 PCIe design using Vivado 2020.2. I re-customized the PCIe IP to enable access to the Config CTRL Interface in order to gain access to the tx_cfg_gnt input. Once this interface was enabled, the PCIe IP stopped generating MSI interrupts. Everything else continued to function correctly except the interrupts. The cfg_interrupt_rdy output never goes high. I have poured over the PG054 User Guide for the added inputs from the Config CTRL Interface and could find any that claim to impact interrupts.

I reverted back to the PCIe IP without the Config CTRL Interface enabled and the MSI interrupts function correctly. Both versions of the PCIe IP are configured for 1 MSI vector.

Any suggestions or recommendations?

Below is the VHDL instantiation of the PCIe IP:


pciex4_inst : pciex4_gen2_cfg
PORT MAP (
pci_exp_txp => PCI_EXP_TXP,
pci_exp_txn => PCI_EXP_TXN,
pci_exp_rxp => PCI_EXP_RXP,
pci_exp_rxn => PCI_EXP_RXN,
int_pclk_out_slave => open,
int_pipe_rxusrclk_out => open,
int_rxoutclk_out => open,
int_dclk_out => open,
int_mmcm_lock_out => open,
int_userclk1_out => open,
int_userclk2_out => open,
int_oobclk_out => open,
int_qplllock_out => open,
int_qplloutclk_out => open,
int_qplloutrefclk_out => open,
int_pclk_sel_slave => (others => '0'),
user_clk_out => USERCLK,
user_reset_out => USERRESET,
user_lnk_up => user_lnk_up,
user_app_rdy => open,
tx_buf_av => tx_buf_av,
tx_cfg_req => tx_cfg_req,
tx_err_drop => open,
s_axis_tx_tready => s_axis_tx_tready,
s_axis_tx_tdata => s_axis_tx_tdata,
s_axis_tx_tkeep => s_axis_tx_tkeep,
s_axis_tx_tlast => s_axis_tx_tlast,
s_axis_tx_tvalid => s_axis_tx_tvalid,
s_axis_tx_tuser => s_axis_tx_tuser,
tx_cfg_gnt => tx_cfg_gnt,
m_axis_rx_tdata => m_axis_rx_tdata,
m_axis_rx_tkeep => m_axis_rx_tkeep,
m_axis_rx_tlast => m_axis_rx_tlast,
m_axis_rx_tvalid => m_axis_rx_tvalid,
m_axis_rx_tready => m_axis_rx_tready,
m_axis_rx_tuser => m_axis_rx_tuser,
rx_np_ok => '0',
rx_np_req => '1',
cfg_mgmt_do => cfg_mgmt_do,
cfg_mgmt_rd_wr_done => cfg_mgmt_rd_wr_done,
cfg_status => open,
cfg_command => cfg_command,
cfg_dstatus => open,
cfg_dcommand => cfg_dcommand,
cfg_lstatus => open,
cfg_lcommand => open,
cfg_dcommand2 => open,
cfg_pcie_link_state => open,
cfg_pmcsr_pme_en => open,
cfg_pmcsr_powerstate => open,
cfg_pmcsr_pme_status => open,
cfg_received_func_lvl_rst => open,
cfg_mgmt_di => cfg_mgmt_di,
cfg_mgmt_byte_en => cfg_mgmt_byte_en,
cfg_mgmt_dwaddr => cfg_mgmt_dwaddr,
cfg_mgmt_wr_en => cfg_mgmt_wr_en,
cfg_mgmt_rd_en => cfg_mgmt_rd_en,
cfg_mgmt_wr_readonly => cfg_mgmt_wr_readonly,
cfg_mgmt_wr_rw1c_as_rw => cfg_mgmt_wr_rw1c_as_rw,
cfg_trn_pending => '0',
cfg_pm_halt_aspm_l0s => '0',
cfg_pm_halt_aspm_l1 => '0',
cfg_pm_force_state_en => '0',
cfg_pm_force_state => "00",
cfg_dsn => (others => '0'),
cfg_interrupt => cfg_interrupt,
cfg_interrupt_rdy => cfg_interrupt_rdy,
cfg_interrupt_assert => cfg_interrupt_assert,
cfg_interrupt_di => cfg_interrupt_di,
cfg_interrupt_do => open,
cfg_interrupt_mmenable => cfg_interrupt_mmenable,
cfg_interrupt_msienable => cfg_interrupt_msienable,
cfg_interrupt_msixenable => open,
cfg_interrupt_msixfm => open,
cfg_interrupt_stat => '0',
cfg_pciecap_interrupt_msgnum => (others => '0'),
cfg_to_turnoff => open,
cfg_turnoff_ok => '0',
cfg_bus_number => cfg_bus_number,
cfg_device_number => cfg_device_number,
cfg_function_number => cfg_function_number,
cfg_pm_wake => '0',
cfg_pm_send_pme_to => '0',
cfg_ds_bus_number => cfg_bus_number,
cfg_ds_device_number => cfg_device_number,
cfg_ds_function_number => cfg_function_number,
cfg_bridge_serr_en => open,
cfg_slot_control_electromech_il_ctl_pulse => open,
cfg_root_control_syserr_corr_err_en => open,
cfg_root_control_syserr_non_fatal_err_en => open,
cfg_root_control_syserr_fatal_err_en => open,
cfg_root_control_pme_int_en => open,
cfg_aer_rooterr_corr_err_reporting_en => open,
cfg_aer_rooterr_non_fatal_err_reporting_en => open,
cfg_aer_rooterr_fatal_err_reporting_en => open,
cfg_aer_rooterr_corr_err_received => open,
cfg_aer_rooterr_non_fatal_err_received => open,
cfg_aer_rooterr_fatal_err_received => open,
cfg_vc_tcvc_map => open,
sys_clk => SYS_CLK_BUF,
sys_rst_n => PWR_UP_RESETL
);

0 Kudos
1 Solution

Accepted Solutions
rkfournier
Adventurer
Adventurer
265 Views
Registered: ‎05-09-2018

I answered my own question: YES, the tx_cfg_req and tx_cfg_gnt must be handled properly during the generation of MSI interrupts. The MSI interrupt will not be generated until the transmit request is granted.

View solution in original post

0 Kudos
4 Replies
nmanitri
Xilinx Employee
Xilinx Employee
360 Views
Registered: ‎06-13-2018

Hi @rkfournier,

Are you seeing this behavior in Simulation or on the Hardware?

Are you able to replicate the issue with Xilinx out of box example design?

Could you please check https://www.xilinx.com/Attachment/Xilinx_Answer_58495_PCIe_Interrupt_Debugging_Guide.pdf.

Regards,

Naveen 

rkfournier
Adventurer
Adventurer
296 Views
Registered: ‎05-09-2018

This problem occurs on working hardware using the same software driver. The only change is to enable the Config CTRL Interface when generating the IP core, and a recompile of the FPGA. MSI interrupts work fine UNTIL this interface is enabled in the IP generator.

0 Kudos
rkfournier
Adventurer
Adventurer
278 Views
Registered: ‎05-09-2018

Question: When implementing tx_cfg_req and tx_cfg_gnt, are these signals also required during MSI Interrupt generation? I found the working IP has tx_cfg_gnt tied to a logic '1' level in the top level synthesis source file. The PG054 PCIe user guide is unclear on this topic.

0 Kudos
rkfournier
Adventurer
Adventurer
266 Views
Registered: ‎05-09-2018

I answered my own question: YES, the tx_cfg_req and tx_cfg_gnt must be handled properly during the generation of MSI interrupts. The MSI interrupt will not be generated until the transmit request is granted.

View solution in original post

0 Kudos