Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
>...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
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: 101852Alan 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 NishiokaArticle: 101853
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
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 ? :) -jgArticle: 101855
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! kingArticle: 101856
> 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
Hey people, Thanks for all the suggestions... will keep you guys posted. Best, mammoArticle: 101858
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, XilinxArticle: 101859
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
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
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
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: 101863full 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 AnttiArticle: 101864
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.) /AndreasArticle: 101865
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 :) /AndreasArticle: 101866
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 AnttiArticle: 101867
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
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 > > AnttiArticle: 101869
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 > > > > AnttiArticle: 101870
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
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 ZwaefArticle: 101872
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... cdsArticle: 101873
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 C380Article: 101874
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:
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