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
Chakra see below in line chakra wrote: > 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 it looks like the PHY managment interface is broken (or the PHY chip worst case) the driver when starts is trying to access the internal registers of the PHY but it seems to fail (this interface is serial of type clk, and a bidirectional data pin MDIO) > 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 here when is trying to mount the /root remotely it can't reach the port for NFS (NFS server running on 192.168.1.5) due to various reasons (network link, PHY chip etc.) > eth0: Could not read PHY control register; err same like the first one. > > Coould anyone please guide me, as to what i am doing wrong, and > possible solution for this error. > Try to debug (hardware) the conetions between the FPGA and PHY, I mean the MDIO (PHY serial mangement interface) and try to det rid of the first error message (very likely will fix the second one) Make sure your *.ucf file matches the fpga pin locations, check against the schematics. > with warm regards, > chakra. > Have fun, AurashArticle: 101876
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). > I take you want to mount the FPGA perpendicular to the rotation axis ? Are you aware that Tin flows ? Under strain, tin flows slowly, over the days. You can see that tin wire moves by itself under gravity. So even if the pbc is able to take the force and the FPGA case takes the strain, the tin won't. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 101877
"JJ" <johnjakson@gmail.com> wrote in message news:1146982987.316600.228410@i39g2000cwa.googlegroups.com... > Alot of good stuff there but not exactly drive by reading. > > So what would you call someone that hasn't pre wiki'ed up on something. > > > If we all went to wikipedia first, we could dissolve the news groups > right? > Hi John, Good points! I sense, rightly or wrongly, you have a little nervousness about Wikipedia, and I share that. Who's to know what motivation someone has had for posting stuff there? I usually use Wikipedia to get a start on what to Google when I'm new to a subject. So, if I had no idea how RFID worked, I'd start at Wikipedia. Then do a few Google searches, and probably end up at somewhere like http://www.rfidinc.com/ and ask questions on sci.electronics.design or maybe alt.privacy. I doubt I'd ask on comp.arch.fpga, even though I know CAF is the only place to be for the world's top digital engineers! :-) As for this newsgroup, the peak level of expertise here is a lot higher than in Wikipedia. If only for that reason, I don't see this newsgroup going away anytime soon. The Wikipedia FPGA article is designed to give the absolute beginner a place to start from. Just MHO! Best, Syms.Article: 101878
Rene Tschaggelar wrote: > I take you want to mount the FPGA perpendicular > to the rotation axis ? Are you aware that Tin > flows ? Under strain, tin flows slowly, over > the days. You can see that tin wire moves by > itself under gravity. So even if the pbc is able > to take the force and the FPGA case takes > the strain, the tin won't. Great post Rene ... in similar ways most other non-crystalized substances which are in fact either elastic or plastic, but we consider "solids" because they seem to hold their shape. http://en.wikipedia.org/wiki/Plasticity_%28physics%29 Note "mild steel" as a plastic :) I'd seriously wonder just how plastic/elastic the doped silicon is and the alum interconnects inside the die as well. at 400G's at lot of things flow that we consider stable solids.Article: 101879
Hi folks, The only imaging chips of that speed (1k frames/s) are CMOS. The easiest way to connect multiple CMOS imaging chips through a large distance is serial LVDS interface. I know that Micron produces one CMOS chip with serial LVDS interface, but framerate is only about 30 FPS. Cheers, GuruArticle: 101880
In article <1147022814.787257.294510@i39g2000cwa.googlegroups.com>, Peter Alfke <alfke@sbcglobal.net> wrote: > >Ron wrote: >> So to multiply two 704 bit numbers >> together (depending upon how it's implemented of course) would require >> roughly sixty 64-bit multiplies and a bunch of adds. ... > >If I remember right, 704 is 11 times 64, so the multiplication would >take 121 of those 64-bit multipliers, not "roughly sixty"... It depends on precise details of the implementation, and you have to write moderately ugly code because the x86 multiply instruction produces its outputs in fixed registers, but if you apply Karatsuba-style techniques enough you can get down to below sixty ... one 12x12 requires six 4x4 + some fiddling, one 4x4 requires three 2x2 + some fiddling, one 2x2 requires four, that's 72, or three + extra fiddling to make 54. However, Karatsuba techniques really work much better on FPGAs where you can do the extra adds in parallel; I don't think you'll gain anything from the three-level decomposition on Opteron. As you might imagine, I would be ecstatic to see a few wide multipliers appearing in FPGAs - a 64x64->128 unit isn't _that_ large an IP block - but the market for number theorists isn't large enough to pay for the masks, and RSA accelerators are produced in enough volume for it to be worth making ASICs. TomArticle: 101881
In article <445f0fe0$1@news1.ethz.ch>, Rene Tschaggelar <none@none.net> wrote: >I take you want to mount the FPGA perpendicular >to the rotation axis ? Are you aware that Tin >flows ? Under strain, tin flows slowly, over >the days. You can see that tin wire moves by >itself under gravity. So even if the pbc is able >to take the force and the FPGA case takes >the strain, the tin won't. I suppose this is because room temperature is near enough to the 231C melting point of tin for elevated-temperature creep to be relevant. On the other hand, I see no mention of tin in the design! TomArticle: 101882
uh, guy - why the hell u wanna brute force rsa with an fpga. there r quite better (faster and cheaper) methods to do so. hope u calculated the throughput and the years/centurys of trying.Article: 101883
fpga_toys@yahoo.com wrote: >Hi Mammo, >I think this would be a great project, and a useful paper to present >for others too. >I'm not sure why Peter is talking about worst case, as Xilinx has >already said the larger parts lack margin to operate at the highest >frequencies with worst case design loads due to power and thermal >issues. Besides the lack of cooling for worst case loads, most boards >also lack the power supply margins too ... and will go unstable at >worst case loading at high clock rates due to dynamic power. Can't this be documented by measureing dynamic current and voltage delivered to fpga. And a ambient and fpga case temperature probe..? The rest should be math and bitpatterns.Article: 101884
Jim Granville schrieb: > Well, I was not actually refering to Xilinx (comprehension?) > - you do seem to be rather Xilinx fixated ? :) Q: Well, what's your opinion on this case, Dr. Freud? A: A clear case of P.., aehhh Xilinx envy! SCNR! ;-) Regards FalkArticle: 101885
Thomas Womack wrote: > In article <445f0fe0$1@news1.ethz.ch>, Rene Tschaggelar <none@none.net> wrote: > > >>I take you want to mount the FPGA perpendicular >>to the rotation axis ? Are you aware that Tin >>flows ? Under strain, tin flows slowly, over >>the days. You can see that tin wire moves by >>itself under gravity. So even if the pbc is able >>to take the force and the FPGA case takes >>the strain, the tin won't. > > I suppose this is because room temperature is near enough to the 231C > melting point of tin for elevated-temperature creep to be relevant. > > On the other hand, I see no mention of tin in the design! There are indeed a few other ways to contact a TQFP or BGA, but none as simple as just solder it onto a pcb. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 101886
"Rene Tschaggelar" <none@none.net> wrote in message news:445f0fe0$1@news1.ethz.ch... > > to the rotation axis ? Are you aware that Tin > flows ? Under strain, tin flows slowly, over > the days. You can see that tin wire moves by > itself under gravity. So even if the pbc is able > to take the force and the FPGA case takes > the strain, the tin won't. > Hmm, I'm suspicious of this! :-) Rene, do you have any references to some data on this. I think most materials have to have a minimum amount of stress before the strain becomes non-reversible or, looking at Antti's wikipedia link, plastic. I wonder what that is for Tin? I think I'm skeptical because of the 'room-temperature-glass-flows-myth'. (No, it doesn't!) Thanks, Syms. p.s. I'll hang a piece of solder off the side of my desk see if it grows!Article: 101887
Are you selecting the programming mode with a dip switch? If so are you sure they are wired correctly and not feeding one of i/o bank voltages or dcio lines or shorted to any other pins? Also, in the past when I had bizarre behavior like this I usually ended up scouring through the options in "Generate Programming File". Sometimes options that seem to be totally unrelated can have major impacts. "zeeman_be" <zeemanbe@gmail.com> wrote in message news:1147077385.999756.220610@u72g2000cwu.googlegroups.com... > 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: 101888
"Symon" <symon_brewer@hotmail.com> wrote in message news:445f2c4d$0$15788$14726298@news.sunsite.dk... > "Rene Tschaggelar" <none@none.net> wrote in message > news:445f0fe0$1@news1.ethz.ch... >> >> to the rotation axis ? Are you aware that Tin >> flows ? Under strain, tin flows slowly, over >> the days. You can see that tin wire moves by >> itself under gravity. So even if the pbc is able >> to take the force and the FPGA case takes >> the strain, the tin won't. >> I've done more research. I think you're claiming that Tin is viscoelastic. See http://en.wikipedia.org/wiki/Viscoelastic However, on the UK's National Physical Laboratory, I found this link. http://www.kayelaby.npl.co.uk/general_physics/2_2/2_2_2.html This says Tin is an isotropic material with a tensile strength of 20-35 MPa, and a Young's modulus of 49.9 GPa. No mention of it being viscoeleastic. What do you think? Cheers, Syms.Article: 101889
In article <445f2d54$1@news1.ethz.ch>, Rene Tschaggelar <none@none.net> wrote: >Thomas Womack wrote: >> In article <445f0fe0$1@news1.ethz.ch>, Rene Tschaggelar <none@none.net> wrote: >> >> >>>Are you aware that Tin >>>flows ? >> I suppose this is because room temperature is near enough to the 231C >> melting point of tin for elevated-temperature creep to be relevant. >> On the other hand, I see no mention of tin in the design! > There are indeed a few other ways to contact a TQFP or BGA, but none > as simple as just solder it onto a pcb. Ah, is this an issue with the new lead-free solders? I knew pure tin crept, but I wasn't aware that solders did. TomArticle: 101890
Hi Anonymous, the programming mode is selected with strap-resistors. I have checked these and I am sure these are fine. This is a board we have been using for more than 6 months now, we haven't seen any real issues on completing the configuration phase (doen pin goes high), except for now where it seems that right after configuration something strange happens when the FPGA starts up with our bitstream. I will follow your suggestion and try looking into the different bitgen options now and hope for the best :-) best regards, Bart De ZwaefArticle: 101891
...and this paper talks about the elastic limit of Tin, so I guess it has one! http://www.national.com/packaging/files/Synchrotron_Nguyen.pdf I found this:- http://en.wikipedia.org/wiki/Yield_stress and on this page http://en.wikipedia.org/wiki/Tensile_strength we find that Tin has a yield stress of 9-14 MPa. So, it's a simple calculation to work out if the tin solder is gonna be strong enough not to creep. This experiment, "The creep of solder", from Cambridge university may be of interest. http://www.msm.cam.ac.uk/phase-trans/2004/creep.practical.pdf Anyway, my place & route has finished, so back to proper work!! :-) HTH, Syms.Article: 101892
> the PPC errata in V2Pro/V4 exist, but for real issues there are either > patches already or they are not relevant in most design Well they obviously do exist, if you call not using cache copyback mode a "patch". This is a major feature of the PPC processors, not having it (having all pages in write-through or cache-inhibited mode) means slowing the CPU a lot, probably several times. Like I wrote before, every single memory write will burst 32 bytes to memory; if this is a 100 MHz SDRAM this will take > 120 nS instead of a single CPU clock cycle - which will typically be below 5 nS. Not that this makes the part unusable, of course - 120 nS per write is still a lot faster than many MCUs which are still in production, it just does not live up to what a PPC processor is about. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Antti wrote: > 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: 101893
On a sunny day (Mon, 8 May 2006 13:49:53 +0100) it happened "Symon" <symon_brewer@hotmail.com> wrote in <445f3dff$0$15792$14726298@news.sunsite.dk>: >This experiment, "The creep of solder", from Cambridge university may be of >interest. >http://www.msm.cam.ac.uk/phase-trans/2004/creep.practical.pdf :-) Yes we know that.Article: 101894
Symon wrote: > I think I'm skeptical because of the 'room-temperature-glass-flows-myth'. > (No, it doesn't!) Shame. Glass flows. You just don't "see" it flow so that makes it a myth for you? The plate glass in the Notre Dame cathedral has measurable differences in thickness from the top to the bottom as just one simple example.Article: 101895
Symon wrote: > "Symon" <symon_brewer@hotmail.com> wrote in message > news:445f2c4d$0$15788$14726298@news.sunsite.dk... > >>"Rene Tschaggelar" <none@none.net> wrote in message >>news:445f0fe0$1@news1.ethz.ch... >> >>>to the rotation axis ? Are you aware that Tin >>>flows ? Under strain, tin flows slowly, over >>>the days. You can see that tin wire moves by >>>itself under gravity. So even if the pbc is able >>>to take the force and the FPGA case takes >>>the strain, the tin won't. >>> > > I've done more research. I think you're claiming that Tin is viscoelastic. > See http://en.wikipedia.org/wiki/Viscoelastic > > However, on the UK's National Physical Laboratory, I found this link. > > http://www.kayelaby.npl.co.uk/general_physics/2_2/2_2_2.html > > This says Tin is an isotropic material with a tensile strength of 20-35 MPa, > and a Young's modulus of 49.9 GPa. No mention of it being viscoeleastic. > > What do you think? I know it is viscoelastic. Try to mount a tin (solder) wire of arbitrary length horizontal on one end. It'll bend down rather quick. The older lead-tin wire was quick in this respect, a matter of a few hours. The new leadfree takes a lot longer, possibly weeks. Another indicator is that you never(!) put a tinned copper wire into a screw terminal. It'll lead to a failure over time (years). The solder creeps under the pressure and the contact becomes worse, the contact resistance becomes higher and thus in a high current application, the contact becomes warmer over time until the contact fails. Thus, always use untinned wire in a screw terminal. ReneArticle: 101896
Dear All, Can anybody tell me what I have to do to install the BFM toolkit? When I follow the link "BFM Toolkit Installation Instructions" in the step 7 of XPS's Create and Import Peripheral Wizard, I arrive to this age http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=dr_pcentral_coreconnect but I don't know what to do next. Do I have to pay for it? Tanks jmArticle: 101897
Bart, did you change the startup clk (option in bitgen) for the two bitstreams , you mentioned "SAME" bitstream that's why I'm asking (they supposed to be different) when you said "slave-serial (as will be in your end product)" I hope you meant master-serial (unless you are using an external controller or micro to push the bitstream) so please clarify this point. at the first glance it looks like the part doesn't finish the config process as it should. what about the DONE pin? Aurash zeeman_be wrote: > 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: 101898
"John_H" <johnhandwork@mail.com> wrote in message news:JpH7g.4786$k%2.1985@trnddc03... > Symon wrote: >> I think I'm skeptical because of the 'room-temperature-glass-flows-myth'. >> (No, it doesn't!) > > Shame. Glass flows. You just don't "see" it flow so that makes it a myth > for you? The plate glass in the Notre Dame cathedral has measurable > differences in thickness from the top to the bottom as just one simple > example. Nope, in olden days making glass windows was tricky. The thickness across the sheet wasn't constant. When they originally fitted the panes into the frames, they fitted the thick bit at the bottom. Cheers, Syms. p.s. Interestingly enough, given what we're talking about, modern window glass is made on top of a pool of molten tin! Google for "Pillington Process".Article: 101899
"Rene Tschaggelar" <none@none.net> wrote in message news:445f462d$1@news1.ethz.ch... > > I know it is viscoelastic. Try to mount a tin > (solder) wire of arbitrary length horizontal > on one end. It'll bend down rather quick. > The older lead-tin wire was quick in this > respect, a matter of a few hours. The new > leadfree takes a lot longer, possibly weeks. > I don't think Tin is viscoelastic. My point is that tin (and other materials) only have this plastic deformation above the yield stress limit. A thin wire stuck out horizontally has a lot of stress. A thick bar of tin isn't going to droop no matter how long you wait. Otherwise solder wire left on the desk would flatten out on its own. The confusion is that Tin and Solder have very low limits compared to other metals, and so it's easy to think the tin flows all the way down to zero stress as it's floppy by comparison with other metals. As you say, different materials have different yield stress limits, and maybe new solder materials have higher limits. The point is that you can work out how much stress the metal can take before it starts to go plastic. And screwing into a terminal block will be above that limit unless you're careful with the screwdriver! :-) Although I suspect the dissimlar metals in a terminal block is a major reason for failure. Cheers, Syms. p.s. Anyone at University wanna pop down to the material science department as ask this question? Is Tin viscoelastic?
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