Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

VoIP (AN374) questions

Altera_Forum
Honored Contributor II
1,339 Views

Hi all, 

 

1) Firstly, I worked on a 3C40 FPGA devboard with a 1Gbe Marvell 88E1119R PHY. 

 

At this time, I have a fully functionnal uClinux + Boa webserver system using Opencores 10/100 MAC, as described in this simple scheme : 

 

http://img260.imageshack.us/img260/192/uclinuxopencoresmac.png 

 

uClinux runs from the SDRAM memory and the Flash memory includes bootloader + JFFS2 file system.... 

 

2) Now, I want to add to this working design the Vider Over IP (AN374) block but only the Transmitter path, as described in this second scheme : 

 

http://img191.imageshack.us/img191/5223/voipuclinuxtsemac.png 

 

I have several high-level questions about this design : 

 

+ Is it possible to use sdram controller instead of ddr sdram controller for the RTP transmitter buffering ?? I think here about latency issues... 

 

+ If YES, is it possible to "share" the sdram between the uClinux system and the RTP transmitter ??  

 

+ 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 ??? 

 

Thanks for your precious help guys !!! 

 

Papy
0 Kudos
11 Replies
Altera_Forum
Honored Contributor II
506 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
506 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
506 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
506 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
506 Views

 

--- 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 !
0 Kudos
Altera_Forum
Honored Contributor II
506 Views

 

--- 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?
0 Kudos
Altera_Forum
Honored Contributor II
506 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
506 Views

hi,all, 

Can you try again to send me the an374 package on my mail:sochuangdz@gmail.com
0 Kudos
Altera_Forum
Honored Contributor II
506 Views

i am using VIOP reference deign in Cyclone II.Whan i am testing(Ethernet to TS) with VLC player it is not working.I am facing some data loss.Whan I am testing with reference design (TS with Ethernet) with reference deign(Ethernet to TS) it is working fine.Kindly suugest is there any other way to fix this.....

0 Kudos
Altera_Forum
Honored Contributor II
506 Views

i can help you ,please contact with me. sochuangdz@gmail.com

0 Kudos
Altera_Forum
Honored Contributor II
506 Views

hello guys......... 

 

i just have the an374 working with a uclinux cpu with boa server to configure the an374..........is finished and working 

 

 

i had some problems like you 

 

 

 

--- Quote Start ---  

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 !! 

--- Quote End ---  

 

 

try look your ts packet size 188 or 204 .....you need detect and if change you need reset the ts input buffer...... 

 

monitore the signal named ts_valid[0] and ts_data at ts input buffer in signal tap 

 

 

 

good luck 

 

 

Franz Wagner
0 Kudos
Reply