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 101850

Article: 101850
Subject: Re: Can an FPGA be operated reliably in a car wheel?
From: MikeShepherd564@btinternet.com
Date: Mon, 08 May 2006 02:08:41 +0100
Links: << >>  << T >>  << A >>
>...FPGA...in a car wheel...100km/hr...approx 400g...
>...15" diameter wheel...

Your figures seem correct, close to the outside of the wheel.

The first thing you should think about is how not to have the FPGA
there.  Maybe you need sensors or outputs in the wheel itself, but do
you really have to process the information there?  Take a look inside
a VCR to see how high-bandwith signals are communicated with the
spinning heads.

If you can't avoid it, keep the circuit close to the axis, so the
acceleration is less.

Article: 101851
Subject: booting problem ML300 :eth0: Could not read PHY control register; err
From: "chakra" <narashimanc@gmail.com>
Date: 7 May 2006 18:12:57 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am loading linux onto the ML300. I have created a zImage.elf file for
ppc with the drivers and bsps for the project created using the EDK.I
am booting from NFS, the board is the client and my system is the
server. while booting up i get the following error.

..................................
.................
eth0: using fifo mode.
eth0: No PHY detected.  Assuming a PHY at address 0.
eth0: Xilinx EMAC #0 at 0x40C00000 mapped to 0xC9070000, irq=31
eth0: id 2.0h; block id 7, type 1
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
eth0: Could not read PHY control register; error 19
IP-Config: Complete:
      device=eth0, addr=192.168.1.10, mask=255.255.255.0,
gw=192.168.1.1,
     host=192.168.1.10, domain=, nis-domain=(none),
     bootserver=192.168.1.5, rootserver=192.168.1.5, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.5
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.1.5
Root-NFS: Unable to get mountd port number from server, using default
eth0: Could not read PHY control register; err

Coould anyone please guide me, as to what i am doing wrong, and
possible solution for this error.

with warm regards,
chakra.


Article: 101852
Subject: Re: Anyone use Xilinx ppc405 profiling tools?
From: "Alan Nishioka" <alan@nishioka.com>
Date: 7 May 2006 18:18:29 -0700
Links: << >>  << T >>  << A >>
Alan Nishioka wrote:
> Does anyone use the profiling tools with the Xilinx ppc405?

I figured it out.  Profiling the ppc405 doesn't work using edk7.1.  The
code generated is broken.  Using edk8.1 it works fine.

Since nobody responded, I am still wondering; Is anybody using the
Xilinx ppc405?
(Or perhaps I they all don't read news on the weekends)

Alan Nishioka


Article: 101853
Subject: Re: A constant value of 0 in block
From: "YiQi" <yiqihuang@gmail.com>
Date: 7 May 2006 18:22:47 -0700
Links: << >>  << T >>  << A >>
Thanks William,
For such a big program, it is very hard to follow 100% of the template.
My code is already in that structure, except that it doesn't have to
work in rising_edge(clock) for the else part.

One thing I really want to ask is does "equivalent to a wire in block"
warning seriously important on synthesis? Is it saft to ignore that?

What I am more worry is the " a constant value" warning, I think I have
to fix that as it may totally check my code.


Article: 101854
Subject: Re: Xilinx 3s8000?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 08 May 2006 13:25:00 +1200
Links: << >>  << T >>  << A >>
Ron wrote:
> Jim Granville wrote:
> 
>> Feeling better now Ron ?
> 
> I would feel even better if people like you who have nothing to 
> contribute would stop harassing me.
> 
>> as you are clearly 100% honest, can we take it that the share in the 
>> fame and glory you offer, also extends to a share in the (now 
>> mentioned) prize ?
> 
> 
> You must have a reading comprehension problem Jim. I posted a link to 
> the RSA challenge number in my original message that started this 
> thread. Had you bothered to look it up, the $30,000 (up to $200,000 for 
> RSA-2048) was clearly posted on the page I linked to.

I do not have the time to chase down links, and links are not 
comprehension...

 > With Austin bragging about the 1.73 billion dollars of US sales last
 > year for Xilinx, I figured the $30,000 RSA prize would be
 > inconsequential chicken feed to them, but yes, of course I would be
 > willing to share half of the RSA prize money with *anyone* who would be
 > willing to provide me with at least the design software to complete my
 > project (preferably NOT Xilinx in view of their attitude towards my
 > project).

If you had mentioned that initially, this could have been a more
productive thread ?


>> Tip: If you want to succeed in any task, it is better to stay focused, 
>> avoiding wasting energies, and also not to alienate any (potential) 
>> sources of assistance. Lots of clever people lurk in this news group.
> 
> 
> Haven't you realized yet that Xilinx reps are a complete waste of my 
> time and energy? They have already made it abundantly clear that they 
> are *NOT* a potential source of assistance to me. 

Well, I was not actually refering to Xilinx (comprehension?)
- you do seem to be rather Xilinx fixated ? :)

-jg


Article: 101855
Subject: Re: How to avoid lossing channel bonding when using Rocket IO?
From: "king" <frogkinger908@sina.com>
Date: 7 May 2006 19:06:33 -0700
Links: << >>  << T >>  << A >>
to Ed McGettigan,

Thank you very much and sorry for late reply.
I am during vocation from 5.1 to 5.7

All you assumptions are correct!

As for CC, I send one after transmitting 5 data packet,
each packet has a constant length: 256 bytes.

And now I found some new phenomenons:
The data flow is TX_fifo -> (TX_logic -> RIO -> RX_logic) -> RX_fifo,
when there is no operation to the rx_fifo( rx_fifo_wr is ' 0' ),
the RIO would seem to be OK, the RX FSM is all right.
As soon as I use the rx_fifo, the whole data flow would be bad, just as
metioned.

I am very surprised at this phenomenon.
Because there is no feedback from the rx_fifo to the RIO,
why the operation to the fifo would influence the RIO?

Do you think this is caused by PAR?

Thank you!

king


Article: 101856
Subject: Re: Can an FPGA be operated reliably in a car wheel?
From: "Andrew FPGA" <andrew.newsgroup@gmail.com>
Date: 7 May 2006 19:15:11 -0700
Links: << >>  << T >>  << A >>
> Your figures seem correct, close to the outside of the wheel.
Thanks for pointing that out Mike, my physics were obviously a bit
lacking. Redone the calculations and I see that I now get 108 g if the
FPGA is located at 50mm from the axis of rotation. I need a minimum
area for the electronics so a 50 mm radius gives me that.

Still, the question remains is 100g too much for an FPGA? How much g
could it take reliably? I know 100g is way too much for a human and I
know that some MEMS accelerometers spec up to 10,000 g for the absolute
max rating (measurement up to 250g max I have seen so far).

Regards
Andrew

MikeShepherd564@btinternet.com wrote:
> >...FPGA...in a car wheel...100km/hr...approx 400g...
> >...15" diameter wheel...
>
> Your figures seem correct, close to the outside of the wheel.
>
> The first thing you should think about is how not to have the FPGA
> there.  Maybe you need sensors or outputs in the wheel itself, but do
> you really have to process the information there?  Take a look inside
> a VCR to see how high-bandwith signals are communicated with the
> spinning heads.
>
> If you can't avoid it, keep the circuit close to the axis, so the
> acceleration is less.


Article: 101857
Subject: Re: Funky experiment on a Spartan II FPGA
From: "mammo" <ankur101@gmail.com>
Date: 7 May 2006 19:50:27 -0700
Links: << >>  << T >>  << A >>
Hey people,

Thanks for all the suggestions... will keep you guys posted.

Best,
mammo


Article: 101858
Subject: Re: Can an FPGA be operated reliably in a car wheel?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 May 2006 20:21:00 -0700
Links: << >>  << T >>  << A >>
Ever since WW II, >60 years ago, electronic circuits have been used in
artillery shells.
I have seen a whole TV camera and transmitter housed in the tip of a
155 mm shell. Those accelerations upon firing are much higher than
400g.
Plastic-encapsulated conventional commercial-grade ICs are actually
extremely rugged, since everything is completely encapsulated in
plastic, the silicon or the wires have nowhere to go. Modern BGA
packages do not even have bonding wires...
I will look for acceleration test data in our reliability reports.
I am sure the G-loads are not your problem. Temperature may be...
Peter Alfke, Xilinx


Article: 101859
Subject: Re: Can an FPGA be operated reliably in a car wheel?
From: John_H <johnhandwork@mail.com>
Date: Mon, 08 May 2006 04:23:48 GMT
Links: << >>  << T >>  << A >>
Andrew FPGA wrote:
> What are the maximum g forces an FPGA could operate under?
> E.g. an FPGA sitting in a car wheel, where the car is travelling at 100
> km/hr experiences approx 400g due to the centripetal acceleration.
> (assuming a 15" diameter wheel).
> Can anyone point to products or applications where this is done
> already? (I know tyre pressure sensors are coming..but these are not
> FPGAs)
> 
> What would the mass of your typical FPGA package/silicon be? Say a 256
> ball BGA(e.g. FT256 or similar). Force = mass x acceleration so I guess
> you could work out the force on the solder balls etc etc.
> 
> I know vibration probably is an issue also - but at least that can be
> mitigated to some extent with the mechanical design of our product
> ,e..g vibration damping etc. However, the centripetal force is another
> matter - its always there whenever the wheel is rotating. (and grows
> with the square of the cars velocity).

By getting as close to bare die as is reasonable (chip scale packaging 
comes to mind) you can reduce the mass to the point where forces are 
inconsequential.  When hybrid microelectronics started with all the 
teeny tiny assemblies using bare die, printed resistors, and other space 
saving techniques, it was to house electronics in artillery shells. 
Those were only fired over the ocean in WW II for fear the enemy might 
get hold of an unexploded shell and discover the tiny electronics.

Work toward a smallest mass solution and you'll probably have an easy 
time of it.  At least you don't have to worry about the electrons 
bunching up to one side of the chip!

Article: 101860
Subject: Re: Xilinx 3s8000?
From: fpga_toys@yahoo.com
Date: 7 May 2006 21:26:01 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> fpga_toys@yahoo.com wrote:
> >> Peter continually goes off half cocked where hobbiests are involved,
> > expecting that they should do their projects like any respectable
> > Fortune 100 company.  He's exceptionally proud of their High Margins,
> > which translate to high end customer costs.
>
> Why do you write such outrageous lies, just because you like the ring
> of them?
> I have never ever mentioned our margins. That's not my style...

Margins, Profits, Profit Margins? Ring a bell? Hardly lies ... you can
run, but you can not hide from your own words. Start with:

"Our primary obligation is to remain an innovative and profitable
company, to the benefit of our customers, our employees, and our
shareholders. Satisfying exotic academic research is fine, as long as
it does not conflict with the primary obligation.
Just my personal opinion...
Peter Alfke"

remember that discussion, where you support keeping access to Xilinx
tools proprietary?

Your arguement in that case was a mock sham about support costs ...
total Bovine ....

When Ron is upset about software license costs and annual support fees
he mirrors real concerns that cripple your market expansion. You
believe that technology is, as you have said, the "crown jewels" ...
more like the lead anchor around your companies neck standing on the
plank.

> I also have often bent over backwards to help students and hobbyist,
> since I remember once havin been one of them myself. (I do discourage
> people from wasting their time on obsolete chips, though...)

There was a day, not that long ago, when pride of craftsmanship would
be brought out when you proudly took an older product in for some
service help. I do it all the time with my Corvairs, Remington &
Underwood Typewritters, Antique Clocks, Hover Vacumn, Packard Bell B&W
Tube TV and Radio, etc ... and when the service personel insist on
throwing that piece of crap away and buying some new product life
engineered for warranty term plus a day, I KNOW I'm dealing with
someone that lacks experience, integrity and pride in their products.

Xilinx prides it's self from what I hear, in keeping every old version
of software safe. Yet you repeatedly insist that a hobbiest that wants
to play with some XC3K should just buy some new fpga instead ... even
after he states he's interested in those. A few years back I had $12K
in NOS two year old XC4085XL parts, that Xilinx turned their back on
and would no longer provide synthesis support for telling me instead to
buy new Virtex Parts to use ISE 5.1 with.

Remember? Do you remember your less than helpful tirade regarding a
hobbiest/developer needing 5V support? Do you need direct quotes and
other references?

yes, you might help people ... and at the same time, are lacking.

> I would even have tried to help Ron, if he had presented a rational
> plan for his endeavor, but he didn't. And then he sank into
> obscenities...

And you don't rapidly escalate disagreements and call people an
imbecile ... just weeks ago?
Remember those words?? ... shall I quote? ... and that's just a start,
many more cases .... you can run, but you can not hide from your own
words.

> This used to be a polite, informative and cooperative newsgroup, until
> you and Ron descended on us, and turned it into an ugly shouting
> contest.

Sorry Peter ... how many times have I asked you, Austin, and other
Xilinx employees to play nice here and be respectiful, suggesting that
you will be treated as you treat others here. That was ignored, and you
gleefuly enter into personal attacks and character assassination at the
drop of a hat to divert the discussion from the very debatable
practices and policies of your employer.

I don't think Ron's choice of words here are the best either ... but
neither are yours, or your actions, or those of other Xilinx employees
in this forum. Your ranting, stomping, insults, and tirades to deflect
valid and justified discussion on flawed Xilinx policy just disgrace
this forum worse.

Grossly shameful .... I don't know how anyone could work for a company
with employees that lack civility, integrity, and a common sense of
respect.  And you dare to repeatedly mock me for using a common screen
name for my list participation as lacking the integrity to use my own
name?  What a crock ... but I'm learning that it's the shame of working
for a company that also hides behind the alias of Xilinx ... rather
than proudly bearing the name of it's founders.

I'm discovering from your actions, that Xilinx is not a company to do
business with, or sully the name of my own business representing your
products.

So, shall we keep quoting your lies today?


Article: 101861
Subject: PCI Core compatibility
From: "water7" <krbyxtrm@gmail.com>
Date: 7 May 2006 21:47:11 -0700
Links: << >>  << T >>  << A >>
Hello i would like to know if anyone is familiar with any pci vendor
core?
I have 2 PCI core working on specific motherboards  but not on both.
I can't tell up to now what is the problem.
The first core works on Elitegroup K7 motherboards.
The second core works on motherboard with pentium 4, and as i have said
earlier those core doesn't work on both motherboard.

is this a pci core design problem or its has something to do with the
motherboard?

Thx.

ps.


Article: 101862
Subject: Re: Xilinx 3s8000?
From: Ron <News5@spamex.com>
Date: Sun, 07 May 2006 23:10:03 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> - you do seem to be rather Xilinx fixated ? :)

Actually Jim, there is a good reason for that. It almost physically 
pains me to say something good about Xilinx in view of this thread's 
history ;-), but their's is the only version of Synplicity that will 
compile and synthesize my design for anything above a bus width of 256 
bits. :-(

Here is the email I received from Synplicity tech support:

     > Hi Ron,
     >
     > This is a bug with pro ASIC mapper and I have filed bug
     > for this issue and I will get this fixed [bug id is: 170164].
     >
     > Design passes when targeted to SX-A technology.
     > Unfortunately, I could not find any workaround for this issue.
     > This design works fine with other technology like xilinx V4,
     > Spartan2 too.
     >
     > Regards,
     > Prashanth

Anyone know how to easily track Synplicity bug reports?

Article: 101863
Subject: Re: PCI Core compatibility
From: "Antti" <Antti.Lukats@xilant.com>
Date: 7 May 2006 23:42:05 -0700
Links: << >>  << T >>  << A >>
full PCI compliance isnt so easy, some PCI cores that seem to work on
one system or even one slot of one system may fail on other system or
even other slot of the same system.

most likely due to small issues with timing. if you are seeing this
then it eventually calls for long trouble-shooting

Antti


Article: 101864
Subject: Re: FPGA-based hardware accelerator for PC
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Mon, 8 May 2006 06:55:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2006-05-07, JJ <johnjakson@gmail.com> wrote:
> I would say that if we were to see PCIe on chip, even if on a higher $
> part, we would quickly see alot more  co pro board activity even just
> plain vanilla PC boards.

You might be interested in knowing that Lattice is doing just that in
some of their LatticeSC parts. On the other hand, you are somewhat
limited in the kinds of application you are going to accelerate since
LatticeSC do not have embedded multipliers IIRC. (Lattice are
targetting communication solutions such as line cards that rarely needs
high performance multiplication in LatticeSC.)

/Andreas

Article: 101865
Subject: Re: FPGA-based hardware accelerator for PC
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Mon, 8 May 2006 06:58:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2006-05-06, Piotr Wyderski <wyderski@mothers.against.spam-ii.uni.wroc.pl> wrote:
> What could it accelerate? Modern PCs are quite fast beasts...
> If you couldn't speed things up by a factor of, say, 300%, your
> device would be useless. Modest improvements by several tens
> of percents can be neglected -- Moore's law constantly works
> for you. FPGAs are good for special-purpose tasks, but there
> are not many such tasks in the realm of PCs.

One interesting application for most of the people on this
newsgroup would be synthesis, place & route and HDL simulation.
My guess would be that these applications could be heavily
accelerated by FPGA:s. My second guess that it is far from trivial
to actually do this :)

/Andreas

Article: 101866
Subject: Re: Anyone use Xilinx ppc405 profiling tools?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 8 May 2006 00:16:24 -0700
Links: << >>  << T >>  << A >>
Yes the AMCC 405 hard-core in the Xilinx FPGA's is the 'buggy 405'
readt the powerPC errata docs from Xilinx. I was terrified when I
discovered tha the PPC hardcore has so my so old and known bugs still
present in V4 silicon.

surprisingly - after being terrified by the amount of bugs, I was again
positivly surprised to see how easy it is to get PPC linux running on
V4 !!

the PPC errata in V2Pro/V4 exist, but for real issues there are either
patches already or they are not relevant in most design

Antti


Article: 101867
Subject: Re: FPGA-based hardware accelerator for PC
From: fpga_toys@yahoo.com
Date: 8 May 2006 00:38:31 -0700
Links: << >>  << T >>  << A >>

Piotr Wyderski wrote:
> AFAIR a nice 2 GHz Sempron chip costs about $70. No FPGA can
> beat its price/performance ratio if its tasks would be CPU-like. An FPGA
> device can easily win with any general-purpose CPU in the domain of
> DSP, advanced encryption and decryption, cipher breaking, true real-time
> control etc., but these are not typical applications of a PC computer, so
> there is not much to accelerate. And don't forget about easier alternative
> ways, like computing on a GPU present on your video card:

CPU's are heavily optimized memory/cache/register/ALU engines, which
for serial algorithms, will always out perform an FPGA unless the
algorithm isn't strictly serial in nature.

In doing TMCC/FpgaC based research for several years, it's suprising
how many natively serial algorithms can be successfully rewritten with
some significant parallel gains in an Fpga domain. The dirty part of
"fixing" traditional optimized C code, is actually removing all the
performance specific coding "enhancements" ment to fine tune that C
code for a particular ISA. In fact, some rather counter intuitive
coding styles (for those with an ISA centric experience set) are
necessary to give an FPGA C compiler the room to properly optimize the
code for performance.

Consider variable reuse. It's very common to declare just a couple
variables to save memory (cache/registers) and heavily reuse that
variable. For an FPGA C compiler, this means constructing multiple
multiplexors for each write instance of the variable, and frequently
comitting  a LUT/FF pair for it. If the instances are separated out,
then frequently the operations for the individual instances will result
in nothing more than a few wires and extra terms in the LUTs of other
variables.  So the ISA optimized C code can actually create more
storage, logic, and clock cycles that may well be completely free and
transparent with a less optimized and direct coding style that
issolates variable by actual function.

Generally a small 16 element array is nearly free, by using LUT based
RAMs for those small arrays.  Thus it becomes relatively easy to design
FPGA code sequences around a large number of independent memories, by
several means, including agressive loop unrolling. Because even LUT
based memories are inheriently serial (due to addressing requirements)
it's sometimes wise to rename array reverences to individual variables
(IE V[0] become V0, V[1] becomes V1, etc) which may easily unroll
several consecutive loops into a single set of LUT terms in a single
reasonable clock cycle time. The choice on this depends heavily on if
the array/variables are feedback terms in the outer C loops (FSM) and
need to be registered anyway.

As I've noted in other discussions about FpgaC coding styles,
pipelining is another counter intuitive strategy that is easily
exploited for FPGA code, by reversing statement order and providiing
addition retiming variables, to break a deep combinatorial code block
up into faster, smaller blocks with the reverse order of updating
creating pipelined FF's in the resulting FSM for the C code loops.

VHDL/Verilog/C all have similar language and variable expression terms,
and can all be compilied with nearly the same functional results. The
difference is that coding FSMs is a natural part of loop construction
with C, and frequently requires considerable care in VHDL/Verilog.
When loops execute in a traditional ISA all kinds of exceptions occur
which cause pipeline flushes, wasted prefetch cycles, branch prediction
stalls, exception processing and other events which prevent fast ISA
machines from reaching even a few percent of best case performance.
These seemingly sequential loops that would intuitively be highly
suited for ISA execution can in fact, actually turn into a very flat
one cycle FSM with some modest recoding that can easily run at a few
hundred MHz in an FPGA, and dozens of cycles in an ISA at a much slower
effective speed.

A large FPGA with roughly a thousand IO pins can keep a dozen 32bit
quad DDR memories in full tilt bandwidth, a significantly higher memory
bandwidth than you can typically get out of a traditional ISA CPU.
Some applications can benifit from this, but I requires that the
primary memory live on the FPGA Accel card, not on the system bus. This
means that the code which manipulates that memory, must all be moved
into the FPGA card, to avoid the bandwidth bottleneck. Like wise some
applications may well need the FPGA to have direct connection to a
couple dozen disk drives, and  network ports, to server wirespeed
network to storage applications, and only use the host CPU for
"exceptions" and "housekeeping".


Article: 101868
Subject: Re: PCI Core compatibility
From: "water7" <krbyxtrm@gmail.com>
Date: 8 May 2006 00:40:23 -0700
Links: << >>  << T >>  << A >>
i guess so, it is on core or in the motherboard,  bec. i have both my
pci board on pentium 3 pc?just not on both amd duron and p4 pc..
one pci board i bought it, other one i made it myself,
i have found that the 'PAR' signal is disconnected from the FPGA in the
pci i bought,
which works on pentium-4 pc... can this be a reason for it not to work
on elitegroup mainboad(with amd duron)?

but it could be timing problems as you say... also when i tried to test
my PCI core on the motherboard that it doesn't work, i can't detect the
'FRAME#' and 'IRDY#' signal, i use external signal analyzer to check
this... why is that so?

-water7

Ayon kay Antti:
> full PCI compliance isnt so easy, some PCI cores that seem to work on
> one system or even one slot of one system may fail on other system or
> even other slot of the same system.
>
> most likely due to small issues with timing. if you are seeing this
> then it eventually calls for long trouble-shooting
> 
> Antti


Article: 101869
Subject: Re: PCI Core compatibility
From: "water7" <krbyxtrm@gmail.com>
Date: 8 May 2006 00:50:36 -0700
Links: << >>  << T >>  << A >>
one more thing to add,
i tested my pci card on its working motherboard via 4-led display,
and for every state it covers one led lights up, so from CONFIG_WRITE,
CONFIG_READ,
IO_READ/MEM_READ/MEM_WRITE it will all light up sequencially, and it
did happen.

But when i put it on the motherboard that it doenst work, not even one
led light up, which mean non of the PCI States was covered except
reset.
(this is a follow up to my post that i tell that with this type of
motherboard i can't detect even the FRAME# and IRDY# signal) .


Ayon kay water7:
> i guess so, it is on core or in the motherboard,  bec. i have both my
> pci board on pentium 3 pc?just not on both amd duron and p4 pc..
> one pci board i bought it, other one i made it myself,
> i have found that the 'PAR' signal is disconnected from the FPGA in the
> pci i bought,
> which works on pentium-4 pc... can this be a reason for it not to work
> on elitegroup mainboad(with amd duron)?
>
> but it could be timing problems as you say... also when i tried to test
> my PCI core on the motherboard that it doesn't work, i can't detect the
> 'FRAME#' and 'IRDY#' signal, i use external signal analyzer to check
> this... why is that so?
>
> -water7
>
> Ayon kay Antti:
> > full PCI compliance isnt so easy, some PCI cores that seem to work on
> > one system or even one slot of one system may fail on other system or
> > even other slot of the same system.
> >
> > most likely due to small issues with timing. if you are seeing this
> > then it eventually calls for long trouble-shooting
> > 
> > Antti


Article: 101870
Subject: Re: Xilinx SelectMAP Question
From: Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk>
Date: Mon, 08 May 2006 09:07:49 +0100
Links: << >>  << T >>  << A >>
Aurelian Lazarut wrote:
> the corect sync word is  0xAA 0x99 0x55 0x66 the docs are correct.
> you need to send the bytes in this order (from left to right)

Fantastic, thanks for the confirmation.

Peter.

Article: 101871
Subject: Strange power up issue on Virtex4
From: "zeeman_be" <zeemanbe@gmail.com>
Date: 8 May 2006 01:36:26 -0700
Links: << >>  << T >>  << A >>
Hi all,

Our PCB is showing a strange start-up/configuration issue.
The board has a virtex4 fpga (xc4vsx35-11) which gives out a DAC-clock,
configured as an LVCMOS33, fast slew rate 24 mA output driver.

Now here's the strange thing : when we configure the device through
JTAG, the clock is ok.
But when we configure it with the SAME bitstream through slave-serial
(as will be the case in the endproduct), the clock-output seems to have
slowed down significantly : slower rise/fall times, voltage swing not
reaching rail-to-rail. Then, when we do a verify through impact it says
verify=succesful, and strangely enough after this verify, our clock
output is ok again.
Note : we use ISE7.1 SP3 on a WinXP machine.

I have checked several scenarios and I am fairly sure this problem has
nothing to do with :
* signal integrity
* power levels during startup/config
* DCM lock issues

Does anyone have any clues where I could search next ? I am running out
of ideas on this. 

Thanks, 
Bart De Zwaef


Article: 101872
Subject: Re: Can an FPGA be operated reliably in a car wheel?
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Mon, 8 May 2006 08:36:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
Andrew FPGA (andrew.newsgroup@gmail.com) wrote:

: Still, the question remains is 100g too much for an FPGA? How much g
: could it take reliably? I know 100g is way too much for a human and I
: know that some MEMS accelerometers spec up to 10,000 g for the absolute
: max rating (measurement up to 250g max I have seen so far).

All I have is a gut feeling that the FPGA will take more gs than the PCB 
it's mounted on?  Also consider the differential forces arising from 
fiting a flat PCB to a curved wheel - different areas are at different 
radial distances...

cds

Article: 101873
Subject: Re: FPGA-based hardware accelerator for PC
From: Adam Megacz <megacz@cs.berkeley.edu>
Date: Mon, 08 May 2006 01:39:24 -0700
Links: << >>  << T >>  << A >>

Andreas Ehliar <ehliar@lysator.liu.se> writes:
> One interesting application for most of the people on this
> newsgroup would be synthesis, place & route and HDL simulation.
> My guess would be that these applications could be heavily
> accelerated by FPGA:s. My second guess that it is far from trivial
> to actually do this :)

Place: http://www.cs.caltech.edu/research/ic/pdf/hwassistsa_fpga2003.pdf
Route: http://www.cs.caltech.edu/research/ic/pdf/fastroute_fpga2003.pdf

  - a    

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Article: 101874
Subject: Re: Can an FPGA be operated reliably in a car wheel?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Mon, 08 May 2006 08:40:50 GMT
Links: << >>  << T >>  << A >>
On 7 May 2006 16:52:31 -0700, "Andrew FPGA" <andrew.newsgroup@gmail.com> wrote:

>What are the maximum g forces an FPGA could operate under?
>E.g. an FPGA sitting in a car wheel, where the car is travelling at 100
>km/hr experiences approx 400g due to the centripetal acceleration.
>(assuming a 15" diameter wheel).
>Can anyone point to products or applications where this is done
>already? (I know tyre pressure sensors are coming..but these are not
>FPGAs)
>
>What would the mass of your typical FPGA package/silicon be? Say a 256
>ball BGA(e.g. FT256 or similar). Force = mass x acceleration so I guess
>you could work out the force on the solder balls etc etc.
>
>I know vibration probably is an issue also - but at least that can be
>mitigated to some extent with the mechanical design of our product
>,e..g vibration damping etc. However, the centripetal force is another
>matter - its always there whenever the wheel is rotating. (and grows
>with the square of the cars velocity).

Let me guess - trying to do something like this perhaps....
http://gizmodo.com/gadgets/gadgets/pimpstar-led-car-rims-162990.php



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