xilinx answer 59968 connecting temac and sgmii …...pma_reset : in std_logic; -- transceiver pma...

© Copyright 2013 Xilinx

Xilinx Answer Record 59968 1

Xilinx Answer 59968

Connecting TEMAC and SGMII Cores in Vivado for 7 series

Important Note: This downloadable PDF of an Answer Record is provided to enhance its usability and readability. It is important to note that Answer Records are Web-based content that are frequently updated as new information becomes available. You are reminded to visit the Xilinx Technical Support Website and review (Xilinx Answer 59968) for the latest version of this Answer.

Introduction

This example is to show how we can have AXI Tri‐Speed Ethernet MAC extended to use SGMII on 7 series devices. It includes detailed steps for generating the “Tri Mode Ethernet MAC” core and “Ethernet 1000BASE-X PCS PMA or SGMII” core in Vivado 2013.2; and for connecting them together in the top level TEMAC example design. It also includes a simulation section on running “BIST” loopback; and a HW debug section on using ILA debug cores in a Vivado flow.



Design Architecture

Here is a block diagram of a TEMAC core and an SGMII core connected together. (see figure 1)

Figure 1 – Block Diagram of Connected TEMAC and SGMII IPs



Design Interfaces

We have 3 main interfaces to focus on in this documentation. (see Figure 1)

Interface 1 – Data Interface between SGMII and Transceiver

Interface 2 – MAC and SGMII Interface

Interface 3 - MAC AXI4 Stream Interface

Here is a list of signals on each interface. We are going to analyze them in both simulation and hardware debug in this documentation.

Date Interface between the GT and SGMII core

data_valid independent_clock configuration_vector status_vector usrclk2 usrclk gttxreset txdata txcharisk loopback powerdown rxrecclk rxdata rxcharisk gtrxreset rxdisperr rxnotintable rxbuferr txbuferr rxchariscomma rxclkcorcnt plllkdet mmcm_locked resetdone txn txp rxn rxp

MAC to SGMII Interface signals

gtx_clk glbl_rstn rx_axi_rstn tx_axi_rstn rx_mac_aclk rx_reset pause_req pause_val clk_enable speedis100 speedis10100 gmii_txd gmii_tx_en gmii_tx_er



gmii_rxd gmii_rx_dv gmii_rx_er mdc mdio_i mdio_o mdio_t

MAC AXI4 Stream Interface Signals

rx_axis_mac_tdata rx_axis_mac_tvalid rx_axis_mac_tlast rx_axis_mac_tuser tx_mac_aclk tx_reset tx_axis_mac_tdata tx_axis_mac_tvalid tx_axis_mac_tlast tx_axis_mac_tuser tx_axis_mac_tready

MAC AXI4Lite Interface Signals

s_axi_aclk s_axi_resetn s_axi_awaddr s_axi_awvalid s_axi_awready s_axi_wdata s_axi_wvalid s_axi_wready s_axi_bresp s_axi_bvalid s_axi_bready s_axi_araddr s_axi_arvalid s_axi_arready s_axi_rdata s_axi_rresp s_axi_rvalid s_axi_rready mac_irq

MAC Statistics Interface Signals

tx_ifg_delay tx_statistics_vector tx_statistics_valid rx_statistics_vector rx_statistics_valid



Generating and Connecting Two Cores in Vivado

TEMAC Core Generation

1. Select “Create New Project” in Vivado and choose the KC705 Evaluation Platform shown as below, then click on “Finish”. (see Figure 2)

Figure 2 - Create a Vivado Project for KC705

2. In Vivado, click on “IP Catalog”; and double click on “Tri Mode Ethernet MAC”. (see Figure 3)



Figure 3 - Generate Tri-Mode Ethernet MAC

3. Make the TEMAC configurations and generate the core. (see Figure 4 and Figure 5)

Figure 4 - TEMAC Configuration Interface



Figure 5 - TEMAC Configuration Features

4. Right click on “Open IP Example Design”. (see Figure 6)



Figure 6 - Open TEMAC Example Design

Click on “OK”. (see Figure 7)

Figure 7 - Open Design in a Specified Location

SGMII Core Generation

With the example design opened, we are going to generate the SGMII core.

5. In the TEMAC example design, double click on the “Ethernet 1000BASE-X PCS/PMA or SGMII” core in “IP Catalog”. (see Figure 8)



Figure 8 - Generate SGMII Core

6. Make the following configurations then click “OK” to generate the core. (see Figure 9, Figure 10, Figure 11, and Figure 12)

Figure 9 - Configure the Core to SGMII



Figure 10 - Enable Auto Negotiation



Figure 11 - Choose Tri-Speed Mode



Figure 12 - Uncheck SGMII PHY Mode

7. After generating the core, we will see similar to Figure 13 in the Vivado GUI. (see Figure 13)

Figure 13 - Vivado Project Manager

Connecting TEMAC and SGMII in Vivado

8. Open the TEMAC example wrapper file and connect the SGMII core with MAC. Please compare tri_mode_ethernet_mac_0_example_design.vhd and tri_mode_ethernet_mac_0_example_design_old.vhd for the detailed changes.



Here are the steps required to connect the two cores.

Instantiate the gig_eth_pcs_pma _block and connect the GMII interface to the Tri-Mode Ethernet MAC. Change the tri_mode_eth_mac_v7_0_block instantiation to use the internal GMII interface instead of an

external GMII interface (the KC705 board is only targeted if you select external GMII or RGMII interface when generating the TEMAC, so the external GMII interface is used for the top level example design and the UCF starting point).

Add the correct MMCM clocking from the gig_eth_pcs_pma _example_design.v and changed the TEMAC to be clocked by this clock.

Set the Configuration vector to enable AN, disable Isolate, Loopback and PowerDown. Set the Link Timer to SGMII standard.

Top-level ports changes: *********************************************************************** -- clock from internal phy -- gtx_clk : in std_logic; -- clk_enable : in std_logic; -- speedis100 : out std_logic; -- speedis10100 : out std_logic; -- 200MHz clock input from board clk_in_p : in std_logic; clk_in_n : in std_logic; phy_resetn : out std_logic; --added SGMII serial data and reference clock ports gtrefclk_p : in std_logic; -- Differential +ve of reference clock for MGT: 125MHz, very high quality. gtrefclk_n : in std_logic; --Differential -ve of reference clock for MGT: 125MHz, very high quality. txp : out std_logic; -- Differential +ve of serial transmission from PMA to PMD. txn : out std_logic; -- Differential -ve of serial transmission from PMA to PMD. rxp : in std_logic; -- Differential +ve for serial reception from PMD to PMA. rxn : in std_logic; -- Differential -ve for serial reception from PMD to PMA. synchronization_done : out std_logic; linkup : out std_logic; -- GMII Interface ----------------- --gmii_txd : out std_logic_vector (7 downto 0); --gmii_tx_en : out std_logic; --gmii_tx_er : out std_logic; --gmii_rxd : in std_logic_vector (7 downto 0); --gmii_rx_dv : in std_logic; --gmii_rx_er : in std_logic; ***********************************************************************

Instantiate the PCM PMA block: *********************************************************************** component gig_ethernet_pcs_pma_0 generic ( EXAMPLE_SIMULATION : integer := 0 -- Set to 1 for simulation ); port( -- Transceiver Interface ------------------------ drpaddr_in : in std_logic_vector(8 downto 0); drpclk_in : in std_logic; drpdi_in : in std_logic_vector(15 downto 0); drpdo_out : out std_logic_vector(15 downto 0); drpen_in : in std_logic;



drprdy_out : out std_logic; drpwe_in : in std_logic; gtrefclk : in std_logic; -- Very high quality 125MHz clock for GT transceiver txp : out std_logic; -- Differential +ve of serial transmission from PMA to PMD. txn : out std_logic; -- Differential -ve of serial transmission from PMA to PMD. rxp : in std_logic; -- Differential +ve for serial reception from PMD to PMA. rxn : in std_logic; -- Differential -ve for serial reception from PMD to PMA. txoutclk : out std_logic; -- txoutclk from GT transceiver (62.5MHz) resetdone : out std_logic; -- The GT transceiver has completed its reset cycle mmcm_locked : in std_logic; -- Locked signal from MMCM userclk : in std_logic; -- 62.5MHz clock. userclk2 : in std_logic; -- 125MHz clock. independent_clock_bufg: in std_logic; -- 200MHz clock. pma_reset : in std_logic; -- transceiver PMA reset signal -- GMII Interface ----------------- sgmii_clk_r : out std_logic; -- Clock for client MAC (125Mhz, 12.5MHz or 1.25MHz). sgmii_clk_f : out std_logic; -- Clock for client MAC (125Mhz, 12.5MHz or 1.25MHz). sgmii_clk_en : out std_logic; -- Clock enable for client MAC gmii_txd : in std_logic_vector(7 downto 0); -- Transmit data from client MAC. gmii_tx_en : in std_logic; -- Transmit control signal from client MAC. gmii_tx_er : in std_logic; -- Transmit control signal from client MAC. gmii_rxd : out std_logic_vector(7 downto 0); -- Received Data to client MAC. gmii_rx_dv : out std_logic; -- Received control signal to client MAC. gmii_rx_er : out std_logic; -- Received control signal to client MAC. gmii_isolate : out std_logic; -- Tristate control to electrically isolate GMII. -- Management: Alternative to MDIO Interface -------------------------------------------- configuration_vector : in std_logic_vector(4 downto 0); -- Alternative to MDIO interface. an_interrupt : out std_logic; -- Interrupt to processor to signal that Auto-Negotiation has completed an_adv_config_vector : in std_logic_vector(15 downto 0); -- Alternate interface to program REG4 (AN ADV) an_restart_config : in std_logic; -- Alternate signal to modify AN restart bit in REG0 link_timer_value : in std_logic_vector(8 downto 0); -- Programmable Auto-Negotiation Link Timer Control -- Speed Control ---------------- speed_is_10_100 : in std_logic; -- Core should operate at either 10Mbps or 100Mbps speeds speed_is_100 : in std_logic; -- Core should operate at 100Mbps speed -- General IO's --------------- status_vector : out std_logic_vector(15 downto 0); -- Core status. reset : in std_logic; -- Asynchronous reset for entire core. signal_detect : in std_logic -- Input from PMD to indicate presence of optical input. ); end component; *********************************************************************** Remove the reusable_clock module as gtx_clk is removed from the toplevel. *********************************************************************** -- component tri_mode_ethernet_mac_0_reusable_clocks is -- port ( -- clocks -- gtx_clk : in std_logic; -- clock outputs -- gtx_clk_bufg : out std_logic; -- s_axi_aclk : out std_logic -- ); -- end component;

***********************************************************************



Add 200MHz clock input from the board: *********************************************************************** clkin_buf : IBUFGDS port map (O => clkin200, I => clk_in_p, IB => clk_in_n); clk200_bufg : BUFG port map (O => clk_200_bufg, I => clkin200); ***********************************************************************

Add PHY reset:

*********************************************************************** phy_reset : process (userclk2) begin if userclk2'event and userclk2 = '1' then if glbl_rst_intn = '0' then phy_resetn_int <= '0'; phy_reset_count <= "000000"; else if not phy_reset_count = "111111" then phy_reset_count <= std_logic_vector(unsigned(phy_reset_count) + 1); else phy_resetn_int <= '1'; end if; end if; end if; end process phy_reset; phy_resetn <= phy_resetn_int; ***********************************************************************

Instantiate MMCM from PCS PMA core: *********************************************************************** mmcm_adv_inst : MMCME2_ADV generic map (BANDWIDTH => "OPTIMIZED", CLKOUT4_CASCADE => FALSE, COMPENSATION => "ZHOLD", STARTUP_WAIT => FALSE, DIVCLK_DIVIDE => 1, CLKFBOUT_MULT_F => 16.000, CLKFBOUT_PHASE => 0.000, CLKFBOUT_USE_FINE_PS => FALSE, CLKOUT0_DIVIDE_F => 8.000, CLKOUT0_PHASE => 0.000, CLKOUT0_DUTY_CYCLE => 0.5, CLKOUT0_USE_FINE_PS => FALSE, CLKOUT1_DIVIDE => 16, CLKOUT1_PHASE => 0.000, CLKOUT1_DUTY_CYCLE => 0.5, CLKOUT1_USE_FINE_PS => FALSE, CLKIN1_PERIOD => 16.0, REF_JITTER1 => 0.010) port map -- Output clocks (CLKFBOUT => clkfbout, CLKFBOUTB => open, CLKOUT0 => clkout0, CLKOUT0B => open, CLKOUT1 => clkout1,



CLKOUT1B => open, CLKOUT2 => open, CLKOUT2B => open, CLKOUT3 => open, CLKOUT3B => open, CLKOUT4 => open, CLKOUT5 => open, CLKOUT6 => open, -- Input clock control CLKFBIN => clkfbout, CLKIN1 => txoutclk_bufg, CLKIN2 => '0', -- Tied to always select the primary input clock CLKINSEL => '1', -- Ports for dynamic reconfiguration DADDR => (others => '0'), DCLK => '0', DEN => '0', DI => (others => '0'), DO => open, DRDY => open, DWE => '0', -- Ports for dynamic phase shift PSCLK => '0', PSEN => '0', PSINCDEC => '0', PSDONE => open, -- Other control and status signals LOCKED => dcm_locked, CLKINSTOPPED => open, CLKFBSTOPPED => open, PWRDWN => '0', RST => mmcm_reset); mmcm_reset <= glbl_rst or (not resetdone); -- This 62.5MHz clock is placed onto global clock routing and is then used -- for tranceiver TXUSRCLK/RXUSRCLK. bufg_userclk: BUFG port map ( I => clkout1, O => userclk ); -- This 125MHz clock is placed onto global clock routing and is then used -- to clock all Ethernet core logic. bufg_userclk2: BUFG port map ( I => clkout0, O => userclk2 );

***********************************************************************

Enable auto-negotiation: *********************************************************************** link_timer_value <= "000110010"; signal_detect <= '1'; sgmii_configuration_vector <= "10000"; --[4]AN enable,[3]Isolate disabled,[2]Powerdowndisabled,[1]loopback disabled, [0] Unidirectional disabled an_adv_config_vector <= "0000000000100001"; an_restart_config <= '1'; synchronization_done <= status_vector_int (1); linkup <= status_vector_int (0);

***********************************************************************



Running Simulation

Before running the simulation, we will need to modify the demo_tb testbench. Please check demo_tb for details. Change the TB_MODE to BIST instead of DEMO: *********************************************************************** -- constant TB_MODE : string := "DEMO" constant TB_MODE : string := "BIST"; ***********************************************************************

In “BIST” mode, the built in pattern generators and pattern checkers are used with the data loopback in the PHY domain. Drive clk200 to 200MHz: *********************************************************************** -- drives clk200 at 200 MHz p_clk200 : process begin clk200 <= '0'; clk200n <= '1'; wait for 80 ns; loop wait for 2.5 ns; clk200 <= '1'; clk200n <= '0'; wait for 2.5 ns; clk200 <= '0'; clk200n <= '1'; end loop; end process p_clk200; ***********************************************************************

Disable Auto-negotiation in the simulation: *********************************************************************** sgmii_configuration_vector <= "10000"; --[4]AN enable,[3]Isolate disabled,[2]Powerdowndisabled,[1]loopback disabled, [0] Unidirectional disabled ***********************************************************************

In Vivado Simulation settings, set the simulator to Vivado Simulator. And click on “Run Simulation”. (see Figure 14)

Figure 14 - Run Simulation



In XSIM, type “run all” in the Tcl Console. When the simulation comes up, you will see something similar to the below. Here is an overview of the simulation. (see Figure 15 ~ Figure 19)

Figure 15 - SGMII to GT Interface

Figure 16 - MAC to SGMII Interface

Figure 17 - MAC AXI4 Stream Interface

Figure 18 - MAC AXI4 Lite Interface



Figure 19 - MAC Statistics

Analyzing Simulation Results

We can zoom in on the first packet from the pattern generator and track it through the MAC AXI4 Stream TX interface to the MAC and SGMII interface; and then to the SGMII and GT interface. Finally it will loopback to the RX SGMII and GT Interface. Here is the first Ethernet packet appearing on the MAC AXI4 Stream TX interface. Here is a snapshot of the zoomed-in AXI4 Stream Interface:

Figure 20 - Zoomed in MAC AXI4 Stream TX Interface

On zooming in again we see the 1

st Packet on the tx_axis_mac_tdata bus. We can see the Source Address (5A-01-

02-03-04-05) followed by the Destination Address (DA-01-02-03-04-05). The data from the pattern generator is also present on the bus. (see Figure 21, Figure 22)

Figure 21 - 1st Ethernet Packet on MAC AXI4 Stream TX Interface (part1)

Figure 22 - 1st Ethernet Packet on MAC AXI4 Stream TX Interface (part2)

This is consistent with what we have in the pat_gen.vhd: *********************************************************************** entity tri_mode_ethernet_mac_0_basic_pat_gen is generic ( DEST_ADDR : bit_vector(47 downto 0) := X"da0102030405"; SRC_ADDR : bit_vector(47 downto 0) := X"5a0102030405"; … ***********************************************************************

When zooming in the first packet on gmii_txd bus between MAC and SGMII interface, we have (see Figure 23, Figure 24):



Figure 23 - 1st Ethernet Packet between MAC and SGMII TX Interface (part1)


The “55” is the preamble. “D5” is the start of the frame data. After “D5”, we can also see the Source Address (5A-01-02-03-04-05) followed by the Destination Address (DA-01-02-03-04-05).

On the SGMII to GT interface, “FB” indicates the start of a packet. “55” is the preamble. “D5” is the start of a frame; and “5A-01-02-03-04-05” is the Source Address, followed by the Destination Address “DA-01-02-03-04-05”. (see Figure 25)

Figure 25 - 1st Ethernet Packet between SGMII and GT Interface (part1)



We can also see “FD” at the end of txdata bus; which indicates the end of a packet. (see Figure 26)


Now we will take a closer look on the RX interface from GT -> SGMII -> TEMAC -> AXI4 Stream, as all of the data has been looped back.

On the SGMII and GT interface, “FB” shows the start of a packet. (see Figure 27)



Figure 27 - Data Looped Back between GT and SGMII RX Interface (part1)

And “FD” is the end of a packet. (see Figure 28)

Figure 28 - Data Looped Back between GT and SGMII RX Interface (part2)

On the SGMII to MAC RX Interface, we can see the following (see Figure 29 and Figure 30):

Figure 29 - Data Looped Back between SGMII and MAC RX Interface (part1)



Figure 30 - Data Looped Back between SGMII and MAC RX Interface (part2)

On the RX AXI4 Stream Interface (see Figure 31):

Figure 31 - Data Looped Back on MAC AXI4 Stream RX Interface

On the MAC AXI4 Lite Interface of the MAC (see Figure 32Figure 32):

Figure 32 - MAC AXI4 Lite Interface

MAC statistics Vector: If we take a closer look at the statistics vector we can see that when tx_statitics_valid is asserted, the tx_statistics_vector is 0x00000801 (see Figure 33 for )

Figure 33 - MAC TX Statistics Vector

We can compare this with the bit definitions of the “Transmitter Statistics Vector” in the Production Guide (see Figure 34 ). This means a “SUCCESSFUL FRAME”; with the frame count bit[11:5] = [1000000] = 64 bytes.



Figure 34 - Part of Bit Definition for the Transmitter Statistics Vector

The same analysis can be done for the Receiver Side.



Verification on Hardware

To verify the design on hardware, we need to modify the XDC file:

Update the XDC to obtain the needed changes for the KC705 board.

Add XDC constraints for the serial clock.

Update the timing and period constraints to the new clocking.

Add constraints for the Synchronization and Link Status signals from the PCS/PMA core to bring these signals

out to LEDs.

Please see the xdc file for more details. Here is a snap shot of the changes: *********************************************************************** set_property PACKAGE_PIN AD12 [get_ports clk_in_p] set_property PACKAGE_PIN AD11 [get_ports clk_in_n] set_property IOSTANDARD LVDS [get_ports clk_in_p] set_property IOSTANDARD LVDS [get_ports clk_in_n] set_false_path -through [get_nets glbl_rst] set_property PACKAGE_PIN AB7 [get_ports glbl_rst] set_property IOSTANDARD LVCMOS15 [get_ports glbl_rst] set_property PACKAGE_PIN AB8 [get_ports frame_error] set_property IOSTANDARD LVCMOS15 [get_ports frame_error] set_property PACKAGE_PIN AA8 [get_ports frame_errorn] set_property IOSTANDARD LVCMOS15 [get_ports frame_errorn] set_property PACKAGE_PIN AC9 [get_ports activity_flash] set_property IOSTANDARD LVCMOS15 [get_ports activity_flash] set_property PACKAGE_PIN AB9 [get_ports activity_flashn] set_property IOSTANDARD LVCMOS15 [get_ports activity_flashn] set_property PACKAGE_PIN G12 [get_ports update_speed] set_property IOSTANDARD LVCMOS25 [get_ports update_speed] set_property PACKAGE_PIN AC6 [get_ports config_board] set_property IOSTANDARD LVCMOS15 [get_ports config_board] set_property PACKAGE_PIN AB12 [get_ports pause_req_s] set_property IOSTANDARD LVCMOS15 [get_ports pause_req_s] set_property PACKAGE_PIN AA12 [get_ports reset_error] set_property IOSTANDARD LVCMOS15 [get_ports reset_error] set_property PACKAGE_PIN Y28 [get_ports {mac_speed[0]}] set_property IOSTANDARD LVCMOS25 [get_ports {mac_speed[0]}] set_property PACKAGE_PIN AA28 [get_ports {mac_speed[1]}] set_property IOSTANDARD LVCMOS25 [get_ports {mac_speed[1]}] set_property PACKAGE_PIN W29 [get_ports gen_tx_data] set_property IOSTANDARD LVCMOS25 [get_ports gen_tx_data] set_property PACKAGE_PIN Y29 [get_ports chk_tx_data] set_property IOSTANDARD LVCMOS25 [get_ports chk_tx_data] set_false_path -through [get_nets phy_resetn] set_property PACKAGE_PIN L20 [get_ports phy_resetn] set_property IOSTANDARD LVCMOS25 [get_ports phy_resetn] set_property PACKAGE_PIN AJ24 [get_ports serial_response] set_property IOSTANDARD LVCMOS25 [get_ports serial_response] set_property PACKAGE_PIN AK25 [get_ports tx_statistics_s] set_property IOSTANDARD LVCMOS25 [get_ports tx_statistics_s]



set_property PACKAGE_PIN AE25 [get_ports rx_statistics_s] set_property IOSTANDARD LVCMOS25 [get_ports rx_statistics_s] set_property PACKAGE_PIN R23 [get_ports mdc] set_property IOSTANDARD LVCMOS25 [get_ports mdc] set_property PACKAGE_PIN J21 [get_ports mdio] set_property IOSTANDARD LVCMOS25 [get_ports mdio] set_property PACKAGE_PIN AE26 [get_ports synchronization_done] set_property IOSTANDARD LVCMOS25 [get_ports synchronization_done] set_property PACKAGE_PIN G19 [get_ports linkup] set_property IOSTANDARD LVCMOS25 [get_ports linkup] set_property PACKAGE_PIN G8 [get_ports gtrefclk_p] set_property PACKAGE_PIN G7 [get_ports gtrefclk_n] set_property PACKAGE_PIN H5 [get_ports rxn] set_property PACKAGE_PIN J4 [get_ports txp] set_property PACKAGE_PIN J3 [get_ports txn] set_property PACKAGE_PIN H6 [get_ports rxp] # Transmitter clock period constraints: please do not relax #create_clock -name clkout0 -period 8.000 [get_ports gtx_clk] create_clock -period 8.000 -name gtrefclk [get_pins ibufds_gtrefclk/O] #create_clock -name txoutclk -period 16.000 [get_pins core_wrapper/transceiver_inst/gtwizard_inst/gt0_GTWIZARD_i/gtxe2_i/TXOUTCLK] create_clock -period 16.000 -name txoutclk [get_pins core_wrapper/U0/transceiver_inst/gtwizard_inst/gtwizard_i/U0/gt0_GTWIZARD_i/gtxe2_i/TXOUTCLK] #create_clock -name core_wrapper/U0/independent_clock -period 5.000 [get_ports independent_clock] create_clock -period 5.000 -name clk_in_p [get_ports clk_in_p] set_false_path -from [get_clocks -include_generated_clocks clk_in_p] -to [get_clocks -include_generated_clocks gtrefclk] set_false_path -from [get_clocks -include_generated_clocks gtrefclk] -to [get_clocks -include_generated_clocks clk_in_p] # AXI-Lite Clock period Constraints # #create_clock -name clkout1 -period 8.000 [get_pins bufg_axi_clk/O] #set gtx_clk_name [get_clocks clkout0] #set axi_clk_name [get_clocks clkout1]

***********************************************************************

Then click the “”Generate Bitstream” button to run the implementation. For information on how to verify it on Hardware, please refer to PG051 – “Targeting the Example Design to a Board” section for details.



Setting Up the Debug Cores in Vivado

There are two ways to set up debug signals in ChipScope. One is to manually pull the signals that we would like to debug in Vivado. The alternative is to use the “mark_debug” attribute in the source codes to mark the signals before running synthesis. This way, the signals that we “marked” to debug will be pulled directly to ChipScope. For this section, we are using the “mark_debug” attribute approach. The files that we are going to add the “mark_debug” attribute are tri_mode_ethernet_mac_0_fifo_block.vhd; tri_mode_ethernet_mac_0_example_design.vhd; and gig_ethernet_pcs_pma_0_block.vhd. In tri_mode_ethernet_mac_0_example_design.vhd, we can add the following: *********************************************************************** attribute mark_debug : string; attribute mark_debug of rx_reset : signal is "true"; attribute mark_debug of tx_reset : signal is "true"; attribute mark_debug of pause_req : signal is "true"; attribute mark_debug of pause_val : signal is "true"; attribute mark_debug of clk_enable : signal is "true"; attribute mark_debug of gmii_txd_int : signal is "true"; attribute mark_debug of gmii_tx_en_int : signal is "true"; attribute mark_debug of gmii_tx_er_int : signal is "true"; attribute mark_debug of gmii_rxd_int : signal is "true"; attribute mark_debug of gmii_rx_dv_int : signal is "true"; attribute mark_debug of gmii_rx_er_int : signal is "true"; ***********************************************************************

In tri_mode_ethernet_mac_0_fifo_block.vhd, we can add the following: *********************************************************************** attribute mark_debug : string; attribute mark_debug of rx_axis_mac_tdata : signal is "true"; attribute mark_debug of rx_axis_mac_tvalid : signal is "true"; attribute mark_debug of rx_axis_mac_tlast : signal is "true"; attribute mark_debug of rx_axis_mac_tuser : signal is "true"; attribute mark_debug of tx_axis_mac_tdata : signal is "true"; attribute mark_debug of tx_axis_mac_tvalid : signal is "true"; attribute mark_debug of tx_axis_mac_tready : signal is "true"; attribute mark_debug of tx_axis_mac_tlast : signal is "true"; attribute mark_debug of tx_axis_mac_tuser : signal is "true"; attribute mark_debug of tx_mac_reset : signal is "true"; ***********************************************************************

In gig_ethernet_pcs_pma_0_block.vhd, we can add the following: *********************************************************************** attribute mark_debug : string; attribute mark_debug of rxchariscomma: signal is "true"; attribute mark_debug of rxcharisk: signal is "true"; attribute mark_debug of rxclkcorcnt: signal is "true"; attribute mark_debug of rxdata: signal is "true"; attribute mark_debug of rxdisperr: signal is "true"; attribute mark_debug of rxnotintable: signal is "true"; attribute mark_debug of rxrundisp: signal is "true"; attribute mark_debug of txbuferr: signal is "true";



attribute mark_debug of loopback: signal is "true"; attribute mark_debug of powerdown: signal is "true"; attribute mark_debug of txchardispmode: signal is "true"; attribute mark_debug of txchardispval: signal is "true"; attribute mark_debug of txcharisk: signal is "true"; attribute mark_debug of txdata: signal is "true"; attribute mark_debug of enablealign: signal is "true"; ***********************************************************************

Then click on “Run Synthesis” to synthesize the design. After synthesis completes, click on “Open Synthesized Design” shown as below (see Figure 35):

Figure 35 - Open Synthesized Design in Vivado

After the design is open, click on “Tools”-> “Set up Debug”

Figure 36 – Set Up Debug in Vivado



Set up the debug signals, then click “Next” (see Figure 37).

Figure 37 - Set Up Debug “Next”

All of the signals that we marked as “Debug” will be populated directly in the “Specify Nets to Debug” window (see Figure 38).

Figure 38 - Specify Nets to Debug



Click on “Finish”. (see Figure 39)

Figure 39 - Finish Set Up Debug GUI

The bug cores are being created.

You can see this in the Netlist tab.

Figure 40 - Netlist tab with Debug Core



And in the “Debug” tab, you can see all of the nets that were marked to debug are here. (see Figure 41)

Figure 41 - Debug Tab with All the Debug Nets

You can right click on any of the Nets; and then “Set Up Debug” to add or remove any nets.



In the Debug -> Debug Cores tab, click on u_ila_0_0 core. You can see “Cell Property” is showing up. (see Figure 42)

Figure 42 - ILA Properties



Click on the “Debug Cores Options” to change the C_DATA_DEPTH to 4096.

Figure 43 - Set ILA Property C_DATA_DEPTH to 4096

Keep the rest of the options as debug.

Click on “Run Implementation”. (see Figure 44)

Figure 44 - Run Implementation with Debug Cores



After implememtaion is finished, click on “Generate Bitstream” to generate the bistream. (see Figure 45)

Figure 45 - Generate Bitstream with Debug Cores

Make sure the bitstream is generated without any timing issues.



Debugging On HW

Connect KC705 board with a computer using Ethernet Cable.

Program FPGA

As the ChipScope ILA core is v2.1 version, we need to use Vivado Logic Analyzer to debug the design. Click on “Open Hardware Session” as below. (see Figure 46)

Figure 46 - Open Hardware Session in Vivado

Click on “Open a new hardware target”. (see Figure 47)

Figure 47 - Open a New Hardware Target



Figure 48 - Specify Vivado CES Server Name



Figure 49 - Selecting Hardware Target and Providing Instruction Register Length (IR Length)



Figure 50 - Set Hardware Target Properties



Figure 51 - Hardware Target Summary

Once you finish opening a connection to a hardware target, the “Hardware” window is populated with the hardware server, hardware target, and various hardware devices for the open target. (see Figure 52)

Figure 52 - Hardware View after Opening a Connection to the Hardware Target

After connecting to the hardware target and before you program the FPGA device, you need to associate the bitstream data programming file with the device. Select the hardware device in the Hardware window and make sure the Programming file property in the Properties window is set to the appropriate bitstream data (.bit) file. (see Figure 53)



Figure 53 - Associating Programming File

Otherwise, select the associated bitstream. (see Figure 54)

Figure 54 - Assigning Programming File Manually

Click on “Program Devices”. (see Figure 55)



Figure 55 - Programming FPGA

Check the DONE status in the Hardware Device Properties view. (see Figure 56)

Figure 56 - Checking Programming is DONE

The Hardware window now shows the ILA and VIO cores that were detected when scanning the device. (see Figure 57)



Figure 57 - ILA Core is Present in Hardware Session

The ILA core(s) that you add to your design appear in the Hardware window under the target device. If you do not see the ILA core(s) appear, right-click on the device and select Refresh Hardware. This re-scans the FPGA device and refreshes the Hardware window. Before going to the next step, we set the speed to 1G by setting the DIP Switch. (see Figure 58) SW11 [1] = 1 SW11 [2] = 1 And then we can press the update_speed button SW5. You will see LINK LED showing a Duplex connection and speed is 1G. (see Figure 58) And then we should also enable pattern generator by setting the DIP switch. (see Figure 58) SW11 [3] = 1 When pattern generator is enabled, you will see LEDs Activity info is flashing.

Figure 58 - KC705 Board Connectivity



Setting the ILA Core Trigger Condition

Use the Trigger Cond control in the ILA Cores tab in the Debug Probes window (or the Trigger Condition property in the ILA Core Properties window) to select between “AND” and “OR” settings. The “AND” setting causes a trigger event when all of the ILA probe comparisons are satisfied. The “OR” setting causes a trigger event when any of the ILA probe comparisons are satisfied. Here is the Debug Probe window. (see Figure 59)

Figure 59 - ILA Debug Probes Window

To capture the 1

st packet on the axi4 stream TX Interface, we can set up the following:

*********************************************************************** tx_axis_mac_tdata = 16h’5A



tx_axis_mac_tready = 2b’1 tx_axis_mac_tvalid = 2b’1 ***********************************************************************

And set up the Trigger Pos to 512. (see Figure 60)

Use the Trigger Pos control in the ILA Cores tab in the Debug Probes window (or the Trigger Position property in the ILA Core Properties window) to set the position of the trigger mark in the captured data buffer. You can set the trigger position to any sample number in the captured data buffer. For instance, in the case of a captured data buffer that is 1024 samples deep:

Sample number 0 corresponds to the first (left-most) sample in the captured data buffer.

Sample number 1023 corresponds to the last (right-most) sample in the captured data buffer.

Samples numbers 511 and 512 correspond to the two “centre” samples in the captured data buffer.

Figure 60 - Setting Up the Trigger Conditions

Click on the “Run Trigger Immediate” button on the left of the Probe window.

Figure 61 - Run Trigger

Here is what shows up in the waveform. We can see the Ethernet packets going through MAC AXI4 Stream Interface to MAC. (see Figure 62)



Figure 62 - Overview Capture in Debug Probes

Analyzing the packets on each interface

Let’s take a closer look at the MAC AXI4 Stream TX interface. (see Figure 63)

Figure 63 - MAC AXI4 Stream TX Interface

When zooming in on a packet on the MAC AXI4 Stream TX interface, we can see “5A-01-02-03-04-05” which is the Source Address; followed by the Destination address “DA-01-02-03-04-05”. Because the packet is too long, here we only capture the beginning of an Ethernet packet and the end of it. (see Figure 64 and Figure 65)

Figure 64 - Zoomed-in Data Packet on MAC AXI4 Stream TX Interface (part 1)

Figure 65 - Zoomed-in Data Packet on MAC AXI4 Stream TX Interface (part 2)

On the MAC to SGMII TX Interface, we can see the following. (see Figure 66)

Figure 66 - MAC and SGMII TX Interface



When zooming in a packet on the MAC to SGMII interface, we can also see “5A-01-02-03-04-05” which is the Source Address; followed by the Destination address “DA-01-02-03-04-05”.

Figure 67 - Zoomed-in Data Packet on MAC to SGMII TX Interface (part 1)

Figure 68 - Zoomed-in Data Packet on MAC to SGMII TX Interface (part 2)

On the SGMII to GT Interface, we can see the following. (see Figure 69)

Figure 69 - SGMII to GT TX Interface

When zooming in a packet on the SGMII to GT interface, we can see “FB” to indicate the start of a packet, and “FD” to indicate the end of a packet. We can also see “5A-01-02-03-04-05” which is the Source Address; followed by the Destination address “DA-01-02-03-04-05”.

Figure 70 - Zoomed-in Data Packet on SGMII to GT TX Interface (part 1)

Figure 71 - Zoomed-in Data Packet on SGMII to GT TX Interface (part 2)

On the host PC, we can use Wireshark to see the Ethernet packets generated by the pattern generator. (see Figure 722)



Figure 72 - Frame Generator in Wireshark

The frame that we have captured is No61. (see Figure 73)



Figure 73 - Frame (Captured in ILA) Shown in Wireshark

Testing in Loopback

As we are going to debug KC705 connected to a host PC. We can also enable loopback, so we can observe the data being looped back on RX interface. To enable the loopback in SGMII, modify the configuration vector in the toplevel file: *********************************************************************** sgmii_configuration_vector <= "10010"; --[4]AN enable,[3]Isolate disabled,[2]Powerdowndisabled,[1]loopback disabled, [0] Unidirectional disabled ***********************************************************************

After this, you need to re-run synthesis and generate bitstream. You can follow the same debug steps. You should see something like this below. You’ll notice the data loopback form SGMII-to-MAC RX interface and then on the MAC AXI4 Stream RX interface. (see Figure 74) With this loopback, you will not see the data coming in from the GT-to SGMII RX interface.



Figure 74 - Loopback Enabled in SGMII

You can also enable the GT PMA loopback by setting the loopback vector to “010” in the file “gig_ethernet_pcs_pma_0_transceiver.vhd”, shown as below: *********************************************************************** gtwizard_inst : gig_ethernet_pcs_pma_0_GTWIZARD_init generic map ( EXAMPLE_SIM_GTRESET_SPEEDUP => "TRUE", EXAMPLE_SIMULATION => EXAMPLE_SIMULATION ) port map ( … ------------------------ loopback and powerdown ports ------------------ gt0_loopback_in => "010",

… ); ***********************************************************************

You should be able to see the data looped back to the GT RX interface.

Revision History

06/05/2011- Initial Release

xilinx answer 59968 connecting temac and sgmii …...pma_reset : in std_logic; -- transceiver pma...

Documents