UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer altde
Observer
148 Views
Registered: ‎05-16-2011

Tri Mode Ethernet MAC (TEMAC) interrupt register writes fail

I've been trying to test the MAC_IRQ output of a Tri Mode Ethernet MAC (on a KU035 project, using Vivado 2018.2, though 2019.2 appears to have the same issue) and am having trouble setting the interrupt enable bit.

I think it looks like a race: if the AXI write data changes on the falling edge of WREADY and WVALID, the new data ends up in the register. (At least in this case, the Xilinx AXI Interconnect block does do that.  The master is an AXI Bridge for PCIE Express Gen3 Subsystem, configured as an endpoint.)  I believe the correct data gets written first and then overwritten, because if the interrupt source is already asserted I get a pulse on MAC_IRQ.

The simulation model is encrypted, but in the attached schematic from the synthesized design it looks like there's one more flip-flop in the write-enable path than in the data path. (The inputs to the unexpanded LUT6, ipic_ier[0]_i_2, are address bits, some of which are already shown, and the chip select, which matches the write enable.)

If I use a force to hold the AXI data for one more clock cycle, the write works. (It also works if I do a burst access that writes the same data to the next address, which stops the data returning to 0 immediately.)

(I don't have this problem with all the MAC registers. We've been able to get MDIO and Ethernet traffic working in simulation and on the target hardware, suggesting that many or most registers work.  I can't be sure, but in the synthesized design inc_control.intc appears to be the only block with an extra fllip-flop in the wrce path.)

Is there a workaround or patch for this?

Regards,

Dan Alt

0 Kudos
2 Replies
Moderator
Moderator
83 Views
Registered: ‎08-25-2009

Re: Tri Mode Ethernet MAC (TEMAC) interrupt register writes fail

Hi @altde ,

Can this issue be reproduced in simulation? If so, could you please send me an exmaple design to check?

There does not seem to be an known issue regarding the same.

 

"Don't forget to reply, kudo and accept as solution."
0 Kudos
Observer altde
Observer
59 Views
Registered: ‎05-16-2011

Re: Tri Mode Ethernet MAC (TEMAC) interrupt register writes fail

Hi, @nanz.

I'm not allowed to send you the design, but here's how the main blocks (all in a Vivado block design, with instance names matching the schematic I attached to the original email) are configured.

U_ETH1_EMAC (xilinx.com:ip:tri_mode_ethernet_mac:9.0):
    CONFIG.Make_MDIO_External {false} \
    CONFIG.Management_Frequency {125.00} \
    CONFIG.Physical_Interface {Internal} \
    CONFIG.Frame_Filter {true} \
    CONFIG.Number_of_Table_Entries {4} \
    CONFIG.Statistics_Counters {true} \
    CONFIG.Statistics_Width {32bit} \

U_MAIN_AXI_INTERCONNECT (xilinx.com:ip:axi_interconnect:2.1):
    All default settings, with 1 slave interface and many master interfaces.
    I don't know if the number of masters matters.  The same behavior may even occur without an interconnect block.

U_TGP_PCIE (xilinx.com:ip:axi_pcie3:3.0):
    This block's master AXI port is connected to U_MAIN_AXI_INTERCONNECT's slave port.
    I don't know if other AXI masters would produce the same behavior, but they could.
    Here are the configuration properties that seem potentially relevant:
    CONFIG.mode_selection {Advanced} \
    CONFIG.device_port_type {PCI_Express_Endpoint_device} \
    CONFIG.pl_link_cap_max_link_width {X1} \
    CONFIG.pl_link_cap_max_link_speed {2.5_GT/s} \
    CONFIG.plltype {CPLL} \
    CONFIG.pf0_link_status_slot_clock_config {false} \
    CONFIG.dedicate_perst {false} \
    CONFIG.pcie_blk_locn {X0Y0} \
    CONFIG.select_quad {GTH_Quad_225} \
    CONFIG.axi_data_width {64_bit} \
    CONFIG.axisten_freq {125} \
    CONFIG.en_axi_slave_if {false} \
    CONFIG.en_axi_master_if {true} \
    CONFIG.pf0_msi_enabled {false} \
    CONFIG.pf0_interrupt_pin {INTA} \
    CONFIG.pf0_msix_cap_table_bir {BAR_1:0} \
    CONFIG.pf0_msix_cap_pba_bir {BAR_1:0} \

I believe the only important thing is the AXI bus timing.  I have attached a simulator screen shot (bad.jpg) showing the failure, with TEMAC ports shown.  The write is supposed to enable the interrupt, which should be immediately asserted because the underlying condition (MDIO ready) is present.  That does happen, but then shortly after the end of the write cycle the interrupt is deasserted, almost certainly because the TEMAC continues to write using s_axi_wdata in the clock cycle after deassertion of s_axi_wvalid and s_axi_wready.  (Last week I read the register after the write and confirmed that the interrupt enable bit ended up '0', but the current simulation does not do that.)

I have also attached a second screen (good.jpg) shot with the design modified to hold s_axi_wdata for an extra clock cycle.  (It also holds s_axi_awaddr, but I don't think that matters, since the TEMAC block latches and holds the address.  Similarly, s_axi_bready timing is also different; I hadn't noticed that before, and while I don't think it matters, I'm not sure.  If my theory is correct, only the s_axi_wdata change is relevant.)  good.jpg also includes a second write to clear the interrupt enable bit.

In both cases each horizontal division is 20 ns and the clock is 125 MHz.

Regards,
Dan

bad.jpg
good.jpg
0 Kudos