ethernet on spartan 3an

Discussion in 'VHDL' started by revkarol, Mar 1, 2013.

  1. revkarol

    revkarol Guest

    Hi,

    I've a starter kit board for the Spartan 3an. This includes and RJ45 Ethernet jack. I'd like to use this to send data down the line to my PC. To simplify matters somewhat, I have an extra network card so it's not on the general LAN. All I want to do is send some (ideally UDP) data, in one direction down the line from the FPGA to the PC. Speed is not an issue as this is mostly a training exercise to 10Mbps is fine. On the PC end I can use some data capture/snooping tool to grab the data.

    Not sure, but perhaps I need a crossover cable or switch between the two?

    My current feeble attempt suggests that I need to use some IP core for Ethernet. Since I've mostly be writing raw VHDL from scratch so far this is new. But also a good thing since I'd like learn how to add various IP cores to a project.

    I've managed to get a temporary licence for the TEMAC (TriMode Ethernet MAC) and generate a core using the Xilinx CORE generator with the MII setting which seems fine for 10Mbps.

    I've managed to get the shipped example synthesized and generate the firmware. However I don't think it's working as I don't see any link activity onthe RJ45 LEDs.

    Basically, I'm not sure if this is the right way to attack the problem. Nor where to go next. Should I add the UDP layer in VHDL?

    Advance thanks for any help/advice given,
    Karol.
    revkarol, Mar 1, 2013
    #1
    1. Advertising

  2. revkarol

    GaborSzakacs Guest

    revkarol wrote:
    > Hi,
    >
    > I've a starter kit board for the Spartan 3an. This includes and RJ45 Ethernet jack. I'd like to use this to send data down the line to my PC. To simplify matters somewhat, I have an extra network card so it's not on the general LAN. All I want to do is send some (ideally UDP) data, in one direction down the line from the FPGA to the PC. Speed is not an issue as this is mostly a training exercise to 10Mbps is fine. On the PC end I can use some data capture/snooping tool to grab the data.
    >
    > Not sure, but perhaps I need a crossover cable or switch between the two?
    >
    > My current feeble attempt suggests that I need to use some IP core for Ethernet. Since I've mostly be writing raw VHDL from scratch so far this is new. But also a good thing since I'd like learn how to add various IP cores to a project.
    >
    > I've managed to get a temporary licence for the TEMAC (TriMode Ethernet MAC) and generate a core using the Xilinx CORE generator with the MII setting which seems fine for 10Mbps.
    >
    > I've managed to get the shipped example synthesized and generate the firmware. However I don't think it's working as I don't see any link activity on the RJ45 LEDs.
    >
    > Basically, I'm not sure if this is the right way to attack the problem. Nor where to go next. Should I add the UDP layer in VHDL?
    >
    > Advance thanks for any help/advice given,
    > Karol.


    What does the example design do? Is it one the usual echo programs
    where it just takes the incoming packed and reverses the MAC addresses?
    If so you'd need to make sure your PC was sending packets. I've found
    that if you have nothing else connected to the PC ethernet port, it
    will send packets for a short period after recognizing that the link
    (PHY) is up. Usually some broadcast ARP packets. If your TEMAC is set
    up with address filtering, I'm not sure if it lets these through or not.
    Since you are making a point-to-point connection for your project,
    the TEMAC should probably be configured without address filtering.
    Otherwise you may need to manually set up the MAC address for the
    board at the PC end like:

    arp -s AA-BB-CC-DD-EE-FF 192.168.2.15

    where AA-BB-CC-DD-EE-FF is the MAC address of the TEMAC and 192.168.2.15
    would be reachable by the ethernet port of the PC as configured (fixed
    IP address and mask). At that point you can run wireshark and try
    to ping 192.168.2.15

    You won't get response from the ping, but if the echo program is
    working correctly, it should show each attempted ping packet twice.

    All this presumes that the link is up and the MAC is running properly.
    I seem to remember that there was a very odd set of clocking required
    to run ethernet at more than one speed, if you're using a GMII/MII
    PHY part (typical xilinx boards have the Marvell 88E1111 or similar).

    -- Gabor
    GaborSzakacs, Mar 1, 2013
    #2
    1. Advertising

  3. revkarol

    revkarol Guest

    Hi Gabor,

    Thanks for the quick response. OK, the info you provided is certainly useful. I am using the standard echo example as you call it.

    One quick question - I think much of the source of my current confusion is the fact that the constraints file provided with the example looks like Greek to me. There is no mention of pin locations specified. Do I have to add these by hand or is there some magic in the "CONFIG PART" directive?

    I'll attach the constraints file in the following post if that helps.

    Thanks again,
    Karol.


    On Friday, March 1, 2013 3:09:03 PM UTC+1, Gabor Sz wrote:
    > revkarol wrote:
    >
    > > Hi,

    >
    > >

    >
    > > I've a starter kit board for the Spartan 3an. This includes and RJ45 Ethernet jack. I'd like to use this to send data down the line to my PC. To simplify matters somewhat, I have an extra network card so it's not on the general LAN. All I want to do is send some (ideally UDP) data, in one direction down the line from the FPGA to the PC. Speed is not an issue as this is mostly a training exercise to 10Mbps is fine. On the PC end I can use some data capture/snooping tool to grab the data.

    >
    > >

    >
    > > Not sure, but perhaps I need a crossover cable or switch between the two?

    >
    > >

    >
    > > My current feeble attempt suggests that I need to use some IP core for Ethernet. Since I've mostly be writing raw VHDL from scratch so far this is new. But also a good thing since I'd like learn how to add various IP cores to a project.

    >
    > >

    >
    > > I've managed to get a temporary licence for the TEMAC (TriMode EthernetMAC) and generate a core using the Xilinx CORE generator with the MII setting which seems fine for 10Mbps.

    >
    > >

    >
    > > I've managed to get the shipped example synthesized and generate the firmware. However I don't think it's working as I don't see any link activity on the RJ45 LEDs.

    >
    > >

    >
    > > Basically, I'm not sure if this is the right way to attack the problem.Nor where to go next. Should I add the UDP layer in VHDL?

    >
    > >

    >
    > > Advance thanks for any help/advice given,

    >
    > > Karol.

    >
    >
    >
    > What does the example design do? Is it one the usual echo programs
    >
    > where it just takes the incoming packed and reverses the MAC addresses?
    >
    > If so you'd need to make sure your PC was sending packets. I've found
    >
    > that if you have nothing else connected to the PC ethernet port, it
    >
    > will send packets for a short period after recognizing that the link
    >
    > (PHY) is up. Usually some broadcast ARP packets. If your TEMAC is set
    >
    > up with address filtering, I'm not sure if it lets these through or not.
    >
    > Since you are making a point-to-point connection for your project,
    >
    > the TEMAC should probably be configured without address filtering.
    >
    > Otherwise you may need to manually set up the MAC address for the
    >
    > board at the PC end like:
    >
    >
    >
    > arp -s AA-BB-CC-DD-EE-FF 192.168.2.15
    >
    >
    >
    > where AA-BB-CC-DD-EE-FF is the MAC address of the TEMAC and 192.168.2.15
    >
    > would be reachable by the ethernet port of the PC as configured (fixed
    >
    > IP address and mask). At that point you can run wireshark and try
    >
    > to ping 192.168.2.15
    >
    >
    >
    > You won't get response from the ping, but if the echo program is
    >
    > working correctly, it should show each attempted ping packet twice.
    >
    >
    >
    > All this presumes that the link is up and the MAC is running properly.
    >
    > I seem to remember that there was a very odd set of clocking required
    >
    > to run ethernet at more than one speed, if you're using a GMII/MII
    >
    > PHY part (typical xilinx boards have the Marvell 88E1111 or similar).
    >
    >
    >
    > -- Gabor
    revkarol, Mar 1, 2013
    #3
  4. revkarol

    revkarol Guest

    # the part selection and associated pin choices (if any) are intended as
    # an example for the family selected. Please refer to the User Guide
    # for more information about IO selection.
    CONFIG PART = xc3s700an-fgg484-4;


    #
    ####
    #######
    ##########
    #############
    #################
    #EXAMPLE DESIGN CONSTRAINTS

    ############################################################
    # Clock Period Constraints #
    ############################################################


    ############################################################
    # RX Clock period Constraints #
    ############################################################
    # Receiver clock period constraints: please do not relax
    NET "mii_rx_clk" TNM_NET = "clk_rx";
    TIMESPEC "TS_rx_clk" = PERIOD "clk_rx" 40000 ps HIGH 50 %;




    ############################################################
    # TX Clock period Constraints #
    ############################################################
    # Transmitter clock period constraints: please do not relax



    NET "mii_tx_clk" TNM_NET = "clk_tx_mii";
    TIMESPEC "TS_tx_clk_mii" = PERIOD "clk_tx_mii" 40000 ps HIGH 50 %;







    ############################################################
    # NOTE: The transmitter and receiver statistic vectors are #
    # routed to IOB's in this design example only to enable #
    # them to be viewed from the demonstration testbench. In a #
    # real design it is expected that they will either be left #
    # unconnected or used internally within the FPGA to #
    # generate further statistical counters. #
    ############################################################

    INST *rx_statistics_valid IOB = true;
    INST *rx_statistics_vector IOB = true;
    INST *tx_statistics_valid IOB = true;
    INST *tx_statistics_vector IOB = true;



    ############################################################
    # NOTE: The async reset is first captured with an async #
    # reset synch to ensure it is maintained for a minimum #
    # duration - paths from this are TIG as it will always be #
    # locally synced
    ############################################################

    INST "*x_reset_gen?reset_sync2" TNM = "REF_RESET";
    TIMESPEC "TS_ref_reset" = FROM "REF_RESET" TIG;



    ############################################################
    # The RX_clk/TX_clk outputs used by the demo_tb are now #
    # sourced from DDR registers - these outputs have to be #
    # tied such that the shared pin doesn't violate routing by #
    # being attached to a signal from a different clock domain #
    # with an IOB register (only one clock can be routed to an #
    # IOB pad/pin pair) - the only way to guarantee this is #
    # through a PROHIBIT #
    ############################################################
    INST "rx_clk" LOC = "V19";
    CONFIG PROHIBIT = U18;
    INST "tx_clk" LOC = "G20";
    CONFIG PROHIBIT = H20;



    #
    ####
    #######
    ##########
    #############
    #################
    #LOCAL LINK CONSTRAINTS

    ############################################################
    # FIFO Clock Crossing Constraints #
    ############################################################
    ## TX Client FIFO
    # Group the clock crossing signals into timing groups
    INST "*client_side_FIFO/tx_fifo_i/rd_tran_frame_tog" TNM = "tx_fifo_rd_to_wr";
    INST "*client_side_FIFO/tx_fifo_i/rd_addr_txfer*" TNM = "tx_fifo_rd_to_wr";
    INST "*client_side_FIFO/tx_fifo_i/rd_txfer_tog" TNM = "tx_fifo_rd_to_wr";
    INST "*client_side_FIFO/tx_fifo_i/rd_retran_frame_tog" TNM = "tx_fifo_rd_to_wr";
    INST "*client_side_FIFO/tx_fifo_i/rd_col_window_pipe_1" TNM = "tx_fifo_rd_to_wr";

    INST "*client_side_FIFO/tx_fifo_i/wr_frame_in_fifo" TNM = "tx_fifo_wr_to_rd";

    TIMESPEC "TS_tx_fifo_rd_to_wr" = FROM "tx_fifo_rd_to_wr" TO clk_tx_mii 38000 ps DATAPATHONLY;
    TIMESPEC "TS_tx_fifo_wr_to_rd" = FROM "tx_fifo_wr_to_rd" TO clk_tx_mii 38000 ps DATAPATHONLY;

    # Reduce clock period to allow for metastability settling time
    INST "*client_side_FIFO/tx_fifo_i/wr_col_window_pipe_0" TNM = "tx_metastable";
    TIMESPEC "ts_tx_meta_protect" = FROM "tx_metastable" 5 ns;

    # constrain the input to this register - this is a multicycle path due to the
    # resync of the control
    INST "*client_side_FIFO/tx_fifo_i/rd_addr_txfer*" TNM = "tx_addr_rd";
    INST "*client_side_FIFO/tx_fifo_i/wr_rd_addr*" TNM = "tx_addr_wr";

    TIMESPEC "TS_tx_fifo_addr" = FROM "tx_addr_rd" TO "tx_addr_wr" 10ns;


    ## RX Client FIFO
    # Group the clock crossing signals into timing groups
    INST "*client_side_FIFO/rx_fifo_i/wr_store_frame_tog" TNM = "rx_fifo_wr_to_rd";
    INST "*client_side_FIFO/rx_fifo_i/rd_addr*" TNM = "rx_fifo_rd_to_wr";

    TIMESPEC "TS_rx_fifo_wr_to_rd" = FROM "rx_fifo_wr_to_rd" TO clk_tx_mii 38000 ps DATAPATHONLY;
    TIMESPEC "TS_rx_fifo_rd_to_wr" = FROM "rx_fifo_rd_to_wr" TO "clk_rx" 38000 ps DATAPATHONLY;




    #
    ####
    #######
    ##########
    #############
    #################
    #BLOCK CONSTRAINTS

    ############################################################
    # External MII Constraints #
    ############################################################

    # MII Transmitter Constraints: place flip-flops in IOB
    INST "*trimac_block*mii_interface*mii_txd*" IOB = true;
    INST "*trimac_block*mii_interface*mii_tx_en" IOB = true;
    INST "*trimac_block*mii_interface*mii_tx_er" IOB = true;

    # MII Receiver Constraints: place flip-flops in IOB
    INST "*trimac_block*mii_interface*rxd_to_mac*" IOB = true;
    INST "*trimac_block*mii_interface*rx_dv_to_mac" IOB = true;
    INST "*trimac_block*mii_interface*rx_er_to_mac" IOB = true;

    # MII IOSTANDARD Constraints: . LVTTL is not the default I/O
    # Standard for Virtex5, Virtex4 and Spartan3 devices:
    # use the following constraints with the device IO Banking rules.

    INST "mii_txd<?>" IOSTANDARD = LVTTL;
    INST "mii_tx_en" IOSTANDARD = LVTTL;
    INST "mii_tx_er" IOSTANDARD = LVTTL;

    INST "mii_rxd<?>" IOSTANDARD = LVTTL;
    INST "mii_rx_dv" IOSTANDARD = LVTTL;
    INST "mii_rx_er" IOSTANDARD = LVTTL;

    INST "mii_tx_clk" IOSTANDARD = LVTTL;
    INST "mii_rx_clk" IOSTANDARD = LVTTL;

    INST "mii_col" IOSTANDARD = LVTTL;
    INST "mii_crs" IOSTANDARD = LVTTL;


    ############################################################
    # The following are only specified to help the tools place #
    # the design without specifically place I/O. These can be #
    # removed when the I/Os are placed in accordance with the #
    # select banking IO rules. #
    ############################################################
    INST "rx_clk" IOSTANDARD = LVTTL;
    INST "rx_statistics_vector" IOSTANDARD = LVTTL;
    INST "tx_statistics_vector" IOSTANDARD = LVTTL;
    INST "rx_statistics_valid" IOSTANDARD = LVTTL;
    INST "tx_clk" IOSTANDARD = LVTTL;
    INST "tx_statistics_valid" IOSTANDARD = LVTTL;
    INST "pause_req" IOSTANDARD = LVTTL;
    INST "pause_val" IOSTANDARD = LVTTL;
    INST "configuration_vector<*>" IOSTANDARD = LVTTL;



    ############################################################
    # For Setup and Hold time analysis on MII inputs #
    ############################################################

    # Identify MII Rx Pads only.
    # This prevents setup/hold analysis being performed on false inputs,
    # eg, the configuration_vector inputs.
    INST "mii_rxd<?>" TNM = IN_MII;
    INST "mii_rx_dv" TNM = IN_MII;
    INST "mii_rx_er" TNM = IN_MII;

    # Define data valid window with respect to the clock.
    # The spec states that, worst case, the data is valid 10 ns before the clock edge.
    # The worst case it to provide 10 ns hold time (a 20 ns window in total)
    TIMEGRP "IN_MII" OFFSET = IN 10 ns VALID 20 ns BEFORE "mii_rx_clk";



    #
    ####
    #######
    ##########
    #############
    #################
    #CORE CONSTRAINTS



    ############################################################
    # Crossing of Clock Domain Constraints: please do not edit #
    ############################################################
    # Flow Control logic reclocking - control sugnal is synchronised
    INST "*trimac_core*FLOW?RX_PAUSE?PAUSE_REQ_TO_TX" TNM="flow_rx_to_tx";
    INST "*trimac_core*FLOW?RX_PAUSE?PAUSE_VALUE_TO_TX*" TNM="flow_rx_to_tx";
    TIMESPEC "TS_flow_rx_to_tx" = FROM "flow_rx_to_tx" TO clk_tx_mii 38000 ps DATAPATHONLY;




    ############################################################
    # Ignore paths to resync flops
    ############################################################
    INST "*/data_sync" TNM = "resync_reg";
    TIMESPEC "ts_resync_flops" = TO "resync_reg" TIG;

    INST "*trimac_core*TXGEN*INT_CRS" TNM = "tx_async_reg";
    INST "*trimac_core*TXGEN*REG_COL" TNM = "tx_async_reg";
    INST "*trimac_core*GMII_MII_TX_GEN*COL_REG1" TNM = "tx_async_reg";

    # following two can be ignored as signal being captured is stable for multiple cycles
    # in cases where it is used
    INST "*trimac_core*TXGEN*REG_TX_EN_IN" TNM = "tx_async_reg";
    INST "*trimac_core*TXGEN*REG_TX_ER_IN" TNM = "tx_async_reg";
    TIMESPEC "ts_tx_async_regs" = TO "tx_async_reg" TIG;
    revkarol, Mar 1, 2013
    #4
  5. revkarol

    GaborSzakacs Guest

    revkarol wrote:
    > Hi Gabor,
    >
    > Thanks for the quick response. OK, the info you provided is certainly useful. I am using the standard echo example as you call it.
    >
    > One quick question - I think much of the source of my current confusion is the fact that the constraints file provided with the example looks like Greek to me. There is no mention of pin locations specified. Do I have to add these by hand or is there some magic in the "CONFIG PART" directive?
    >
    > I'll attach the constraints file in the following post if that helps.
    >
    > Thanks again,
    > Karol.
    >
    >
    > On Friday, March 1, 2013 3:09:03 PM UTC+1, Gabor Sz wrote:
    >> revkarol wrote:
    >>
    >>> Hi,
    >>> I've a starter kit board for the Spartan 3an. This includes and RJ45 Ethernet jack. I'd like to use this to send data down the line to my PC. To simplify matters somewhat, I have an extra network card so it's not on the general LAN. All I want to do is send some (ideally UDP) data, in one direction down the line from the FPGA to the PC. Speed is not an issue as this is mostly a training exercise to 10Mbps is fine. On the PC end I can use some data capture/snooping tool to grab the data.
    >>> Not sure, but perhaps I need a crossover cable or switch between the two?
    >>> My current feeble attempt suggests that I need to use some IP core for Ethernet. Since I've mostly be writing raw VHDL from scratch so far this is new. But also a good thing since I'd like learn how to add various IP cores to a project.
    >>> I've managed to get a temporary licence for the TEMAC (TriMode Ethernet MAC) and generate a core using the Xilinx CORE generator with the MII setting which seems fine for 10Mbps.
    >>> I've managed to get the shipped example synthesized and generate the firmware. However I don't think it's working as I don't see any link activity on the RJ45 LEDs.
    >>> Basically, I'm not sure if this is the right way to attack the problem. Nor where to go next. Should I add the UDP layer in VHDL?
    >>> Advance thanks for any help/advice given,
    >>> Karol.

    >>
    >>
    >> What does the example design do? Is it one the usual echo programs
    >>
    >> where it just takes the incoming packed and reverses the MAC addresses?
    >>
    >> If so you'd need to make sure your PC was sending packets. I've found
    >>
    >> that if you have nothing else connected to the PC ethernet port, it
    >>
    >> will send packets for a short period after recognizing that the link
    >>
    >> (PHY) is up. Usually some broadcast ARP packets. If your TEMAC is set
    >>
    >> up with address filtering, I'm not sure if it lets these through or not.
    >>
    >> Since you are making a point-to-point connection for your project,
    >>
    >> the TEMAC should probably be configured without address filtering.
    >>
    >> Otherwise you may need to manually set up the MAC address for the
    >>
    >> board at the PC end like:
    >>
    >>
    >>
    >> arp -s AA-BB-CC-DD-EE-FF 192.168.2.15
    >>
    >>
    >>
    >> where AA-BB-CC-DD-EE-FF is the MAC address of the TEMAC and 192.168.2.15
    >>
    >> would be reachable by the ethernet port of the PC as configured (fixed
    >>
    >> IP address and mask). At that point you can run wireshark and try
    >>
    >> to ping 192.168.2.15
    >>
    >>
    >>
    >> You won't get response from the ping, but if the echo program is
    >>
    >> working correctly, it should show each attempted ping packet twice.
    >>
    >>
    >>
    >> All this presumes that the link is up and the MAC is running properly.
    >>
    >> I seem to remember that there was a very odd set of clocking required
    >>
    >> to run ethernet at more than one speed, if you're using a GMII/MII
    >>
    >> PHY part (typical xilinx boards have the Marvell 88E1111 or similar).
    >>
    >>
    >>
    >> -- Gabor

    >


    You need to make sure that there are LOC constraints for every top-level
    port (FPGA pin) in the design. I saw only a couple in the constraints
    you posted. These have to match your actual hardware if you're using
    a board which is already built. If you're just starting out and plan
    to build a board after the design is complete, then you can start by
    letting the tools place the I/O's for you and lock them down when you
    are satisfied (back-annotate). If you're using a development board,
    you should have received a standard UCF file with it, that includes
    constraints for all pins including location and IO standard. ISE
    allows you to use more than one UCF file in a project, so you could
    have one with the board-level location and IO standard constraints
    and another with the timing constraints required by the core.

    -- Gabor
    GaborSzakacs, Mar 1, 2013
    #5
  6. revkarol

    Guest

    בת×ריך ×™×•× ×©×™×©×™, 1 במרץ 2013 15:32:35 UTC+2, מ×ת revkarol:
    > Hi,
    >
    >
    >
    > I've a starter kit board for the Spartan 3an. This includes and RJ45 Ethernet jack. I'd like to use this to send data down the line to my PC. To simplify matters somewhat, I have an extra network card so it's not on the general LAN. All I want to do is send some (ideally UDP) data, in one direction down the line from the FPGA to the PC. Speed is not an issue as thisis mostly a training exercise to 10Mbps is fine. On the PC end I can use some data capture/snooping tool to grab the data.
    >
    >
    >
    > Not sure, but perhaps I need a crossover cable or switch between the two?
    >
    >
    >
    > My current feeble attempt suggests that I need to use some IP core for Ethernet. Since I've mostly be writing raw VHDL from scratch so far this is new. But also a good thing since I'd like learn how to add various IP cores to a project.
    >
    >
    >
    > I've managed to get a temporary licence for the TEMAC (TriMode Ethernet MAC) and generate a core using the Xilinx CORE generator with the MII setting which seems fine for 10Mbps.
    >
    >
    >
    > I've managed to get the shipped example synthesized and generate the firmware. However I don't think it's working as I don't see any link activity on the RJ45 LEDs.
    >
    >
    >
    > Basically, I'm not sure if this is the right way to attack the problem. Nor where to go next. Should I add the UDP layer in VHDL?
    >
    >
    >
    > Advance thanks for any help/advice given,
    >
    > Karol.


    You may be interested to look on:
    "...project implements an IP TTL filter in hardware. If an IPV4 packet is identified, the machine checks its TTL field. Based on previous values of TTL data collected and analyzed from former packets, the machine decides if the packet is spoofed or not..."
    http://bknpk.no-ip.biz/my_web/SDIO/ip_ttl_filter_main.html
    , Aug 13, 2013
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Nicklas

    Ethernet MAC core

    Michael Nicklas, Nov 12, 2003, in forum: VHDL
    Replies:
    2
    Views:
    3,740
    Allan Herriman
    Nov 13, 2003
  2. Replies:
    1
    Views:
    1,499
    Mike Treseler
    Sep 20, 2005
  3. Replies:
    0
    Views:
    551
  4. Etantonio
    Replies:
    2
    Views:
    515
    Etantonio
    Jul 16, 2008
  5. CreeD_XIII

    Spartan 3an Rotary Encoder

    CreeD_XIII, Jun 23, 2009, in forum: VHDL
    Replies:
    0
    Views:
    1,510
    CreeD_XIII
    Jun 23, 2009
Loading...

Share This Page