VoIP (AN374) questions

If you use the Avalon bus to connect the RAM, it makes no difference (but performance) to the other parts of the design, what RAM technology is used.

The Avalon bus can do Multi-Master, so sharing the RAM between multiple parts of the design (CPU, Ethernet DMA-controller, your own "hardware") is possible.

I don't see a predefined way to share the TSE (or whatever Ethernet controller) between the CPU and some "hardware" you design. Perhaps another idea is to implement a second Ethernet IP core and use a switch chip with two MII interfaces as a Phy to allow for a single cable. Do you really need GBit ? If no, I suppose using the OpenCore Ethernet controller would be a better idea, as you might be able to modify it in a way that is better suited to interface with your "hardware". Any standard Ethernet core would need a CPU interface, additionally, for configuration purpose.

Do you really want to do the (UDP / ) IP stack in "hardware" (how, if I may ask) ? If no, maybe a second NIOS running a Niche stack might be way to avoid the Linux overhead for the "realtime" network access.

If doing this you maybe could avoid the second Ethernet controller by creating a pure software IP layer interface between the Linux system and the second NIOS.

-Michael

Firstly thanks for your very detailed answer I really appreciate :-)

--- Quote Start ---

Perhaps another idea is to implement a second Ethernet IP core and use a switch chip with two MII interfaces as a Phy to allow for a single cable.

--- Quote End ---

I think about another solution but based on the same trick : try to make the TSE MAC 1000 work with uClinux (I've already have a TSE licence) and keep the hardware data path in GBit mode... Consequently, I could use a switch chip with two GMII interfaces pointing to the same PHY !! I made a complete scheme to illustrate my solution :

http://img213.imageshack.us/img213/5170/voipuclinuxtsemacphyint.png

--- Quote Start ---

Do you really need GBit ?

--- Quote End ---

Yes, I really need GBit because TS bitrate can easily reach 150/200 Mbits...

--- Quote Start ---

Do you really want to do the (UDP / ) IP stack in "hardware" (how, if I may ask) ?

--- Quote End ---

Yes, because the VoIP design (AN374) seems to be the perfect balance between implementation time/complexity, required performance/options (GBit, UDP, RTP, FEC CoP#3...) and configuration possibilities !!

-> I have one last question concerning the support of TSE MAC 1000 with uClinux :

------------------------------------------------------------------------------------------------------

The Nios Wiki (uClinux) page about Ethernet suggests two solutions :

[*] Altera Tripple Speed Ethernet support (EXPERIMENTAL)

exOr,

[*]Altera Triple Speed Ethernet MAC support(SLS)

[*]Drivers for Marvell PHYs

Which choice is the most suitable for an GMII interface with the PHY in Gigabit mode ?? Furthermore, does anyone succeed to use uClinux in Gigabit mode with TSE MAC ??

------------------------------------------------------------------------------------------------------

Thanks for your help !!

Papy

Re your picture: IMHO it does not make much sense to use a Gigabit MAC/PHY for Linux, with a NIOS processor, as the IP stack is too slow to support more than 100 MBit. But if the PHY does need GMII, it's the only option.

I'm really interested in knowing how you do the UDP and IP layers hardware.

Again, it could be possible to use this stack on a higher level (IP) for the CPU, too, instead of implementing a dual MII interface.

I have no knowledge regarding the TSE and I don't intend to use it.

-Michael

--- Quote Start ---

-> I have one last question concerning the support of TSE MAC 1000 with uClinux :

------------------------------------------------------------------------------------------------------

The Nios Wiki (uClinux) page about Ethernet suggests two solutions :

[*] Altera Tripple Speed Ethernet support (EXPERIMENTAL)

exOr,

[*]Altera Triple Speed Ethernet MAC support(SLS)

[*]Drivers for Marvell PHYs

Which choice is the most suitable for an GMII interface with the PHY in Gigabit mode ?? Furthermore, does anyone succeed to use uClinux in Gigabit mode with TSE MAC ??

------------------------------------------------------------------------------------------------------

Thanks for your help !!

Papy

--- Quote End ---

Both drivers work with TSE on uClinux (no MMU), but I haven't gotten the experimental one to work on Linux with MMU. The SLS driver works with MMU with a patch. I suggest using the SLS one because it seems to be more maintained.

I haven't been able to get Gigabit speeds with either driver. That is, the device establishes a gigabit link, but if I time how long it takes from when the driver starts the hardware transmission until the busy bit is cleared, it's only transmitting at 100Mbit. I am using a National Semiconductor PHY rather than the Marvell one.

While you are unlikely to get anywhere near gigabit speeds with Linux because of the processing overhead for the TCP|UDP/IP stack, having the MAC+PHY working at gigabit should get you at least some speed improvement by saving 90% of the hardware transmission time. Let us know how it goes.

--- Quote Start ---

I haven't been able to get Gigabit speeds with either driver. That is, the device establishes a gigabit link, but if I time how long it takes from when the driver starts the hardware transmission until the busy bit is cleared, it's only transmitting at 100Mbit.

--- Quote End ---

It's not a problem for me, considering the fact that I only want a common GMII or RGMII interface between uClinux, VoIP data path and the switch chip block, whatever the transmit speed to uClinux ;) I think this constraint will facilitate the switch chip conception....

--- Quote Start ---

I suggest using the SLS one because it seems to be more maintained.

--- Quote End ---

I encountered some problems using the SLS driver :

----------------------------------------------------------------------------------------------------

0 : New Bus ID

BUG: No TSE MDIO Reset

Altera TSE MII Bus: probed

Found phy with ID=0x1410e80 at address=0x1

Altera TSE MII Bus: MDIO Bus Registered

ERROR :/home/papy/nios2-linux/linux-2.6/drivers/net/altera_tse.c:1701:request

_mem_region() failed

altera_tse: probe of altera_tse.0 failed with error -16

----------------------------------------------------------------------------------------------------

but I read in the following topic it is a quite common issue (end of the page) :

http://alterauserforum.net/forum/showthread.php?t=18802&page=3

The "altera_tse.txt" link proposed by Kazuyasu is very helpful but I still have errors when compilating....

Where can I find the most recent version of the following files ??

nios2-linux/linux-2.6/drivers/net/altera_tse.c

nios2-linux/linux-2.6/drivers/net/altera_tse.h

nios2-linux/linux-2.6/drivers/net/altera_tse_ethtool.c

nios2-linux/linux-2.6/drivers/net/altera_tse_mdio.c

Thanks !

--- Quote Start ---

+ Is it possible to use the altera tse mac in the same time with uclinux (LAN --> webserver and webserver --> LAN) and with the data path (RTP + UDP/IP --> LAN) ??? What happened if uClinux and UDP/IP block sends data simultaneously to the MAC ???

--- Quote End ---

Tried and am getting simultaneous data to MAC - did I miss this workaround?

Hi all,

I have successfully implemented the Video Over IP design (AN374) on my devboard with the FEC functionality disabled (because of a missing high-speed DDR SDRAM on the board). Some details :

1) Only the transmit path (TS-to-Ethernet) is used here

2) Only one Transport Stream (TS) with an average rate of 40Mbits

3) Aggregation = 7 TS packets per Ethernet frame

I can see on Wireshark UDP or RTP frames (depending on how I configure the design) coming from the board but when I check these frames, almost every frame is associated with the following critical error :

-----------------------------------------------------------------------

> Detected missing CC frame before this (accumulated CC loss count:9971)

> Expert Info (Error/Malformed): Detected CC loss

message: detected cc loss

severity level: error

group: malformed

-----------------------------------------------------------------------

If I try to open a VLC player at this network address :

rtp://@227.40.50.60:8192

The video appears but with a high degree of artefacts (green square all over the screen) and when I check the statistics, the number of corrupted packets is very elevated !!!

I don't understand what I'm doing wrong because I can successfully configure the "ts_input", "rtp_tx" and "udp_ip" blocks with the API and the statistics about every block are described exaclty as in the demo settings....

does anyone have experienced this particular issue about packet loss recently with video over ip ??

Thanks for your precious help guys !

Papy

hi,all,

Can you try again to send me the an374 package on my mail:sochuangdz@gmail.com