ethernet on spartan 3an

[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 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.

 

[GaborSzakacs]

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

 

[revkarol]

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.

 

[revkarol]

# 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;

 

[GaborSzakacs]

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.

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

 

[bknpk]

בת×ריך ×™×•× ×©×™×©×™, 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