> >X-Complaints-To: groups-abuse@google.com
> >NNTP-Posting-Date: Mon, 29 Nov 2004 19:19:02 +0000 (UTC)
> >Xref: newsmst01a.news.prodigy.com comp.arch.fpga:78930
>
>
> nslookup 66.35.226.228
> Name: ip66-35-226-228.altera.com
> Address: 66.35.226.228
>
> >Paul Smith <ptsmith@nospam.indiana.edu> wrote in message
news:<cnl7em$9q3$1@hood.uits.indiana.edu>...
> >> I'm considering the V2pro series for several projects.
LOL
I posted once earlier about Altera (as company) being at Electronica 2004 in
Munich - in true belive that it was so, as when I was at that booth
(Altera!) I asked "you are from Altera?" YES
"From Altera directly, not representing them?" YES
ang guess what? after the fair I looked at the business card that guy gave
me: "Altera, represented by somecompany" !!?
now someone posting under bogus name from Altera corp machine to the
newsgroup, gosh what a world!
Antti
Reply by Austin Lesea●November 30, 20042004-11-30
!!!!!!!?????
Yet another clandestine altera.com posting?
Who can we trust?
In all fairness, what the poster did is against Altera company policy,
and he (or she) if caught, will be in 'big trouble' (this from a private
communication to me from an Altera VP).
I would prefer real customer questions and concerns in this forum, as I
know would all of you.
Austin
----snip----
>Paul Smith <ptsmith@nospam.indiana.edu> wrote in message news:<cnl7em$9q3$1@hood.uits.indiana.edu>...
>> I'm considering the V2pro series for several projects.
V2PRO High Speed serial is called RocketIO. I have a tee shirt to prove it.
Maximum baud is 3.125 GBaud. This is what the original poster is asking about.
V2PRO-X High Speed serial is called RocketIO.
Maximum baud is 10.3125 GBaud.
Virtex 4 High Speed serial is called RocketIO.
Maximum baud is 11.1 GBaud.
On 29 Nov 2004 11:19:02 -0800, zhiman@hotmail.com (Zhi) wrote:
>Hi,
>
>Although I don't dispute some of the success stories of RocketIO, I
>would like to point out of the following:
>
>1. The reference clock requirement for RocketIO is very tight
>(=expensive). Xilinx has been recommending an oscillator from EPSON
>with very low jitter.
>
>2. If your application is less than or equal to 6.5Gb/s, do not use
>RocketIO. You will be paying a premium for a 10Gb/s transceiver.
>Altera and Lattice have better alternatives.
Which is wrong. The OP asked about V2PRO, max rate is 3.125 GBaud.
When comparing features, make sure you evaluate what IP is included
in one vendor's SerDes, which other vendors require you to use
logic resources to achieve.
>3. Lastly, just to make it clear:
>V2Pro uses an "old" transceiver, which has poor performance with
>jitter tolerance and transfer, although it has very good jitter
>generation
>V2ProX uses RocketIO
Not according to Xilinx.
>10Gb/s technology for backplanes is here, but there are a lot of
>challenges. One must utilize new backplane (PCB) material, new
>connectors, new test/measurement equipment, and be extermely careful
>with the board design since every little discontinuity will contribute
>to eye closure. Obviously reference backplanes/boards for 10Gb/s exist
>today, but the question is whether they are feasible and
>cost-effective for production.
None of which is relevant, given the OP's question.
>Just my two cents,
>Zhi
I wouldn't give you one cent.
Philip Freidin,
Particpant in the definition, design, and verification of 3 generations
of RocketIO (and all round good guy consultant).
Philip Freidin
Fliptronics
Reply by Zhi●November 29, 20042004-11-29
Hi,
Although I don't dispute some of the success stories of RocketIO, I
would like to point out of the following:
1. The reference clock requirement for RocketIO is very tight
(=expensive). Xilinx has been recommending an oscillator from EPSON
with very low jitter.
2. If your application is less than or equal to 6.5Gb/s, do not use
RocketIO. You will be paying a premium for a 10Gb/s transceiver.
Altera and Lattice have better alternatives.
3. Lastly, just to make it clear:
V2Pro uses an "old" transceiver, which has poor performance with
jitter tolerance and transfer, although it has very good jitter
generation
V2ProX uses RocketIO
10Gb/s technology for backplanes is here, but there are a lot of
challenges. One must utilize new backplane (PCB) material, new
connectors, new test/measurement equipment, and be extermely careful
with the board design since every little discontinuity will contribute
to eye closure. Obviously reference backplanes/boards for 10Gb/s exist
today, but the question is whether they are feasible and
cost-effective for production.
Just my two cents,
Zhi
Paul Smith <ptsmith@nospam.indiana.edu> wrote in message news:<cnl7em$9q3$1@hood.uits.indiana.edu>...
> I'm considering the V2pro series for several projects.
>
> I've heard from someone with experience that there are problems with the
> RocketIO when a lot of other things are happening on the chip. This is
> thought to be a problem with the V2pro package. The evaluation boards
> only implement the RocketIO without a lot of other things going on in
> the part.
>
> Can anyone provide an example of a successful RocketIO implementation on
> a real board that also has a lot of parallel IO and heavy use of
> internal block RAM, etc?
>
> Paul Smith
> Indian University Physics
Reply by Adarsh Kumar Jain●November 22, 20042004-11-22
Hi Paul,
I am at CERN, Geneva. We recently successfully tested a VME 9U Board which
has 9 V2Pros and 3 Alteras.
We are using all 8 Rocket IOs present on the V2P7s in each of them except
for the last one in which we only use 6 of them (big deal ;) )
We are running the Xilinxs at about 80-85% of resource utilization(logic)
and use about 60-70% of Block RAMs. This will go further up as we proceed
with the production of the Board and we are confident that our board will
eventually do what it is supposed to !
Of course there were problems, some on the Xilinxs, some on the board. But
most of the problems (or rather our problems) we traced to the Refernce
Clock (mostly jitter). I was myself new to the Rocket IOs when i started
this project and so
there was a lot of trial and error. But eventually we did make the board
work.
We have an article in the current Xcell issue:
http://www.xilinx.com/publications/xcellonline/xcell_51/xc_particle51.htm
If there are specific questions, then maybe we can try to answer them
Good luck,
Adarsh
"Paul Smith" <ptsmith@nospam.indiana.edu> wrote in message
news:cnl7em$9q3$1@hood.uits.indiana.edu...
>
> I'm considering the V2pro series for several projects.
>
> I've heard from someone with experience that there are problems with the
> RocketIO when a lot of other things are happening on the chip. This is
> thought to be a problem with the V2pro package. The evaluation boards
> only implement the RocketIO without a lot of other things going on in
> the part.
>
> Can anyone provide an example of a successful RocketIO implementation on
> a real board that also has a lot of parallel IO and heavy use of
> internal block RAM, etc?
>
> Paul Smith
> Indian University Physics
>
Reply by glen herrmannsfeldt●November 19, 20042004-11-19
Symon wrote:
> That's right. The inductance depends on the area of the loop the current
> takes. The plane inductance on it's own isn't important, it's the loop area
> of the trace and the plane that matters.
OK, yes, I agree. A ground plane closer to the signal lines will
reduce the inductance.
> What another plane can do is lower the loop area. If a trace always close to
> one or other tightly coupled planes, the loop area is small. If you only
> have one ground plane, it can be harder to keep the trace close to it on a
> multi-layer board.
> Also, forget about making bypass capacitors out of power and ground planes
> at the frequencies of interest for FPGAs. The tiny amount you can make is
> pissed away by the inductance of the vias, PCBs traces and FBGA traces.
Well, put more vias in parallel, which will reduce the inductance
somewhat. The inductance should depend on the length, but it is
still likely higher than one would like it to be.
-- glen
Reply by B. Joshua Rosen●November 19, 20042004-11-19
On Fri, 19 Nov 2004 11:37:39 -0500, Paul Smith wrote:
>
> I'm considering the V2pro series for several projects.
>
> I've heard from someone with experience that there are problems with the
> RocketIO when a lot of other things are happening on the chip. This is
> thought to be a problem with the V2pro package. The evaluation boards
> only implement the RocketIO without a lot of other things going on in
> the part.
>
> Can anyone provide an example of a successful RocketIO implementation on
> a real board that also has a lot of parallel IO and heavy use of
> internal block RAM, etc?
>
> Paul Smith
> Indian University Physics
Glen,
That's right. The inductance depends on the area of the loop the current
takes. The plane inductance on it's own isn't important, it's the loop area
of the trace and the plane that matters.
What another plane can do is lower the loop area. If a trace always close to
one or other tightly coupled planes, the loop area is small. If you only
have one ground plane, it can be harder to keep the trace close to it on a
multi-layer board.
Also, forget about making bypass capacitors out of power and ground planes
at the frequencies of interest for FPGAs. The tiny amount you can make is
pissed away by the inductance of the vias, PCBs traces and FBGA traces.
Best, Syms.
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:cnm07f$nv3$1@gnus01.u.washington.edu...
>
>
> Austin Lesea wrote:
>
>
> > It does help. Two inductors in parallel is half the inductance.
>
> > Place them with the power planes next to them, and you also get added
> > bypass capacitance (power/ground sandwiches).
>
> That was what I thought, to, until someone reminded me that increasing
> the wire size for coil inductors doesn't decrease inductance
> proportionally. It is the mutual inductance, the interaction of the
> magnetic field between the two, that changes it.
>
> If you have alternating ground and power, and the currents are equal
> (and opposite) then it might be true. (That is, more transmission line
> like, and less wire like.) For I/O pin current, going out traces
> that can't cancel the magnetic field of the ground plane current,
> I think it isn't true. The additional capacitance does help, though.
>
> -- glen
>
Reply by glen herrmannsfeldt●November 19, 20042004-11-19
Austin Lesea wrote:
> It does help. Two inductors in parallel is half the inductance.
> Place them with the power planes next to them, and you also get added
> bypass capacitance (power/ground sandwiches).
That was what I thought, to, until someone reminded me that increasing
the wire size for coil inductors doesn't decrease inductance
proportionally. It is the mutual inductance, the interaction of the
magnetic field between the two, that changes it.
If you have alternating ground and power, and the currents are equal
(and opposite) then it might be true. (That is, more transmission line
like, and less wire like.) For I/O pin current, going out traces
that can't cancel the magnetic field of the ground plane current,
I think it isn't true. The additional capacitance does help, though.
-- glen
Reply by Austin Lesea●November 19, 20042004-11-19
Glen,
It does help. Two inductors in parallel is half the inductance.
Place them with the power planes next to them, and you also get added
bypass capacitance (power/ground sandwiches).
Austin
glen herrmannsfeldt wrote:
>
>
> Austin Lesea wrote:
>
> (snip)
>
>> Here, "a lot" is defined as more than 100 mV peak to peak. I mean,
>> when the core voltage is 1.5 volts, or even 1.2 volts, 100 mV of
>> ground bounce is now a significant factor, and not just for the MGTs!
>> Any bounce not addressed increases the system jitter, and hence
>> requires more timing slack for a design to operate reliably. Perhaps
>> you need to double up on ground planes for lowering the return
>> inductance?
>
>
> Some time ago I had suggested using thicker copper to reduce
> inductance, before realizing that it really doesn't help.
> (The inductance of a rectangular bar is proportional to the
> sum of the height and width.) I believe that parallel ground
> planes will have the same effect. The reduction in resistance
> might help, though.
>
> -- glen
>