Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
actually, more readers need to learn more about trolls, and just notBrowsing through the "about" links I found this brief note
on Usenet posting:
http://groups.google.com/support/bin/static.py?page=basics.html#flamed
For those that missed it, there is a long wonderful thread in theabsoulutly true ... but not the whole thread, or even vary many of the
authors in the thread ... the brash branding of the entire thread, even
I will do everything I can to keep this newsgroup focused on FPGAs. ItYeah, I should have changed the subject in my first reply.
But you can measure the core supply current. Should be easy enough to do someAnd yes, I've since cooked a couple XCV800's, so I have the sense now
to check FPGA's when testing a new application or demo. When RC cards
do not even have the temp diode monitor IC connected to the FPGA, it's
difficult for an RC programmer even to be able and check the chip temp
when it's stuffed in a box, and automatically shut the app down or
throttle back the clocks.
I started watching sci.electronics.design since analog and RF stuff tends toI issued my warning when I saw that mountain of crud descending on us:
off-topic, xenophobic, rambling like a drunken sailor, and often
downright stupid. The fact that our beloved and respected Ray Andraka
inserted some pearls of wisdom does not change the general view. The
thread started with a provocative question, and then degraded into
rambling chaos.
I have watched other newsgroups fall into a similar trap, and I suggest
we band together to avoid this here. The subject is FPGAs, and we
should not get dragged into semi-intelligent (often un-informed and
even stupid) discussions about completely different subjects. There are
thousands of other newsgroups that do ventilate all sorts of ideas.
We have avoided spam, we should also be able to avoid an invasion like
the one I objected to.
Peter Alfke
I haven't tried hard yet, and easily got "close" with several large
pipelined demos. I am concerned about what someone really concerned
about performance may fairly easily do. And in particular what does
that translate into regarding design envelopes for those that make PCI
add in FPGA
accelerator boards, and what should the customer clearly be aware of
and have disclosed for selection guidelines in Reconfigurable Computing
(RC) platforms.
snip
toys,
A comment about modeling the FPGA and package:
Look up Howard Johnson's presentations. Ball/pad inductance is useless
(last year's solution). I am surprised you bring it up. HJ proves that
it is the loops and their topology that matter. And without a 3D field
solver, you have no hope of learning anything at all.
Except if you use our FPGAs: we do the hard stuff so you don't have to
(e.g ParseChevron (tm), patents pending).
The number of planes, and bumps/balls for Vcc's and ground ensure that
the voltage drops are kept within the required limits, even for your 40
watt design. It is up to you to design the PDS for your board, and we
have applications notes to help you in that regard.
Comments we have received include folks who now tell us that the
SparseChevron packages(tm) are superior to IBM's "cross" design.
I'm happy to just be in the same league.
http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/advantages/sipi.htm
http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf
Austin
So, my point is, and nobody seems to disagree, that it's unrealistic toSo my point is, the FPGA vendors give you the information they can about
power dissipation. They can't know your design to provide you better
numbers without you actually simulating the post PAR design with vectors
that accurately reflect the actual usage. For a general purpose board,
the board designer can limit the FPGA dissipation to whatever is safe
for the board cooling environment by using thermal diodes or power
supply current limits to avoid damage to the FPGA or board, and he can
do that without knowing anything about your design. Isn't that a better
tree to bark up?
I've watched his presentation ... and it explained the horribleLook up Howard Johnson's presentations. Ball/pad inductance is useless
(last year's solution). I am surprised you bring it up. HJ proves that
it is the loops and their topology that matter. And without a 3D field
solver, you have no hope of learning anything at all.
The point of the 40w design, is that it's derated. Doubling, or better,The number of planes, and bumps/balls for Vcc's and ground ensure that
the voltage drops are kept within the required limits, even for your 40
watt design. It is up to you to design the PDS for your board, and we
have applications notes to help you in that regard.
Looking in from the sidelines, it seems to me that quite a bit of thisSo, my point is, and nobody seems to disagree, that it's unrealistic to
assume that the devices can be 100% packed, use the marketing numbers
for system design clock speeds, at a modest toggle rate, and not blow
right thru the power the device can handle. Disagree?
If not, then the device HAS TO BE DERATED from marketing numbers for RC
use. Disagree?
I don't understand you Frank! Multiple times others haveDear all,
I am using Virtex 4 from Xillinx, and I really missed the clock for LVDS.
So, should I transfer data to LVDS each time posedge of the clock.
The clock should be LVDS clock, LTTL clock or any clock is possible.
Many thanks
Frank
It probably needs some care, to ensure CLK_min times are ok ?The circuit is reliable, although the generated pulse width is
determined by gate delays. But it is self-compensating, since the clock
pulse will not end until the flip-flop has toggled.
a circuit ( from HP?) for Biphase decode.It's kind of clever, if I am allowed to say so...
Yes, I recall a similar [XOR-Q] clock scheme many, many years ago, on
Thanks for making my point. The Xilinx product chips + ISE is unable tofpga_toys@yahoo.com wrote:
So, my point is, and nobody seems to disagree, that it's unrealistic to
assume that the devices can be 100% packed, use the marketing numbers
for system design clock speeds, at a modest toggle rate, and not blow
right thru the power the device can handle. Disagree?
You won't get the density and performance without handcrafting to meet
both the density and performance limits. The typical user is going to
run into place and route issues before he even gets close to the high
density, high clock rate corner. I don't care if it is an RC
application or not, you just don't get into that corner unless you do a
considerable amount of handcrafting on the design.
Worse yet, RC will tend to use the largest chips available, or theThe reason they get away with it today is that for hardware design
there is
a VERY strong incentive to buy up ... purchase a larger device, just to
make
sure that in the future changes will fit. So many designs will always
have the
headroom, and presure on Xilinx to improve P&R for high density routing
is
relatively low, as few designs will cross above 95% use.
With RC there is a completely different goal, and that is to use the
entire chip,
in fact, all of every chip in an FPGA processor array. High density
designs are
the norm with RC, and half device designs will be relatively rare.