Virtex-4 Gigabit Ethernet design

Hi

I'm evaluating one Gigabit Ethernet design who use the hard Temac embedded in the Virtex-4 FX (ML403 evaluation board) for fast image transmision.

The GSRD reference design (xapp546) is my best option, but have a 79% of occupied slices and I need more space for more components and the Treck TCP/IP used is a evaluation versión. It exist the option of the TEMAC UltraController-II but it seem that the PowerPC processor of the Virtex-4 can't be used for others issues and I don't know if the uIP TCP/IP stack used in this design supports Jumbo frames like Treck stack. This jumbo frames are needed for maximum performance at gigabit ethernet.

Somebody have a easy solution to this problem? Another design?

Thank you very much.

Reply to
David
Loading thread data ...

Hi David,

I have a similar project - Camera on Virtex4FX12. I have Memec's FX12 MiniModule and TEMAC reference design uses hard LL_TEMAC core (which has a large FIFO - about 50% of FX12's BRAMs) and an open source lwIP stack version 1.01.a (some kind of workaround to work with TEMAC). I did not test the performance of this system, but I believe It could be equal to your design. I don't like my design because it uses too much BRAM and it cannot make it work in EDK 8.1 (for now). I also wanted to add ChipScope core to it, but there was simply not enough BRAM :( GRRRR. I took a look at the xapp807 (UC-II) but I don't know how to add other peripherals (which I have a lot) and FIFO's are only 1 BRAM block deep

- resulting in poor performance (reported 50 Mbps). Hard TEMAC with sizable FIFO's would be very handy solution with open source lwIP stack.

How do you stream the data to the processor? I am trying to make OPB master peripheral to write data to OPB DDR and then processor can access this data (maybe not suitable for real time streaming but necessary to get all of the 100-200 frames needed).

I would like to get any solution for this problem, so HELP WANTED!

Guru

Reply to
Guru

the Virtex-4 FX (ML403 evaluation board) for fast image transmision.

occupied slices and I need more space for more components and the Treck TCP/IP used is a evaluation versión. It exist the option of the TEMAC UltraController-II but it seem that the PowerPC processor of the Virtex-4 can't be used for others issues and I don't know if the uIP TCP/IP stack used in this design supports Jumbo frames like Treck stack. This jumbo frames are needed for maximum performance at gigabit ethernet.

I'm personnaly working an a project where we need to send a >300 Mbps dataflow to the FPGA and also retrieve some data.

The solution I'm using right now is a PC connected point to point to the virtex4 using a 1000Base-T cat6e cable. The communication is then done at 1Gbps full duplex (other modes are not supported).

The application on the PC just sends the data as fast as possible using raw ethernet frames (not even udp, just the mac header and then directly the payload, with just a seq number so that I can at least spot missing data).

On the FPGA side, I use the hardemac alone with just some custom logic (very simple), to push the incoming data into à 16 kb FIFO (8 BRAMs). To prevent the FIFO ever being full (and thus a need to handle quite frequent retramsimission & co), as soon as the FIFO hits the 3/4, the logic transmits PAUSE frame continuously with a maximum pause time. As soon as the FIFO is not half full anymore, it transmits 1 PAUSE frame with a zero pause time to allow the PC to resume the xfer.

Since this flow control is done in "hardware", that work quite nice and my FIFO never overflows.

Of course that is not "real" tcp-ip and I can't establish connection and co ... just send a datastream. It all depends of what you need ...

Sylvain

Reply to
Sylvain Munaut

I have a similar trouble. Xilinx should provide a plb_temac with lwip support into next release of edk service pack 2.

Memec webserver reference desing is not 100% compatble with edk 8.1i. I have contacted reference design center and they have released a fully compatible version. Now you can download a new version of the design from avnet reference design center.

Then you can make some changes into lwip to make it compatible with edk

8.1i. I already made it. It is quite simple. You should change directory structure and .mld file.

Use the netlist of ll_temac. It works well. Don't re-synthetize, into my system doesn't work.

I have also tried to lower the number of bram, but I wasn't able. It seems that Memec has released the core without some files needed to open fifos into core generator. If you would try, please check the gemac_common. The core is made by ll_temac and gemac_common.

Marco Toschi

Reply to
Marco T.

Hello David,

You don't need to use Jumbo frames to utilize whole power of Gigabit Ethernet. With Virtex4 EMACs we got more than 120MB/s data throughput with plain Ethernet frames. And PC was able to handle this data stream without any problems. We built the streaming hardware within Virtex4FX20 and developed custom protocol driver for MS Widows Ethernet stack. During testing phase we got no errors/retries. With TCP/IP stack you will get less data bandwidth, since each frame will need to have TCP/IP header, but I still think it will not worse to move to Jumbo solution.

With best regards, Vladimir S. Mirgorodsky

David wrote:

d in the Virtex-4 FX (ML403 evaluation board) for fast image transmision.

occupied slices and I need more space for more components and the Treck TCP= /IP used is a evaluation versi=F3n. It exist the option of the TEMAC UltraC= ontroller-II but it seem that the PowerPC processor of the Virtex-4 can't b= e used for others issues and I don't know if the uIP TCP/IP stack used in t= his design supports Jumbo frames like Treck stack. This jumbo frames are ne= eded for maximum performance at gigabit ethernet.

Reply to
v_mirgorodsky

Hello Marco & Vladimir

Unfortunately we need TCP/IP in our products, so we need to use the TCP/IP stack and prefereably without any cost. In the relating thing to the speed of transmission on gigabit ethernet, we have reached more than 900 MB/s with the ML403 development board and a cathegory 6 crossover cable with the GSRD reference system, who use the Treck TCP/IP stack with Jumbo frames. Without Jumbo frames the transmission speed falls to 250 MB/s. Our specifications must reach at least 350 MB/s.

Another problem is the size of the design. The GSRD systems occupies the 79% of the Virtex4FX12 (in the ML403 board). The best option is to use the next FPGA, the Virtex4FX20, but the ISE WebPack, don't sinthetize this chip. The cost of the product it's growing up!!

The last option that I'm evaluating is the UltraController II. I have sinthetize the XAPP807 reference design, a Gigabit webserver. The used resources are minimal (two FIFOs, 20 slices and 18 LUTs) but I have several doubts yet. The UltraController II use the PPC405 as the engine to control the temac (Exclusively?). I'm investigating about to expand the design to use the PPC405 for others parrallel issues but the work flow is different like the EDK's flow and there is no access to the PLB or OPB buses.

Maybe the GSRD team can make a smaller gigabit design? I wait that!

Reply to
David Quiñones

P stack and prefereably without any cost. In the relating thing to the spee= d of transmission on gigabit ethernet, we have reached more than 900 MB/s w= ith the ML403 development board and a cathegory 6 crossover cable with the = GSRD reference system, who use the Treck TCP/IP stack with Jumbo frames. Wi= thout Jumbo frames the transmission speed falls to 250 MB/s. Our specificat= ions must reach at least 350 MB/s.

79% of the Virtex4FX12 (in the ML403 board). The best option is to use the = next FPGA, the Virtex4FX20, but the ISE WebPack, don't sinthetize this chip= . The cost of the product it's growing up!!

thetize the XAPP807 reference design, a Gigabit webserver. The used resourc= es are minimal (two FIFOs, 20 slices and 18 LUTs) but I have several doubts= yet. The UltraController II use the PPC405 as the engine to control the te= mac (Exclusively?). I'm investigating about to expand the design to use the= PPC405 for others parrallel issues but the work flow is different like the= EDK's flow and there is no access to the PLB or OPB buses.

I would't touch UltraController II if I were you. UCII has a very poor performance due to tiny FIFO's (about 100Mbit/s according to XAPP807 datasheet), so it won't satisfy your needs.

Cheers, Guru

Reply to
Guru

Hello Guru

The FIFOs can be expanded, isn't it? There's a lot of resources availables to do this. And I need a very high transmisión speed and the results showed in the xapp807 are reception bandwith.

I'm watching a webcast at

formatting link
about to learn to use the ultracontroller-II with the TEMAC. I will inform about the evaluation of the UCII + TEMAC.

Best regards boys

Reply to
David Quiñones

Hi

It's no bad the webcast at

formatting link
There is a presentation with voice and you can save it in pdf format and the transcription of the voice too.

We will follow informing...

Reply to
David Quiñones

Yes it is true, FIFOs can be expanded. The only problem is that the UCII is not XPS conmpatible design. Modifcations should be done manually in ISE with no guarantee that the modified design will work.

Regards, Guru

Reply to
Guru

Yes, these are the great disadvantages of the UC-II design. The work flow is different like the XPS work flow, and the modification of the design must be do with ISE, but that is simply another way of work. You can choose: · XPS work flow: very compatible, with a great quantity of memory, with the PLB and OPB buses but with a great consumption of resources. · UC II designs: You have a lot of resources avalaible and the 32 Kb of memory are cache, the fastest possible, but the work flow it's a low level work flow but there exists options to expand the design.

I have introduced some modifications to the TEMAC UCII design. I will inform about the results

Regards

Reply to
David

Hi boys, good news!!

The GSRD team will be release a new version of the GSRD using the MPMC2 at the end of May.

I'm waiting that impatiently

Best regards

Reply to
David Q.

Hello

I just finished the test with the UC-II gigabit ethernet design for the ML403 board. Unfortunately, the design is very slow for high speed transmission. The main problem is the little quantity of memory for the code of the TCP/IP stack, so you need to optimize in space, and the instruction speed is decreased.

But for slow applications this is a great solution, because it's simply and easy to learn.

The next step? Hardware processing...

Regards

Reply to
David Q.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.