How can I get data from Altera Triple Speed Ethernet (TSE) MAC through Avalon bus?

Hi,

There is actually 2 types of Avalon "bus" that TSE uses. Following is how the "bus" talk.

a. data path

To be exact the TSE MAC has 2 Avalon-Streaming interfaces (TX and RX path) for the data plane (http://www.altera.com/literature/fs/fs_avalon_streaming.pdf) on the fifo/application side. This interface consist of only SOP, DATA, EMPTY, VALID, READY and EOP signal. It is a point to point protocol and it is not a bus. You need to write a state machine that can (on RX path)

1. assert the READY signal whenever your DMA (for dumping data to memory) is ready to accept data

2. start to accept the first unit of DATA whenever SOP and VALID is asserted high

3. continue to accept the DATA as long as VALID is high, and continue to assert READY as read acknowledge to the TSE MAC or de-assert it to back pressure/stop transaction

3. only consume the bytes depend on the EMPTY signal on the last unit of data whenever EOP is asserted high (only if you are using 32-bit FIFO interface)

Sure for every VALID and READY is high-> valid data is accepted by you, you state machine should dump it to the memory.

You might need to take a look at the definition of the READY LATENCY in the back pressure section in the specification, it is a little bit different from what we generally think READY signal is for in this interface.

b.control path

There is another register read/write interface for the MAC configuration as a control plane called AValon-Memory Map interface, but it is no more than a interface consist of address, write, read, readdata, writedata signal(you don't even need to read the spec). You just need to write a sequential state machine to setup all the configuration register one by one so that the MAC work in a way you expect in the beginning, it is very simple.

Finally, you can almost ignore all other signals that is exist on the MAC interface but is not mentioned here. You might use them, if you need extra info on the MAC FIFO status, to use a signal instead of register write to change settings and so on.

Note: to be precise, both Avalon-ST and Avalon-MM is not a bus, it is a point-point connection (avalon-ST), and multi-point to multi-point connection switch fabric (avalon-MM). It doesn't time-share a communication path like a bus:) Anyway, without using SOPC Builder, Avalon-MM is merely a register read/write interface without any magic(quite a lot). Avalon-ST in the other hand doesn't does much magic even in SOPC builder.

Hi!

I'm also using TSE without Nios II and I have made a process using the Avalon-MM interface to configure mac address and so on on the TSE. I have also made a small receiver which use the Avalon-ST to get data from RX FIFO. SInce I don't have any higher protocols such as IP and TCP i have used the arp command on the host pc to set a fix IP-mac combination and when I ping my card I see activity on the PHY leds but valid (avalon-st) is not set high. As of now I just count the number of times Valid is set high but I can't see any "traffic" to my module. How can I verify that the TSE MAC is running and "handling" traffic? My next idea is to read out all registers to make sure that they are correct but then I only have 8 leds to "show" their values on. Does anyone have an ide of what registers needs to be set and how to set them i.e. how to set mac address so that it is not mirrored or something like that.

Question:

Assume that you have the hardware wired up correctly (clock, control and data path)

MAC Config:

1. Do you set the MAC address register 1 (lower 4 bytes) and 2 (uppper 2 bytes)?

Do your ARP packet contains the MAC address of the MAC you set? The MAC will not pass through any packet to the Avalon-ST interface if the unicast MAC address is not match if it is not work in the promiscuous mode. However packet with broadcast packet will get through.

Suggestion: set the command config register "promiscuous" bit to true, so that any packets detected in the network will get to the Avalon-ST side.

2. Do your system successfully done with software reset? Tight the software reset bit to an LED. This is a self clear command config register bit, if it doesn't not get through, you most probably didn't wire you clock to the MAC correctly. Make sure the RX_ENA command config bit is not zero, and the MAC Internal Loopback bit is of value zero too.

What registers should be read out for debugging?

3. Turn on the statistic counters synthesis option, Read out the Receive Packet counters and Receive Error related counters. Use the push buttons on the board to select which counter's value to display on the LED. You only need to display the lower few bits of the counter. This give you a good insight on does MAC receive any packet and if yes why it doesn't pass through the packet by looking at the error counter; if no, then I would

suggest you check the wiring of the GMII/MII interface and the clock signal wiring. If the wiring is right, what to do next?

others that you might already know:

4. in the MAC configuration, you need to read out PHY autonegatiated speed (10/100/1000) and set the MAC to operate in correct mode through the ETHMODE bit. 10/100 and 1000 has different clocking, you should be able to read this in the user guide.

5. pin mapping on the hardware?

Hi!

Thanks for reply:

General concerns:

- HW pin mapping, the names of the TSE "signals" and the pin mapping of the PCIe dev. board is not 1 to 1. For example I have mapped GM_RX_DV to PIN_E28 which is enet_rx_dv in the board ref. manual.

- The ref. clk of 125MHz in TSE manual is connected to gtx_clk and to tx_clk. Im not sure if I should map it to pin b33 which is enet_gtx_clk or if I can use the same as rx_clk i.e. enet_rx_clk pin M27 (actually signal is "connected" in VHDL i.e. tx_clk <= rx_clk)

- THe rest of my system uses PIN_A20 for clk, I believe it's around 150MHz. Im not sure if it's ok, but I guess it's a different clock domain.

1. I set the mac in the following way

constant mac: std_logic_vector(47 downto 0) := X"861D33B91900";

...

mm_writedata <=mac(31 downto 0);

...

mm_writedata(15 downto 0) <=mac(47 downto 32);

The Command-Config reg:

constant tx_ena: integer := 0;

constant rx_ena: integer := 1;

constant promise_en: integer := 4;

constant tx_addr_ins: integer := 9;

constant rx_err_disc: integer := 26;

...

cc_reg(tx_ena) <='1';

cc_reg(rx_ena) <='1';

cc_reg(promise_en) <='1';

cc_reg(tx_addr_ins) <='1';

cc_reg(rx_err_disc) <='1';

...

write the next cycle.

I'm not sure I understand "Tight the sw reset bit to a LED" I guess i set it with a write <='1', writedata<=... towards avalon-mm then I need to read it once and check if it is still "1". If it is the reset has not "passed" then something is wrong or?

I have set set_1000<='1'; which I guess hard codes the GBit "way". After a PHY reset the 1000 led is shown on the card so I guess the PHY is aligned but I'm not sure what will happend if I connect a 10/100 device.

If needed I can send you my small "project" if it is easier for you too check but I will try to have a look at the reset bit and the stat. regs. I attached the pin file for review.

I have now done a config loop of the MAC and then I read some of the registers out and display them on the LEDs. For some reason TX_ENA is the only one cleared i.e. it is set to '0' which for some unknown reason is the value activating the LEDs on my PCIe dev. board. I now guess this is because the TX clock is not set as it should be. I tried to understand from the documentation how it should be and my idea now is to introduce a PLL which creates a 125MHz clk from the 100MHz input clk. I have tried to find information about this but I can't find any hints about it in this forum. If I look at the data path ref. design which is using SFP instead of "regular" PHY it seams to use some 83.3333... clk which seams odd to me, this must be a different PHY i guess since the "regular" PHY uses 125MHz in "plain GigE" setup. Can anyone describe this clocking issue to me i.e. do I need this PLL to set the clock right.

wbr,

P-A

Hi,

I am currently trying to configure TSE MAC core on Stratix II GX board. Even I have similar confusions with gtx_clk and tx_clk. If you have any further information, please let me know.

Thanks and Regards

Praveen

--- Quote Start ---

Hi!

Thanks for reply:

General concerns:

- HW pin mapping, the names of the TSE "signals" and the pin mapping of the PCIe dev. board is not 1 to 1. For example I have mapped GM_RX_DV to PIN_E28 which is enet_rx_dv in the board ref. manual.

- The ref. clk of 125MHz in TSE manual is connected to gtx_clk and to tx_clk. Im not sure if I should map it to pin b33 which is enet_gtx_clk or if I can use the same as rx_clk i.e. enet_rx_clk pin M27 (actually signal is "connected" in VHDL i.e. tx_clk <= rx_clk)

- THe rest of my system uses PIN_A20 for clk, I believe it's around 150MHz. Im not sure if it's ok, but I guess it's a different clock domain.

1. I set the mac in the following way

constant mac: std_logic_vector(47 downto 0) := X"861D33B91900";

...

mm_writedata <=mac(31 downto 0);

...

mm_writedata(15 downto 0) <=mac(47 downto 32);

The Command-Config reg:

constant tx_ena: integer := 0;

constant rx_ena: integer := 1;

constant promise_en: integer := 4;

constant tx_addr_ins: integer := 9;

constant rx_err_disc: integer := 26;

...

cc_reg(tx_ena) <='1';

cc_reg(rx_ena) <='1';

cc_reg(promise_en) <='1';

cc_reg(tx_addr_ins) <='1';

cc_reg(rx_err_disc) <='1';

...

write the next cycle.

I'm not sure I understand "Tight the sw reset bit to a LED" I guess i set it with a write <='1', writedata<=... towards avalon-mm then I need to read it once and check if it is still "1". If it is the reset has not "passed" then something is wrong or?

I have set set_1000<='1'; which I guess hard codes the GBit "way". After a PHY reset the 1000 led is shown on the card so I guess the PHY is aligned but I'm not sure what will happend if I connect a 10/100 device.

If needed I can send you my small "project" if it is easier for you too check but I will try to have a look at the reset bit and the stat. regs. I attached the pin file for review.

--- Quote End ---

Hi..

can anyone tell me whether TSE MAC supports TCP/IP..?

regards..

--- Quote Start ---

I know the simple answer will be use NisoII...

But in my situation is ..I cannot use NisoII or any other soft/hard

core processor (actually is..I am not able to use any asm/c ..whatever

computer programing language).

I would want to know anyone try to build a FSM to "talk" with the

Avalon bus before?

What should I do/understand first for build a FSM to work as Master in

Avalon bus?

My project require to receive packet and put them into memory and then

I have another logic to read from the memory.

The data flow is that

Ethernet --> PHY(chip) --> TSE MAC IP --> Avalon bus --> memory --

>DDR2 controller ->DDR2 memory.

What I have now:

1. PCI Express Development Kit, Stratix II GX Edition (http://

www.altera.com/products/devkits/altera/kit-pciexpress_s2gx.html (http://www.altera.com/products/devkits/altera/kit-pciexpress_s2gx.html))

2. DDR2 controller demo (non Avalon Bus), (it is work on the PCI

Express Development Kit)

3. TSE MAC IP (I did not try it..because all the demo are using

NiosII)

--- Quote End ---

Hi,

first of all, i'm sorry for posting in a old topic, but i've don't found other posts or places wich can help me and show me a way to start using TSE.

I'm a bit confuse about this:

--- Quote Start ---

b.control path

There is another register read/write interface for the MAC configuration as a control plane called AValon-Memory Map interface, but it is no more than a interface consist of address, write, read, readdata, writedata signal(you don't even need to read the spec). You just need to write a sequential state machine to setup all the configuration register one by one so that the MAC work in a way you expect in the beginning, it is very simple.

--- Quote End ---

does it mean that i must to configure all 256 registers :(??

and, the addres bus is 8 bits width, and the adress are 32 bits width. so, how can i access some address? :confused:

Thanks and happy new year, everyone :D

Regards,

Nathan.