Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST

Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | RocketIO, where to start?

There are 12 messages in this thread.

You are currently looking at messages 0 to 10.

RocketIO, where to start? - MM - 2005-02-28 16:26:00

Hi all,

I am thinking of using RocketIO for serializing a very simple parallel data
flow from one Xilinx FPGA to another. The data flow is a stream of 16-bit
word pairs running at approximately 70 MHz, i.e. the total data rate is 2.24
Gb/s. At the receiving end I need to resynchronize the data to the original
70 MHz clock (The clock can be made available to both FPGAs).

I was wondering if someone could point me in the right direction (should I
be using Aurora?) as I am feeling a little overwhelmed with the amount of
the information on RocketIO, most of which seems not too relevant to my
simple case...


Thanks,
/Mikhail





Re: RocketIO, where to start? - nigelg - 2005-02-28 17:50:00

Hi Mikhael,
	
	If you have Xilinx CORE Generator installed, you can generate an Aurora 
module for your application. A single lane full-duplex Aurora module 
with a 4-byte streaming parallel interface will fit.

	CORE Generator will give you the source code for the module, which you 
can integrate with your design. You'll need to provide a 140 Mhz 
reference clock to run the RocketIO; the module will provide a 70 Mhz 
clock derived from the reference clock for the parallel interface. The 
TX interface is a data port plus a ready signal and a data valid signal. 
The RX interface is a data port plus a data valid signal.

	RocketIO uses Clock Data Recovery (CDR) which means the data you 
receive will be synchonized to a 70 Mhz clock recovered from the serial 
input. Unless you need the clocks on both devices to be exactly in 
phase, you wont need to provide the same clock to both FPGAs.

	If this sounds like it might work for you, you should take a look at 
the Aurora Reference Design User Guide in the downloads section of the 
Xilinx Aurora lounge (www.xilinx.com/aurora -> Click the Access Lounge 
button for the Aurora Reference Design at the bottom of the page: the 
user guide is the second link.)

Regards,
Nigel

MM wrote:
> Hi all,
> 
> I am thinking of using RocketIO for serializing a very simple parallel data
> flow from one Xilinx FPGA to another. The data flow is a stream of 16-bit
> word pairs running at approximately 70 MHz, i.e. the total data rate is 2.24
> Gb/s. At the receiving end I need to resynchronize the data to the original
> 70 MHz clock (The clock can be made available to both FPGAs).
> 
> I was wondering if someone could point me in the right direction (should I
> be using Aurora?) as I am feeling a little overwhelmed with the amount of
> the information on RocketIO, most of which seems not too relevant to my
> simple case...
> 
> 
> Thanks,
> /Mikhail
> 
> 

Re: RocketIO, where to start? - Duane Clark - 2005-02-28 18:45:00

MM wrote:
> Hi all,
> 
> I am thinking of using RocketIO for serializing a very simple parallel data
> flow from one Xilinx FPGA to another. The data flow is a stream of 16-bit
> word pairs running at approximately 70 MHz, i.e. the total data rate is 2.24
> Gb/s. At the receiving end I need to resynchronize the data to the original
> 70 MHz clock (The clock can be made available to both FPGAs).
> 
> I was wondering if someone could point me in the right direction (should I
> be using Aurora?) as I am feeling a little overwhelmed with the amount of
> the information on RocketIO, most of which seems not too relevant to my
> simple case...

The Aurora module is a pretty good match for that, I would think. Yes it 
looks like a lot of info, mut mainly you will be concerned with TX_DIN 
and TX_WR (and perhaps TX_DST_RDY) on the write side, and RX_SRC_RDY and 
RX_DOUT on the receive side. They are simple handshaking signals which 
do exactly what the names imply, so the core is really easy to use. Read 
the section on clocking several times, though ;)

Unfortunately, getting the simulation up and running is a bit of a pain. 
Only Swift simulation models are provided for the RocketIO, and I think 
I spent most of a day researching these and getting them going in 
Modelsim, but they work fine after that. It was well worth the trouble; 
the simulation is pretty good fidelity.

-- 
My real email is akamail.com@dclark (or something like that).
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: RocketIO, where to start? - MM - 2005-03-01 10:36:00

Hi Nigel,

Thanks for your help. When is the Aurora module going to be available for
the V4 FX series? I know that even V4 MGBT user manual has not been released
yet...


/Mikhail



Re: RocketIO, where to start? - MM - 2005-03-01 10:37:00

Thanks Duane.

/Mikhail



Re: RocketIO, where to start? - nigelg - 2005-03-01 16:41:00

The first Aurora code for Virtex 4 will be
available in the first 
IPUpdate for ISE 7.1. You might also try talking to a Xilinx FAE in your 
area, since they can sometimes set you up with early access material.

Regards,
Nigel

MM wrote:
> Hi Nigel,
> 
> Thanks for your help. When is the Aurora module going to be available for
> the V4 FX series? I know that even V4 MGBT user manual has not been released
> yet...
> 
> 
> /Mikhail
> 
> 
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: RocketIO, where to start? - MM - 2005-03-01 17:48:00

On a different topic, what kind of error rate can
I expect at 2.24 GB/s? Two
FPGAs I am connecting with this link are on 2 separate PCBs (so called front
and rear Compact PCI cards). The cards are connected with a 2mm Hard Metric
"pass-through" connector. In other words there is a backplane or rather
midplane between the cards, but there are no tracks, the signals pass
directly through the vertical male connector pins sticking out on both sides
of the plane, while each of the cards has a right angle female connector.

My problem is that I can't really have any errors at all... If that is not
achieavable with RocketIO at the data rate I am interested in, then I guess
I should look at other options. I noticed that there is a slower core in the
Coregen, called High-Speed Data Serialization and Deserialization. I guess I
could use 4 of them, one per each of the bytes in my packet and run them at
560 MHz. Would this be more reliable?



Thanks,
/Mikhail



Re: RocketIO, where to start? - Marc Randolph - 2005-03-02 00:22:00

MM wrote:
> On a different topic, what kind of error rate can I expect at 2.24
GB/s? Two
> FPGAs I am connecting with this link are on 2 separate PCBs (so
called front
> and rear Compact PCI cards). The cards are connected with a 2mm Hard
Metric
> "pass-through" connector. In other words there is a backplane or
rather
> midplane between the cards, but there are no tracks, the signals pass
> directly through the vertical male connector pins sticking out on
both sides
> of the plane, while each of the cards has a right angle female
connector.
>
> My problem is that I can't really have any errors at all... If that
is not
> achieavable with RocketIO at the data rate I am interested in, then I
guess
> I should look at other options. I noticed that there is a slower core
in the
> Coregen, called High-Speed Data Serialization and Deserialization. I
guess I
> could use 4 of them, one per each of the bytes in my packet and run
them at
> 560 MHz. Would this be more reliable?

Howdy Mikhail,

Unless you have something weird going on in your system, you should be
able to achieve "error-free" links (better than 1E-12, let's say).
Weird being something like noise on your MGT power or ground, or
reference clock quality problems.  With RocketIO, you trade fewer pins
for a little more design complexity (due to the higher speeds).
Thousands of people doing it (error free) though, so it works.

Have fun,

   Marc


Re: RocketIO, where to start? - MM - 2005-03-02 10:08:00

Thanks.

/Mikhail


______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: RocketIO, where to start? - Austin Lesea - 2005-03-02 10:34:00

MM,

A well designed link has 0 errors.

Yes, no errors.

No reason why you can not model this, and prove in simulation (hspice, 
nspice) that the link has more than enough margin to be error free.

I caused quite a stir when everyone wanted to publish an error rate of 
1E-12 (basically one of the common specifications for XAUI, etc.)  I 
said that since we have no errors in a properly designed link, the BER 
should be identically 0.

That is what we published.

My opinion:  if there are errors, the link was not designed properly, 
and it is broken (or the transceivers are junk).

The midplane through connectors need to be modeled and verified they do 
not mess up the balance, impedance, etc. but otherwise this arrangement 
should work error free at any rate supported by our devices (up to 10 
Gbs).  With no long paths, you have the best situation:  no loss to 
speak of.

Austin

MM wrote:
> On a different topic, what kind of error rate can I expect at 2.24 GB/s? Two
> FPGAs I am connecting with this link are on 2 separate PCBs (so called front
> and rear Compact PCI cards). The cards are connected with a 2mm Hard Metric
> "pass-through" connector. In other words there is a backplane or rather
> midplane between the cards, but there are no tracks, the signals pass
> directly through the vertical male connector pins sticking out on both sides
> of the plane, while each of the cards has a right angle female connector.
> 
> My problem is that I can't really have any errors at all... If that is not
> achieavable with RocketIO at the data rate I am interested in, then I guess
> I should look at other options. I noticed that there is a slower core in the
> Coregen, called High-Speed Data Serialization and Deserialization. I guess I
> could use 4 of them, one per each of the bytes in my packet and run them at
> 560 MHz. Would this be more reliable?
> 
> 
> 
> Thanks,
> /Mikhail
> 
> 
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

| 1 | 2 | next