Issues with Xilinx xapp635: Interface for TigerSharc Link Ports.

Hello,

Started to look at the xapp635 to implement link port interface in Virtex II device. I ran a simulation (VHDL version) with the test bench that came with the app note and it did not pass the test. There is a bug in the receiver implementation. It fails at the very first reception.

I have identified the bug to be we_en signal going to the block ram.

Did anyone have any other issues with this core? The app note claims to have achieved 500 Mb/s per line, which translates to 250 MHz clock. Now I have my suspicions on these numbers :-). Does anyone have any numbers that they achieved?

The test board Xilinx used seems to be Danube DSP board from Bittware. The Bittware website claims a max throughput on these links to be 1GB/s which translates to 125 MHz clock rate.

Maybe someone had better luck with Verilog version of the core. Cursory look into verilog source files tells me it also has the same bug.

Fixing the bug is going to be a pain as there are no comments what so ever in the code. Looks like they intentionally stripped all the comments before releasing the code. Wondering if its better to write my own receiver based on the same technique rather than trying to fix this one.

Wondering if I can open a webcase or 'bug' Xilinx about this one as its only a xapp, is free and comes with no warranty what so ever.

Brijesh

Reply to
Brijesh
Loading thread data ...

the

I ran into the same thing although I'm only looking at a 1-bit implementation. The _complete_ lack of comments in the VHDL is crazy. Given the fact that it is meant as a design starting point I would have imagined it to be about 90% comments to explain why things were done and other options that are possible. The description in the PDF, while it helps, is no replacement for inline comments.

I just started working on my implementation so I can't really give any more guidance at this point. I found XAPP265 to be more useful than the two TigerSharc related app notes. The only exception is that the receiver clock is not continuous so you can't take it into a DCM.

James.

Reply to
James Morrison

the

I have not used Xapp635, but I have use the Verilog link port design that is in Xapp634, and it works for me. I am using it to comunicate between Virtex-II FPGAs, and not with a TigerSHARC. Maybe it is worth a look.

Regards,

John McCaskill

Reply to
John McCaskill

You might also want to look at xapp609 about local clocking resources.

Iam planning to write my own core now, instead of trying to fix there core. Would love to hear what speeds you are able to achieve. We would have to hit 150 MHz clock rate so as to fully use the DSP's processing potential.

I dont have any idea if 150 MHz is pushing the limits of local clocking resources or not?

Brijesh

James Morris>

the

Reply to
Brijesh

I did take look at them. Looks like the new TigerSharc interface is reduced functionality version of the old interface. They seem to have removed the crc verification function and hand placed and routed the whole thing to get better clock rates. Thats the first impression I got.

By the what kind of clock rates were you able to get out of it? Did you get the published max throughputs?

thanks Brijesh

Reply to
Brijesh

We currently have the system clock input constrained to 100 MHz. The lxclkin and lxclkout clocks would be 50 MHz, or upto 100MB/sec. This is more than fast enough for what we are using it for, so I have not tried to see how fast it will go. We are using V2 -5C speed grade. We have had it running faster in the past, but I would have to go digging through our CVS repository to see how fast. If memory serves, I think we had it running with a main clock of 125 MHz.

Regards,

John McCaskill

Reply to
John McCaskill

I use Verilog version of xapp 635 and find the same problem with you. I made a small change and it can work well in simulation.

You can try this change. In the first "process" of file rx_4_128_right.vhd, change the "we

Reply to
rightnow

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.