Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 107275

Article: 107275
Subject: Re: fastest FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 25 Aug 2006 17:59:50 -0700
Links: << >>  << T >>  << A >>
Totally_Lost wrote:
> Peter Alfke wrote:
> > It's hard to understand how grown-ups can indulge in this kind of silly
> > argumentation...
> > Peter Alfke
>
> For reference, a couple years back I had a couple XC2000E-8 parts in
> Xilinx BG560 proto boards running a hand packed bit serial RC5 cracking
> design at max clock rate ... petlier cooled, but could never get it
> power stable, even after augmenting the power bypass caps and buss wire
> to the socket. At first I blamed the sockets. Then put four of them on
> PCBs and tried again .... never could get it stable anywhere close to
> rated clock rate.

...snip...

> If you, Austin, and Xilinx say XCV2000E/XCV2600E parts fully hand
> packed with with bit serial compute engines should easily be stable
> with solid cooling, I for one, will remain skeptical.
>
> If you want to say the XC4VLX200's packed the same way can be made
> stable, or similar large XC5VLX parts, then I'll be happy to go back to
> the client with that guarentee if Xilinx will stand behind it 110%.

Is it possible that your problem is something other than heat?  Power
decoupling is more of a science than an art or guessing game.  It is
entirely possible that your decoupling was not adequate in spite of the
augmentation.  To fully decouple power for fast chips the power planes
must be built with a lot of internal capacitance along with a range of
different capacitor values to allow parallel resonances to be bypassed
and a low impedance to be obtained over a wide frequency range.


Article: 107276
Subject: Re: fastest FPGA
From: "Symon" <symon_brewer@hotmail.com>
Date: 26 Aug 2006 03:11:30 +0200
Links: << >>  << T >>  << A >>
"rickman" <gnuarm@gmail.com> wrote in message
news:1156553990.451411.179250@m79g2000cwm.googlegroups.com...
>   To fully decouple power for fast chips the power planes
> must be built with a lot of internal capacitance along with a range of
> different capacitor values to allow parallel resonances to be bypassed
> and a low impedance to be obtained over a wide frequency range.
>
Rick,
You may find this enlightening!
http://www.sigcon.com/Pubs/news/1_17.htm
A range of values (in the same package size) is no help, it just bloats your
BOM.
Cheers, Syms.



Article: 107277
Subject: Re: fastest FPGA
From: fpga_toys@yahoo.com
Date: 25 Aug 2006 18:27:52 -0700
Links: << >>  << T >>  << A >>

rickman wrote:
> Is it possible that your problem is something other than heat?

Not heat, the XC2000E rolled over right after loading, room temp die.

> Power
> decoupling is more of a science than an art or guessing game.  It is
> entirely possible that your decoupling was not adequate in spite of the
> augmentation.  To fully decouple power for fast chips the power planes
> must be built with a lot of internal capacitance along with a range of
> different capacitor values to allow parallel resonances to be bypassed
> and a low impedance to be obtained over a wide frequency range.

You know, it's always possible.

I stacked 0805/0603 caps right across the back side of the BG560
power/ground pads ... 0.01uf, 0.1uf, and 1.0uf on top of each other in
a second test, and it just delayed the failure for a few seconds. It
took abandoning the LUT SRL's to get any stability, plus backing the
clock off.

I personally don't think there is any way to fully load a large BG560
XCV2000E device with a dense bit/digit serial computational engine. I
did notice that both Austin and Peter were not that quick to defend
that is should be possible.

The only bright spot, is that Austin sayslarge  XC4V and XC5V can
handle a fully loaded 1010101 design, which I would love to verify ...
but I'm certainly not going to spend $10K to test it from my own funds.

My personal belief is that the ground ring/net is probably shared with
I/O pads, and is probably stable. I also suspect that it's the VCCINT
pads that are dropping, which would make the worst case not 1010101 ...
but a large number of 0->1 transistions in the fabric. Bit serial
doesn't do that easily, or likely, but it does happen too when a MAC is
cleared, the first add value for the next term is all ones. It does
complicate the problem, when you also have heavy concurrent pin I/O in
progress ... which I didn't. At least Xilinx is quick to rate the max
number of up/down transitions for that problem.

This mantra about 25% transitions is total BS for dense bit serial
designs, SRL's or not.


Article: 107278
Subject: Re: Newbie frustration
From: Daniel O'Connor <darius@dons.net.au>
Date: Sat, 26 Aug 2006 11:01:18 +0930
Links: << >>  << T >>  << A >>
John McGrath wrote:

> You are right - they are totally contained within that always block -
> so you most likely are getting away with it - but if you had used
> noo-blocking <= statements, I wonder if the result may have been
> different ;) (at least for behavioural sim). There are some imteresting

True enough, but I've been trying to commit the "Verilog coding styles that
kill" paper to memory so I didn't use non blocking statements :)

> subtlties in verilog. I often use the verilog 2001 construct
> 
> always@(*)
> ....
> 
> to ensure that the sensitivity list is always complete - should avoid
> that problem.

Sort of - I think really it would just hide the bugs in Xst. (but the price
is right so I'm not complaining very much :)

> As for the issue, it seems that the above is indeed not the issue from
> your discription, and that it is most likely timing related.

More's the pity really 8-)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Article: 107279
Subject: Re: Quartus and source control (continued)
From: Daniel O'Connor <darius@dons.net.au>
Date: Sat, 26 Aug 2006 11:07:22 +0930
Links: << >>  << T >>  << A >>
Petter Gustad wrote:
> I only store ONE file for Quartus, a tcl script to compile the design.
> It includes all the pin assignments, global assignments to generate
> SVF files etc.
> 
> A typical build from a fresh checkout will look like:
> 
> cvs co designname
> cd designname/impl/ep1c6t144c8
> quartus_sh -t compile.tcl

If only Xilinx made life that simple :(

I'm not what you'd call a fan of the .ise file.. Project Navigator regularly
corrupts it (usually after it's destroyed the backup copy), and the tools
that interface to it are.. weak. pjcli can't even recreate a full project
because it doesn't understand how to add a constraint file to it!

And let's not get into the tool's obsession with absolute pathnames which
make having 'beta' versions of your design very frustrating :(

(but on the plus side I have a makefile which replicates the build
functionality I need.. still working on generating simulation)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Article: 107280
Subject: Re: Open source Xilinx JTAG Programmer released on sourceforge.net
From: Daniel O'Connor <darius@dons.net.au>
Date: Sat, 26 Aug 2006 11:17:16 +0930
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com wrote:

> The Digilent USB driver was the biggest task in this project. The
> xc3sprog jtag interface doesn't really match the Digilent protocoll. So
> I had to create a little bit different JTAG engine than xc3sprog to
> support parport and USB, and to utilize the speed of Digilent USB
> device, and to have a reduced speed version.
> 
> The other problem what I had was, to create a infrastructure to support
> multiple devices, where the algorithms may be similar, and to do that I
> should have rewritten the whole xc3sprog anyway.

Ahh fair enough.
Pity.. it is frustrating to find several programs that have slightly
different baseline functionality rather than having pooled resources to
create one more complete program.

Guess I'll download xilprog and send you some FreeBSD patches :)

Any chance you can find out why anon CVS doesn't work? Having it checked out
makes it much easier to generate diffs.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Article: 107281
Subject: Re: fastest FPGA
From: fpga_toys@yahoo.com
Date: 25 Aug 2006 19:03:07 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> I almost threw up when I read John Bass explain how he uses a
> deliberately dumb-sounding name plus naive questions to light some fire
> and create controversial flames.

And just to correct the point .... I didn't ask any naive questions
that Austin jumped on, both I made, and defended a statement which both
You and Austin are pissy unhappy about.

Totally_Lost wrote:
> John_H wrote:
> > You may run into power issues before you can consider overclocking.  You
> > could design so much high speed logic in a huge part that you can only run
> > x% of the part at Fmax or all of the part at x% of Fmax.
>
> Right on John ... :)
>
> As I've noted before, you seriously need to "derate" large Xiinx FPGAs
> for designs that have very high percentage of active logic. Since they
> assume around 15-20% of the design will be active, it's very easy to be
> unable to get power into the devices within the spec'ed voltage
> margins, or to keep it cool if you do. Doing single point thermal
> monitoring on the die, may not be enough to readily identify that other
> portions of the die are well above that limit temp once you are
> agressively cooling the part.
>
> Packing the device from edge to edge with active logic will cause
> problems. At both high speeds and high density, many of the larger
> parts are simply not usable.

To which Austin insultingly asserts:

Austin Lesea wrote:
> Ray,
>
> I agree.  Good post.
>
> Totally_Lost is, unfortunately, lost... totally.
>
> Austin

and both of you end up eating crow for. That's your problem, take
responsibility for it.


Article: 107282
Subject: Re: fastest FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 25 Aug 2006 21:10:39 -0700
Links: << >>  << T >>  << A >>
Symon wrote:
> "rickman" <gnuarm@gmail.com> wrote in message
> news:1156553990.451411.179250@m79g2000cwm.googlegroups.com...
> >   To fully decouple power for fast chips the power planes
> > must be built with a lot of internal capacitance along with a range of
> > different capacitor values to allow parallel resonances to be bypassed
> > and a low impedance to be obtained over a wide frequency range.
> >
> Rick,
> You may find this enlightening!
> http://www.sigcon.com/Pubs/news/1_17.htm
> A range of values (in the same package size) is no help, it just bloats your
> BOM.

Yes, I see what you are saying.  But the point is that you and Dr.
Johnson make these statements with absolutely no supporting evidence.
I was in the class, I saw the impedance plots and I even asked the
exact same question about using the same package with the same
parasitics.  The issue is not the inductance, the issue is SRF.  It
took me awhile to understand why this is important.  It was especially
hard for me to grasp when I looked at the data for three different
value caps superimposed to show that the inductive reactance region was
nearly identical.  But the smaller caps had a higher SRF.  So combining
a small number of 0.1 uF, a few more 0.01 uF and more of the 0.001 uF
parts seem to provide the best solution.

The impedance plot of the bare board with well coupled ground and power
planes (no parts) shows the impedance dropping with frequency until it
hits a SRF.  The impedance goes up a bit and then seems to oscillate in
the very high frequency region.  Adding a single value of caps lowers
the impedance at the low end, but actually makes the impedance higher
at 150 MHz from parallel resonance between the cap and the plane.  It
is not clear to me that any reasonable number of additional caps would
reduce this peak to be acceptable.  Adding some caps at a smaller value
added a new minimum in the impedance and raised the frequency of the
parallel resonance.  Adding a third value of caps makes the impedance
plot quite acceptable with peaks less than about 100 mohm up to 3 GHz
and the bulk of the graph under 25 mohm below 300 MHz.  The graph is so
very clear with the capacitor related minimums at about 20, 50 and 200
MHz.

This guy chalenged some of my very deeply held beliefs in how to design
power systems.  I could not find a single thing wrong with anything he
said.  Others in the class would argue with him about their beliefs.
But in the end it was beliefs vs. facts... no contest!

There are two things that Dr. Johnson said that I want to address.  "In
addition, you have introduced the possibility of a resonance occurring,
as you point out, between the lead inductance of the larger capacitor
and the capacitance of the second, smaller-valued component."  I think
this is pretty clearly nonsense and I am surprised he said it.  He
refers to the two values of capacitors not being useful because they
have the same inductance.  Now he is saying that the inductance of one
cap can interact with the capacitance of the other.  Isn't that a
contradiction?  Wouldn't that produce the same result as the second
capacitor's self resonance?

The other thing he said is, "The best method for controlling the
resonances between sections of the power system is to buy cheap, low-Q
bypass components in the first place".  Even though this seems counter
intuitive, the data bears this out.  The low quality (or high ESR)
reduces the amplitude of the parallel resonance peaks and makes the
impedance more even.  Sounds odd, but correct, again the data bears
this out.


Article: 107283
Subject: Re: fastest FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 25 Aug 2006 21:25:24 -0700
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> rickman wrote:
> > Is it possible that your problem is something other than heat?
>
> Not heat, the XC2000E rolled over right after loading, room temp die.
>
> > Power
> > decoupling is more of a science than an art or guessing game.  It is
> > entirely possible that your decoupling was not adequate in spite of the
> > augmentation.  To fully decouple power for fast chips the power planes
> > must be built with a lot of internal capacitance along with a range of
> > different capacitor values to allow parallel resonances to be bypassed
> > and a low impedance to be obtained over a wide frequency range.
>
> You know, it's always possible.

It is good that you are open to possibilities.

> I stacked 0805/0603 caps right across the back side of the BG560
> power/ground pads ... 0.01uf, 0.1uf, and 1.0uf on top of each other in
> a second test, and it just delayed the failure for a few seconds. It
> took abandoning the LUT SRL's to get any stability, plus backing the
> clock off.

Another odd thing about power that I learned was that the placement of
the decoupling caps is not at all critical.  This guy had designed a
test board with caps at less than an inch from the test points and at
about 3, 6 and 9 inches.  The graphs of impedance between the planes
are nearly identical regardless of which capacitor was populated.  So
it is clear that the caps don't need to be right on top of the power
pins.  But to make the smaller caps work well, you do need more of them
than you need of the larger value caps.  Not that I am doubting that
you had enough.  I am just pointing out what the data indicates is
required.


> I personally don't think there is any way to fully load a large BG560
> XCV2000E device with a dense bit/digit serial computational engine. I
> did notice that both Austin and Peter were not that quick to defend
> that is should be possible.
>
> The only bright spot, is that Austin sayslarge  XC4V and XC5V can
> handle a fully loaded 1010101 design, which I would love to verify ...
> but I'm certainly not going to spend $10K to test it from my own funds.

I have no doubt that there are some designs that will not do well in an
FPGA.  These are complex chips and it has got to be hard to design them
for all applications.  It is also possible that there are SI issues
inside the chip.  As you point out, ground and power bounce are very
real problems and there is nothing you can do on the outside to
mitigate them.


Article: 107284
Subject: Re: FPGA -> SATA?
From: fpga_toys@yahoo.com
Date: 25 Aug 2006 23:10:17 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> The ASSP vendors are very protective about their business:  they
> continue to make their little applications as tough to do as possible,
> to keep out the 'big bad FPGA vendors' who seem to be eating up all
> their businesses.  (Hey, we are just trying to make our customers happy!)
>
> Too bad:  when an industry is spending time being defensive, they have
> already lost - any time spent not innovating means you are doomed to
> failure.

Ok ... I took the time to see who the little guys are at SATA-IO that
Austin claims are running completely scared of the  'big bad FPGA
vendors'. Frankly, when I read down the list, it becomes pretty obvious
many of the players could aquire Xilinx with a day or two's free
profits and not even worry about the investment costs if they paid
twice what Xilinx was worth.

The only two things obvious, is that Austin's/Xilinx's head is so full
of shit if they think half these companies even care what Xilinx does
with SATA, and that Xilinx is so full of NIH that they are failing to
meet custmers needs by refusing to play nicely inside the industry wide
SATA club.

Anybody spot those that Austin claims "are running completely scared of
the  'big bad FPGA vendors'."????

ACARD Technology Corporation
Accusys
Adaptec, Inc.
Addonics Technologies
Adtron Corporation
Aeluros, Inc.
Agere Systems
Agilent Technologies, Inc.
Allion Computer Inc.
Alta Engineering
AMCC (3ware)
AMD
Aska Technologies Inc.
ATI
Avery Design Systems
Bell Microproducts
BiTMICRO Networks
BizLink
Broadcom
Buffalo Inc.
Catalyst Enterprises Inc.
CEVA
CI Design
Circuit Assembly Corp.
Comax Technology, Inc.
CRU-DataPort
CRUZ Systems
Dallas Semiconductor, Inc.
DataStor Technology Co., Ltd.
Dell
Denali Software, Inc.
Der An Electric Wire & Cable Co., Ltd
DoTop Technology, Inc.
Ease Software, Inc.
Electronics Testing Center, Taiwan
Emulex Corporation
Epson Research & Development, Inc.
EqualLogic
Exar Corporation
Expert I/O
Faraday Technology Corporation
FCI
Finisar
FirmTek, LLC
Foxconn Electronics
Fujikura/DDK
Fujitsu Computer Products of America
Fujitsu-Siemens Computers
Genesys Logic, Inc.
Golden Bridge Electech Inc.
Hewlett-Packard
Highly Reliable Systems
HighPoint Technologies, Inc.
Hitachi Global Storage Technologies
Hitachi-LG Data Storage Korea, Inc.
Horng Tong (HOMETOM) Enterprise Co., Ltd.
IBM Corporation
IIX Consulting
Infineon Technologies
Infortrend Technology, Inc.
Initio Corporation
Intel Corp.
Intella Sys Corp.
IntelliProp Inc.
Interelectronix
Iomega
JAE Electronics
Jalink Technology Inc.
Jei Wei Electronic Co., Ltd.
JMicron Technology Corp.
Joinsoon Electronics Mfg. Co. Ltd.
J.S.T. Mfg. Co., Ltd.
Kano Technologies
Kawasaki Microelectronics, Inc.
KnowledgeTek, Inc.
Knowlent Corporation
LeCroy Corp.
LaCie
Landwin Electronic Corp.
Link-A-Media Devices
LITE-ON Technology Corp.
Longwell
LSI Logic
LyCOM Technology, Inc.
Marvell Semiconductor, Inc.
Maxtor
MediaTek Inc.
Mentor Graphics
Microsoft
Mitac International  Corporation
Molex, Inc.
M-Systems
NEC Electronics Corporation
Netcell Corp.
Niketech
Northstar Systems Corp.
Nvidia Corporation
Omneon Video Networks
Oxford Semiconductor Ltd.
Quantum Corp.
Panasonic Semiconductor
PDE Technology Corporation
PHILIPS & BenQ Digital Storage Corporation
Philips Semiconductors
Pioneer Corporation
Plextor Corp.
PMTC NV
Prolific Technology, Inc.
Promise Technology, Inc.
ProStor Systems, Inc.
P-TWO Industries Inc.
Rapid Conn
RATOC Systems, Inc.
Realtek
Renesas Technology
RITEUP Co., Ltd.
ROHM Co., Ltd.
Samsung Electronics
Sanko Electronics Co., Ltd.
Seagate Technology
Scientific Atlanta
Sierra Logic, Inc.
SIIG, Inc.
Silicon Image Inc.
Silicon Integrated Systems Corp
SiliconStor, Inc.
SimpleTech
SMK Corporation
Soft Mixed Signal Corporation
Sonnet Technologies, Inc.
Space Shuttle Hi-Tech Co., Ltd.
STMicroelectronics
Sunext Technology
Sun Microsystems, Inc.
Sunplus Technology Co. Ltd.
Synthesys Research, Inc.
Synopsys
Taiwan Electronics Co., Ltd.
Tektronix
Top Yang Technology Enterprise Co., Ltd.
Toshiba
Total Technologies, Ltd.
Trimax Electronics Co., Ltd.
Tyco Electronics
ULi Electronics Inc.
ULINK Technology
University of New Hampshire InterOperablitity Lab
Via Technologies Inc.
Vitesse Semiconductor Corp.
VMC Consulting
VSO Electric Co, Ltd.
Wavecrest
Western Digital Corp.
Wieson Technologies Co., Ltd.
Win Win Precision, Co., Ltd.
Wipro Limited
Y.C. Cable USA, Inc.
Zarlink


Article: 107285
Subject: Re: fastest FPGA
From: John_H <johnhandwork@mail.com>
Date: Sat, 26 Aug 2006 06:33:38 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
<snip>
> This guy chalenged some of my very deeply held beliefs in how to design
> power systems.  I could not find a single thing wrong with anything he
> said.  Others in the class would argue with him about their beliefs.
> But in the end it was beliefs vs. facts... no contest!

I love eye-opening engineering.  It's not often that there's a spark of 
"oh yeaaaaah" like this.

> There are two things that Dr. Johnson said that I want to address.  "In
> addition, you have introduced the possibility of a resonance occurring,
> as you point out, between the lead inductance of the larger capacitor
> and the capacitance of the second, smaller-valued component."  I think
> this is pretty clearly nonsense and I am surprised he said it.  He
> refers to the two values of capacitors not being useful because they
> have the same inductance.  Now he is saying that the inductance of one
> cap can interact with the capacitance of the other.  Isn't that a
> contradiction?  Wouldn't that produce the same result as the second
> capacitor's self resonance?

The SRF of a capacitor gives you the minimum impedance - as close to the 
ideal dead short as you can get.  Above that frequency, the cap goes 
inductive but it's still a darn good impedance for several octaves of 
frequency.  If you have another capacitor with a higher SRF, what you 
end up with isn't the *series* resonance, but an anti-parallel resonance 
(the "anti" looks strange but those were the terms used).  Going back to 
the early book-learning, this anti-parallel resonance ends up as an 
open, not a direct short.  The only thing saving that frequency point 
from being a dead-open is the non-ideal characteristics of those 
parasitics.  SRF in a capacitor is a good thing.  Resonance between a an 
inductor and a capacitor in parallel isn't so good.

> The other thing he said is, "The best method for controlling the
> resonances between sections of the power system is to buy cheap, low-Q
> bypass components in the first place".  Even though this seems counter
> intuitive, the data bears this out.  The low quality (or high ESR)
> reduces the amplitude of the parallel resonance peaks and makes the
> impedance more even.  Sounds odd, but correct, again the data bears
> this out.

If you model the parallel L and C you get an open.  If you sprinkle some 
R into those textbook equations, the impedance doesn't keep heading up 
to la-la land.  Really neat stuff.  I haven't had a chance to try this 
out myself, but I sure would like to.

Article: 107286
Subject: Re: fastest FPGA
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 26 Aug 2006 18:34:50 +1200
Links: << >>  << T >>  << A >>
rickman wrote:

> Symon wrote:
> 
>>"rickman" <gnuarm@gmail.com> wrote in message
>>news:1156553990.451411.179250@m79g2000cwm.googlegroups.com...
>>
>>>  To fully decouple power for fast chips the power planes
>>>must be built with a lot of internal capacitance along with a range of
>>>different capacitor values to allow parallel resonances to be bypassed
>>>and a low impedance to be obtained over a wide frequency range.
>>>
>>
>>Rick,
>>You may find this enlightening!
>>http://www.sigcon.com/Pubs/news/1_17.htm
>>A range of values (in the same package size) is no help, it just bloats your
>>BOM.
> 
> 
> Yes, I see what you are saying.  But the point is that you and Dr.
> Johnson make these statements with absolutely no supporting evidence.
> I was in the class, I saw the impedance plots and I even asked the
> exact same question about using the same package with the same
> parasitics.  The issue is not the inductance, the issue is SRF.  It
> took me awhile to understand why this is important.  It was especially
> hard for me to grasp when I looked at the data for three different
> value caps superimposed to show that the inductive reactance region was
> nearly identical.  But the smaller caps had a higher SRF.  So combining
> a small number of 0.1 uF, a few more 0.01 uF and more of the 0.001 uF
> parts seem to provide the best solution.
> 
> The impedance plot of the bare board with well coupled ground and power
> planes (no parts) shows the impedance dropping with frequency until it
> hits a SRF.  The impedance goes up a bit and then seems to oscillate in
> the very high frequency region.  Adding a single value of caps lowers
> the impedance at the low end, but actually makes the impedance higher
> at 150 MHz from parallel resonance between the cap and the plane.  It
> is not clear to me that any reasonable number of additional caps would
> reduce this peak to be acceptable.  Adding some caps at a smaller value
> added a new minimum in the impedance and raised the frequency of the
> parallel resonance.  Adding a third value of caps makes the impedance
> plot quite acceptable with peaks less than about 100 mohm up to 3 GHz
> and the bulk of the graph under 25 mohm below 300 MHz.  The graph is so
> very clear with the capacitor related minimums at about 20, 50 and 200
> MHz.
> 
> This guy chalenged some of my very deeply held beliefs in how to design
> power systems.  I could not find a single thing wrong with anything he
> said.  Others in the class would argue with him about their beliefs.
> But in the end it was beliefs vs. facts... no contest!

For some good plotted-examples, of what you describe, see this pdf

http://www.atmel.com/dyn/resources/prod_documents/doc4279.pdf

<paste>
> Another odd thing about power that I learned was that the placement of
> the decoupling caps is not at all critical.  This guy had designed a
> test board with caps at less than an inch from the test points and at
> about 3, 6 and 9 inches.  The graphs of impedance between the planes
> are nearly identical regardless of which capacitor was populated.  So
> it is clear that the caps don't need to be right on top of the power
> pins.  But to make the smaller caps work well, you do need more of them
> than you need of the larger value caps.  Not that I am doubting that
> you had enough.  I am just pointing out what the data indicates is
> required.

  You'd need to be carefull in the description. In this case, the caps 
decouple the plane, and the plane decouples the device. So short 
connections to the plane are VERY important, and once you have those, 
then yes, the absolute CAP placement is less critical.
- see fig 15 in the pdf above, for the plane vs trace nh/cm

  I think some PCB stackups, offer thinner plane separations, and higher
permittivity, both to drive down the plane impedance ( for some cost 
trade off ).

-jg



Article: 107287
Subject: Re: Digilent USB support from Xilinx Impact (Programmer cable SDK for Impact)
From: Daniel O'Connor <darius@dons.net.au>
Date: Sat, 26 Aug 2006 17:59:57 +0930
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com wrote:

> I inject a dll into the impact.exe, and hook DeviceIoControl and some
> other kernel32 APIs. impact.exe calls DeviceIoControl to read/write LPT
> I/O port using windriver6 driver. Instead of calling original windrvr
> DeviceIoControl function I just forward the TMS/TDI/TDO/TCK bits  to
> Digilent USB (or any other programmer cable).

Easy enough to do that with LD_PRELOAD in Linux. (.so injection)
Interesting idea!

> On linux the easiest could be to create a brand new windrvr emulator
> driver where we implement all the IOCTLs used by impact. BTW, I have no
> clue why they are using the windriver as a device driver, because all
> the features they do with the Jungo driver ius really simple and
> generic(eg: user mode I/O access, USB acces to device, etc.)

Assuming you can get the windrv header file, although I think you can
probably reverse engineer it anyway.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Article: 107288
Subject: Re: fastest FPGA
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 26 Aug 2006 11:14:47 +0200
Links: << >>  << T >>  << A >>
Jim Granville schrieb:

> http://www.eet.com/news/design/showArticle.jhtml;jsessionid=50HDYO5YS5YXCQSNDLRSKH0CJUNN2JVN?articleID=192300291
> 
> 
> Claims this :
> 
> "Imapcar has 128 processing elements, each with embedded memory. The 128
> parallel processing elements use the SIMD (single instruction stream
> multiple data stream) method. Each element processes four instructions
> per cycle. Thus, total performance was 100 Gops running at 100 MHz,
> enabling real-time image recognition at 30 frames per second."

Hmm. 128*100M*4 = 100G
Somehow I am missing a factor of two here.

Kolja Sulimma

Article: 107289
Subject: Re: fastest FPGA
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 26 Aug 2006 02:32:33 -0700
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Ray Andraka wrote:
> > real world high density high clock rate
> > designs tend to have average toggle rates of 20% or less.  Bit serial
> > designs have toggle rates that are a bit higher, but still usually well
> > under 50%.  I don't see dissipations more than about 20-25W, which can
> > be handled with proper thermal design on any of the large FPGAs.  In
> > most cases, I'd say the average dissipation I've been seeing on large
> > aggressive designs (2V6000, V4SX55, 2P70) is between 10 and 13 Watts.
>
> As a reference point, bit toggle rates of high density bit serial LUT
> SRL designs are SIGNIFICANTLY higher, and depending on the statistical
> distribution of 1's and 0's in the data easily hover around 75% or
> better. Doing designs which ignore the data specific toggle rates by
> simply assuming toggle rates based on traditional parallel designs is
> folly at best.
>
> The RC5 design was interleaved and pipelined with NO parallel
> operations. The nature of the RC5 data stream after the first stage is
> highly random, IE 50% of the data has a changes state on each clock,
> 25% of the data changes state at half the clock rate, and 12.5% of the
> data changes state at 1/4 the clock rate, ... to an average of near
> 75%, and short term variances that are statistically frequent much
> higher than that.

Now I'm totally confused TC. What does "highly random" data mean? Data
with a 75% toggle rate is halfway towards the ultimate pathological
case of "0101010101...". To me, highly random data implies a fairly
flat distribution with a 50% average toggle rate, period. If any given
flop has a 50% chance of toggling on any given clock cycle, your
summation seems to imply that some flops (or srl cells) are toggling
twice per cycle. That's a neat trick, and I don't get it.

> The same was true of the high density heat simulation model based on
> LUT SRL's and bit serial MAC's (inspired by your web page). The
> floating point data, with an assumed leading one, and normalized, has a
> nearly random toggle rate in the bit serial stream. It was necessary
> again to word interleave the engine to facilitate parallel loading of a
> multiplier, which shifted the ratio of LUT SRL's up to retime the
> interleaved data. And again, toggle rates overall were well above 50%,
> actually near 75%, and nothing like your "usually well under 50%"
> guideline.
> Reflecting on these two "normal" bit serial designs, I would suggest
> that heavily pipelined bit seral crypto and floating point math engines
> which are hand packed, and highly replicated, will easily exceed the
> 50% toggle rates. This is especially compounded when considering the
> serial shift costs of LUT SRL's.
>
> Replacing LUT SRL's with LUT RAM's certainly helps by removing the SRL
> bit shifting power, but doesn't lower the design toggle rates below 50%
> ... as they remain around 75% unless there are significant data
> dependencies that cause significant runs of zero's or one's.

Is crypto/FP data that different than other data? Perhaps there's an
opportunity here. A clever recoding could replace highly toggling
symbols by equivalent low toggle rate sequences. You could change your
75% to 25%, and get a 3:1 power reduction (um, tongue in cheek there).

One parting comment,
John, you're a fairly bright guy (I truly admire anyone with skills and
patience to put together a language compiler), but everyone errs from
time to time. In my callow youth, I designed a path in an XC3000 that
relied on route/gate delay to take a signal across a clock boundary, to
catch it on the next clock (In retrospect, 3000s were really tiny!).
Come the die shrink, I got burned. Sounds like you did too, even more
literally. I sympathize, but we live and learn. The caustic expletives
don't help your cause, and really puts folks off here.

Regards all,
Just John


Article: 107290
Subject: Re: FPGA -> SATA?
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 26 Aug 2006 04:14:07 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> Austin Lesea wrote:
> > Martin,
> >
> > No, and No.  Sorry, even V5 does not have the frequency tracking agility
> > to track the SATA spread spectrum clock.  And because of that, we have
> > no IP for it, either.
> >
> > The ASSP vendors are very protective about their business:  they
> > continue to make their little applications as tough to do as possible,
> > to keep out the 'big bad FPGA vendors' who seem to be eating up all
> > their businesses.  (Hey, we are just trying to make our customers happy!)
> >
> > Too bad:  when an industry is spending time being defensive, they have
> > already lost - any time spent not innovating means you are doomed to
> > failure.
>
> That probably depends on where you are standing.
>
>   Could be, that the FPGA sector needs to innovate, and include
> sufficent agility to track a SATA spread spectrum clock ?
>
>   Sounds more an issue of who decides the market is large enough to
> bother with, than any perceived fpga-vs-assp battles ?
>
> -jg

I'll second this with an added comment: Spread spectrum clocks are an
absolute must in some areas, and very desirable in others; I would
*love* to use a spread spectrum clock in my newest design because it
does not have a metal enclosure and EMI/EMC is a major issue.
When you make FPGAs (or ASICs or any other chip for that matter) for a
living but not shipping board and enclosure level products it's easy to
forget 'little details' like this (regulatory compliance) that systems
and board designers live with day in and day out.

Spread spectrum obviously alleviates the problem significantly (in some
very subtle ways too). A lot of vendors offer the ability to track a
spread spectrum clock; why not FPGA vendors too?

Cheers

PeteS


Article: 107291
Subject: Re: RocketIO over cable
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 26 Aug 2006 04:28:40 -0700
Links: << >>  << T >>  << A >>
Ed McGettigan wrote:
> vt2001cpe wrote:
> > Thank you everyone for your quick and informative responses! In the
> > event of a large number of bit errors, is it possible for a comma
> > character to be incorrectly introduced? What would the effect be? Will
> > the CRC fail and put the state machine into an error state, or will
> > data continue to transmit, unaware?
>
> It is possible to generate more than a single bit error in the same
> 8b10b word, but with a well designed link this is very unlikely to
> occur.  In any case your transmitter is completely unaware that an
> error actually occurred and will happily continue transmitting. It's
> your receiver logic needs to be able to handle any errors that happen.
>
> The worst case that could happen is that the error generates a comma
> character that is out of alignment with the previous alignment.  This
> would cause a constant stream of errors until a correct comma character
> is received and the link realigns to the correct 8b10b word. All of
> this is fairly standard stuff and has been around for decades in
> many different protocols.
>
> Since it doesn't look like you have a particular protocol in mind. I
> would suggest that you take a look at the light weight Aurora protocol
> http://www.xilinx.com/aurora  Even if you decide to not use it, you
> should be able to learn a lot from it.
>
> Ed McGettigan
> --
> Xilinx Inc.

As noted, much depends on the cable. I have used a lot of high speed
cables, and the best of the bunch is made by Gore (and whoever they may
have licensed their 'Eye-Opener' self equalising cable to)
http://www.gore.com/en_xx/products/cables/copper/backplane/gore_eye-opener_airmaxvs_cable_assemblies.html

I've run 4x InfiniBand over 11 metres on this type of cable and it was
within the spec (10dB   insertion loss max, amongst other things). That
was the best I ever achieved with 4x cables. I once had a cable that
could do <= 10dB attenuation of a single 2.5Gb/s pair at 17m.

The further you want to run the signal, the more expensive the cable is
going to be. Spectra Strip is usually the basis of most high speed
cable assemblies, which is not particularly cheap.

As always, the loss budget includes the transmitter and receiver specs.
I haven't seen an FPGA that was IB compliant, but could run IB over
limited distances.

Of course, if you want to run faster than that (DDR IB comes to mind ;)
then your cable length will be shortened proportionately.

Cheers

PeteS


Article: 107292
Subject: Re: FPGA -> SATA?
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 26 Aug 2006 12:49:07 GMT
Links: << >>  << T >>  << A >>
"PeteS" <PeterSmith1954@googlemail.com> wrote:

>Jim Granville wrote:
>> Austin Lesea wrote:
>> > Martin,
>> >
>> > No, and No.  Sorry, even V5 does not have the frequency tracking agility
>> > to track the SATA spread spectrum clock.  And because of that, we have
>> > no IP for it, either.
>> >
>> > The ASSP vendors are very protective about their business:  they
>> > continue to make their little applications as tough to do as possible,
>> > to keep out the 'big bad FPGA vendors' who seem to be eating up all
>> > their businesses.  (Hey, we are just trying to make our customers happy!)
>> >
>> > Too bad:  when an industry is spending time being defensive, they have
>> > already lost - any time spent not innovating means you are doomed to
>> > failure.
>>
>> That probably depends on where you are standing.
>>
>>   Could be, that the FPGA sector needs to innovate, and include
>> sufficent agility to track a SATA spread spectrum clock ?
>>
>>   Sounds more an issue of who decides the market is large enough to
>> bother with, than any perceived fpga-vs-assp battles ?
>>
>> -jg
>
>I'll second this with an added comment: Spread spectrum clocks are an
>absolute must in some areas, and very desirable in others; I would
>*love* to use a spread spectrum clock in my newest design because it
>does not have a metal enclosure and EMI/EMC is a major issue.
>When you make FPGAs (or ASICs or any other chip for that matter) for a
>living but not shipping board and enclosure level products it's easy to
>forget 'little details' like this (regulatory compliance) that systems
>and board designers live with day in and day out.
>
>Spread spectrum obviously alleviates the problem significantly (in some
>very subtle ways too). A lot of vendors offer the ability to track a
>spread spectrum clock; why not FPGA vendors too?

You can as long as you don't use the DCM (or anything like it) and
route the fpga for the highest allowed clock frequency. If you use an
external device to create your clocks and feed them into the fpga,
there is no reason why an fpga won't work with spectrum spread clocks.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 107293
Subject: Re: FPGA -> SATA?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 26 Aug 2006 07:16:20 -0700
Links: << >>  << T >>  << A >>
Nico Coesel schrieb:

> "PeteS" <PeterSmith1954@googlemail.com> wrote:
>
> >Jim Granville wrote:
> >> Austin Lesea wrote:
> >> > Martin,
> >> >
> >> > No, and No.  Sorry, even V5 does not have the frequency tracking agility
> >> > to track the SATA spread spectrum clock.  And because of that, we have
> >> > no IP for it, either.
> >> >
> >> > The ASSP vendors are very protective about their business:  they
> >> > continue to make their little applications as tough to do as possible,
> >> > to keep out the 'big bad FPGA vendors' who seem to be eating up all
> >> > their businesses.  (Hey, we are just trying to make our customers happy!)
> >> >
> >> > Too bad:  when an industry is spending time being defensive, they have
> >> > already lost - any time spent not innovating means you are doomed to
> >> > failure.
> >>
> >> That probably depends on where you are standing.
> >>
> >>   Could be, that the FPGA sector needs to innovate, and include
> >> sufficent agility to track a SATA spread spectrum clock ?
> >>
> >>   Sounds more an issue of who decides the market is large enough to
> >> bother with, than any perceived fpga-vs-assp battles ?
> >>
> >> -jg
> >
> >I'll second this with an added comment: Spread spectrum clocks are an
> >absolute must in some areas, and very desirable in others; I would
> >*love* to use a spread spectrum clock in my newest design because it
> >does not have a metal enclosure and EMI/EMC is a major issue.
> >When you make FPGAs (or ASICs or any other chip for that matter) for a
> >living but not shipping board and enclosure level products it's easy to
> >forget 'little details' like this (regulatory compliance) that systems
> >and board designers live with day in and day out.
> >
> >Spread spectrum obviously alleviates the problem significantly (in some
> >very subtle ways too). A lot of vendors offer the ability to track a
> >spread spectrum clock; why not FPGA vendors too?
>
> You can as long as you don't use the DCM (or anything like it) and
> route the fpga for the highest allowed clock frequency. If you use an
> external device to create your clocks and feed them into the fpga,
> there is no reason why an fpga won't work with spectrum spread clocks.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl

well in the case of SATA it is not so much an option.

FPGA has no issues when external SATA PHY is used, but then we are not
much talking about using MGT ofr SATA anymore.

if we use external CDR circuitry that locks to SATA and spits out
serial stream suitable for MGTs, then I think its still possible that
MGTs dont lock anyway. and I dont think such an CDR IC is easier to
find (or cheaper) then SATA PHY (what is almost impossible to obtain)

BTW in my comment about V2Pro MGT issues I did mean the CDR clock
region being too narrow +-100ppm (SATA +-300), those making V2Pro not
to lock in  some cases where initial clock is too far away - also when
spread spectrum is not used. This issue has been fixed in V4FX ASFAIK -
the CDR lock range is  extended.

Antti


Article: 107294
Subject: Re: FPGA -> SATA?
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 26 Aug 2006 16:36:53 +0200
Links: << >>  << T >>  << A >>
<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1156572617.852268.132070@m79g2000cwm.googlegroups.com...
> Austin Lesea wrote:
>> The ASSP vendors are very protective about their business:  they
>> continue to make their little applications as tough to do as possible,
>> to keep out the 'big bad FPGA vendors' who seem to be eating up all
>> their businesses.  (Hey, we are just trying to make our customers happy!)
>>
>> Too bad:  when an industry is spending time being defensive, they have
>> already lost - any time spent not innovating means you are doomed to
>> failure.
>
> Ok ... I took the time to see who the little guys are at SATA-IO that
> Austin claims are running completely scared of the  'big bad FPGA
> vendors'. Frankly, when I read down the list, it becomes pretty obvious
> many of the players could aquire Xilinx with a day or two's free
> profits and not even worry about the investment costs if they paid
> twice what Xilinx was worth.
>
> The only two things obvious, is that Austin's/Xilinx's head is so full
> of shit if they think half these companies even care what Xilinx does
> with SATA, and that Xilinx is so full of NIH that they are failing to
> meet custmers needs by refusing to play nicely inside the industry wide
> SATA club.
>
> Anybody spot those that Austin claims "are running completely scared of
> the  'big bad FPGA vendors'."????
>
[snip]
Dear Mr Brass!

What has the World done to You? Did you lost your grannys savings in Xilinx 
stock or your own balls in the supermarket !?

Some free advice to you:
1) go fly a kite
2) rent a movie titled "Joe vs Volcano", watch it, to the very end
3) think twice before claiming to know the contents of the heads of the 
others

-------------


The ASSP vendors are very likely not directly scared, but for some reason 
almost every document regarding SATA IC's is only available under NDA and 
SATA PHY silicon is virtually impossible to obtain. The most reasonable use 
of SATA PHY would be an FPGA based product. As for the ASIC designs it makes 
more sense to integrate the PHY on chip. So for me its pretty much clear why 
SATA PHYs are not available, the same Silicon/IP vendors are also selling 
SATA IP, and selling bare SATA PHY as IC (to be possible be used with an 
FPGA) would make their possible earnings from ASSP and ASIC IP sales 
smaller. So some small guys are defenetly looking at FPGA vendors.

Antti,
who just returned from "flying the kite" 



Article: 107295
Subject: Re: Installing Quartus 6 "web edition full"
From: "Subroto Datta" <sdatta@altera.com>
Date: Sat, 26 Aug 2006 14:43:29 GMT
Links: << >>  << T >>  << A >>
There is no difference between the Quartus II 5.1 Web Edition and Quartus II 
5.1 Web Edition Full. The name difference stems from the fact that the 
Quartus II 5.1 Web Edition Full is a single file download while the Quartus 
II 5.1 Web Edition is a three file download (for folks with slower links). 
If you received a CD with web edition you would have the Quartus II 5.1 Web 
Edition Full.

If you have a new license file go to Tools->License Setup and point to the 
file you have in the License File Entry at the top.

Hope this helps,
Subroto Datta
Altera Corp.


<edaudio2000@yahoo.co.uk> wrote in message 
news:1156519663.127711.210640@m79g2000cwm.googlegroups.com...
> Is there a difference between Quartus "Web Edition" and "Web Edition
> Full"?
>
> I bought the NIOS development kit which came with Quartus 5.1 Web
> Edition Full
>
> I now want to replace it with the standard Quartus 6 WEb Edition, but
> the program won't allow me to enter a new (downoladed) license file,
> nor it will perform the automatic web license update Message: "Can't
> find a newer license file for this system at the Altera website,
> contact Altera Customer service"
>
> Does anybody know what may be going on?
>
> I have raised a  service request on the altera website, but I suspect
> they may take a very long time to respond.
>
> Any help appreciated
>
> TIA
> 



Article: 107296
Subject: Re: Digilent USB support from Xilinx Impact (Programmer cable SDK for Impact)
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 26 Aug 2006 07:53:39 -0700
Links: << >>  << T >>  << A >>
Go to windriver website and download the evaluation version. It
includes the header files.

Zoltan


Article: 107297
Subject: Re: UltraController II + SystemAce
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Sat, 26 Aug 2006 08:21:31 -0700
Links: << >>  << T >>  << A >>
Patrick,

what board are you targeting?

If you can send me your design I'll have a look to see what might be wrong.

It looks like you can download the bitstream with XMD and then connect 
to the PPC with XMD. You can download and run software to the PPC 
through XMD with

$ xmd
XMD% connect ppc hw -debugdevice icachestartadr <adr> dcachestartadr <adr>
XMD% dow <elf file>
XMD% run

You might have a look at the xmd.ini file to see what the correct 
"connect" parameters are.

You can also have a look at XAPP807. It is a small system that makes use 
of the UC2 and the TEMAC.


- Peter



Patrick Dubois wrote:

> Hello everyone,
> 
> First of all, big thanks to everyone who contribute to this newsgroup.
> Most of the time, I can find a solution to my problem just googling
> this newsgroup. Not this time however...
> 
> I know that this is a long post but if you can help with the
> UltraController II + SystemAce or UC2 + xmd, please read on.
> 
> I'm currently trying to get a system with the UltraController II up and
> running. To make a long story short (hopefully), I started with the
> tools at v7.1, the UC2 reference design, and an eval board from Avnet.
> I was able to successfully build a small system using the UC2 and a
> Wishbone bus. I always ran the UC2 code using the debugger however (XMD
> + GDB).
> 
> Confident that the UC2 was a good solution for me (as I don't have
> external ram), I spent a few months incorporating the UC2 in my real
> design (3 FPGAs, two VP40 and one VP7). I used SystemC to simulate the
> UC2 and now I reached the point of trying it out in hardware. That's
> when the problems start...
> 
> First of all, xmd can't even detect the PowerPCs in the JTAG chain in
> the big design. So I took a step back and went back to the Avnet eval
> board to play around more and get to understand the flow better. Right
> now I'd like to accomplish two things:
> 1- I'd like to be able to create a SystemAce file that loads both the
> bit config file and the elf program file at boot-up (for the Avnet
> board with a single VP7).
> 2- I'd like to understand how xmd can load and run my software without
> the GDB debugger.
> 
> For the SystemAce, I used the modified genace.tcl script that comes
> with the reference design but it doesn't work. To be more precise, I
> can generate the ace file, the SystemAce loads everything in the FPGA
> fine (done led goes up), but my code doesn't boot. The hardware part
> seems okay because one of my debug led turns on (attached directly to
> VCC in the fpga). Since the code doesn't boot, I tried to use xmd to
> connect to the PowerPC. However, xmd doesn't detect the PowerPC (ERROR:
> Unable to connect to PowerPC target. Invalid Processor Version No
> 0x00000000"). That's strange because if I then proceed to load the bit
> file using iMPACT, then xmd can detect the PowerPC fine.
> 
> Now for xmd, I'd like know how to load and run my code with it. I
> followed the instructions in XAPP571 (to properly use the DEBUGHALT
> controller), but it doesn't work. I tried a few things but I'm really
> in the dark as I don't have deep understanding of the whole EDK flow
> (which is why I choose the UltraController in the first place).
> 
> I appologize for the long post but I wanted to give as much details as
> possible to whoever could help me... By the way, I opened several
> webcases with Xilinx to help me along the way to where I am now, but I
> thought I'd give this newsgroup a shot for any UC2 experts out there.
> 
> Thanks.
> 
> Patrick Dubois
> 

Article: 107298
Subject: Re: USB PHYs and drivers that folks have used
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 26 Aug 2006 15:35:01 GMT
Links: << >>  << T >>  << A >>
> I'm planning on using a Cypress CY7C67200 in a project. It has 2 USB
> ports and one can be on-the-go, meaning it can switch between host
> and peripheral mode as necessary. I really just need 2 host ports.
>
> The chip is 8051 based with support hardware. However it seems to
> have some mode where it can get out of the way and be controlled
> by an external device, which would be the FPGA. It's all theory, I
> need to prove out functionality.
>
Thanks for the input.  One of the devices under consideriation is the 
Cypress  CY7C68016 which is 8051 based with USB, and I'm guessing similar in 
some fashion to the 7C67200 that you're using (but I'll take a look maybe 
that would be a better choice for us too).  The only 'problem' is that the 
system as a whole has on the order of ~150-200 I/O pins (depends on other 
system level tradeoffs that we're considering).  The logic to support those 
I/O pins won't take up many of the logic resources of any FPGA that can 
support the I/O pin requirements.

Given that, and the fact that it appears (based on logic resources of the 
cores I'm looking at) that I can embed a processor and USB and the custom 
logic for all the other I/O all in one part and just skip over having a 
separate part just to get the USB functionality it seems irght now to be the 
least expensive product cost approach at the moment (even while adding the 
external USB PHY).  But now the issues become:
- Has someone really field tested and qualified the core?
- Are their reference designs available upon which that qualification was 
based?
- Linux drivers to support the core?

Without 'yes' answers to each of the above questions it will drive up risk 
and development costs which need to be balanced into the equation for 
deciding.

I'm not unwilling to pay for the core to get the above mentioned assurances, 
but if someone has already done this exercise with the OpenCores version it 
would be worth the time to persue that avenue as well.

KJ 



Article: 107299
Subject: What is the truth about the Virtex5 ?
From: jeffnewcomb@nci-usa.com
Date: 26 Aug 2006 09:06:26 -0700
Links: << >>  << T >>  << A >>
I questioned the availability of the Virtex5 back in July on this group
and got some responses from Xilinx people saying it was being sampled
and to get a sample I needed to get an order in immediately. I did that
even though the parts were not even in distributors systems and the
local Xilinx reps initially were not sure what delivery would be.  I
did get a response back from the rep saying there was a 13 week
delivery for an engineering sample which would be in late Sept. and you
could not get production parts until next year. I could live with that
and proceeded with my design using a V5LX50. Yesterday we got a FAX
from our distributor /rep saying delivery of the engineering sample
would not be until May 2007!!!. This is a full year after the part was
anounced. I have seen numerous advertisements for the Virtex 5
"Shipping NOW". Does anyone know the truth behind this part ???? Are
there major problems with the part?




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search