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
Sorry! I found the error. The error is not related to what I have thought, it relates to situation: std_logic => A(I), In a generate loop as following: Lable_A : for I in 0 to 3 generate ... port map ( ... A => A(I), ... ); A() must be declared as signal A : unsigned(3 downto 0); And it cannot be decleared as signal A : unsigned(1 downto 0); <-- my error Thank you. WengArticle: 101826
Or does '0' turn the LED on? "Jep" <Laurent.George@gmail.com> wrote in message news:1146997489.503620.68120@g10g2000cwb.googlegroups.com... >I have a little problem with flashing a led. > > I want flash a led for indicating the status of my program. > > I do the following: > > LED1 <= '1', '0' after 200 us; > > But it burn all the time. > > Do you have a solution? ( wthout counters) >Article: 101827
With respect to connecting multiple boards, the XUPV2P "Using High Speed Serial MGTs with the Aurora IP" Quickstart provides a good infrastructure so the developer can focus on the partition itself. Paul c d saunter wrote: > > Ron, > Perhaps you could partner with a local university and form an > undergraduate project based on this? I say this because universities > have access to this rather nice board at an affordable price... > > http://www.xilinx.com/univ/xupv2p.html > > Unless you could shrink the design you'd need to join several boards... > > Cheers > cdsArticle: 101828
Jep wrote:
> LED1 <= '1', '0' after 200 us;
^^^^^^^^^^^^^^^^
This is not supported by synthesis.
> But it burn all the time.
... because the 2nd part of the code line is ignored.
> Do you have a solution? ( wthout counters)
Whats wrong with counters?
Ralf
Article: 101829Ron 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"... I am glad we got away from the obscenities, and now deal with basic math... Peter AlfkeArticle: 101830
Piotr Wyderski wrote: snipping > > If the 32 bit RISC was optimized for some specialized task, then it > > might make sense to have it alongside a high-performance CPU. > > No, because in this case you are trying to outperform an out-of-order, > highly parallel processor core able to complete ~6 simple instructions > per cycle and clocked at 2+ GHz. Reasonable soft CPU cores run at > about 200 MHz and complete only one instruction per cycle. It > means that a cheap CPU you can buy anywhere has about 60 times > higher performance in sequential processing. Even if you could provide > the same performance (not to mention about outperforming it, which > is the key idea, anyway), it would mean that you are at least Harry Potter. > :-) > I have fantastic disbelief about that 6 ops /clock except in very specific circumstances perhaps in a video codec using MMX/SSE etc where those units really do the equiv of many tiny integer codes per cycle on 4 or more parallel 8 bit DSP values. Now thats looking pretty much like what FPGA DSP can do pretty trivially except for the clock ratio 2GHz v 150MHz. I look at my C code (compilers, GUI development, databases, simulators etc) and some of the the critical output assembler and then time some parts on huge 1M timed loops making sure no iteration benefits from cacheing the previous run. I always see a tiny fraction of that ~6 ops/cycle. SInce my code is most definitely not vector code or media codec but is a mix of graph or tree traversal over large uncacheable spans, I often see avg rates exactly 1 op per clock on Athlon TB at 1GHz and also XP2400 at 2GHz. My conclusion is that the claims for wicked performance are mostly super hype that most punters accept all too easily. The truth of the matter is that Athlon XPs rated at say 2400 are not 2.4 x faster than TB at 1GHz in avg cases, maybe on vector codecs. When I compare WIndows apps for different cpus, I usually only see the faster cpu performing closer to sqr of its claimed speedup. A while back, Toms Hardware did a comparison of 3GHz P4s v the P100 1st pentium and all the in betweens and the plot was basically linear and thats on stupid benchmarks that don't reflect real world code. One has to bear in mind the P4 not only used 30x the clock to get 30x the benchmark performance, it also used perhaps 100x the transistor count as well and that is all due to the Memory Wall and the necessiity to avoid at all costs accessing DRAM. Now if we did that on an FPGA benchmark we would be damned to hell, one should count the clock ratio and the gate or LUT ratio but PCs have gotten away with using infinite transistor budgets to make claims. This makes sense to me since the instruction rate is still bound by real memory accesses to DRAM some percent of the time for cache misses, I figure around 2% typical or even more. DRAM has improved miserably over 20yrs in true random access about 2x from 120ns to 60ns Ras to Dout time. If you use cache misses close to 0.1% then you get the hyped nos, but code doesn't work like that atleast mine doesn't. Try running a random number generator say R250 which can generate a new rand number every 3ns on a XP2400 (9 ops IIRC). Now use that no to address a table >> 4MB. All of a sudden my 12Gops Athlon is running at 3MHz ie every memory access takes 300ns or so since every part of the memory system is wreaked (deliberately in this case). Ironically if thats all you wanted to do, an FPOA cpu without complex MMU, TLBs could generate random numbers in 1 cycle and drive an SDRAM controller just as fast if not faster since SDRAMs can cyle fully random closer to 60ns. Now in packet switching and processing where large tables are looked up with random looking fields, they use RLDRAM to get SRAM like performance. So what does real code look like, any old mixture of the 2 extremes, ie sometimes its memory crippled, sometimes if everything is in L1 cache, it really does seem to do 2 ops/clock if array accesses are spread out, even with small forward branches. So all the complexity of these OoO machines is there to push up the avg rate and keep it just above 1 for typical integer codes, more for specially tuned codes. Each FP code used though is equivalent to a large no of ops on an integer only cpu, but then I rarely use FP except for reporting averages. So on an FPGA cpu, without OoO, no Branch prediction, and with tiny caches, I would expect to see only abouit .6 to .8 ops/cycle and without caches, a fraction of that. So that leaves the real speed difference much closer, maybe 10-20 to 1 for integer codes, but orders more for FP codes. For an integer only problem where some of the code can be turned into specialized instructions as in your applications list, the FPGA cpu is more transparent and possibly a more even match if replicated enough, but still it is dificult even to get parity and writing HDL is much harder than plain C. I have no experience with the Opterons yet, I have heard they might be 10x faster than my old 1GHx TB but I remain skeptical based on past experience. On the Harry Potter theme, I have suggested that an FPGA Transputer cpu that solves the Memory Wall by trading it for a Thread Wall using latency hiding MTA cpu AND esp latency hiding MTA RLDRAM can be a more serious competitor to conventional OoO BP, SS designs that continue to flog regular SDRAMs. In that sort of design a 10 PE + 1 MMU Transputer node setup with RLDRAM can match 1000 Mips since each PE is only 100Mips but you have to deal with 40 threads with almost no Memory Wall effect, ie a Thread Wall. Since the PEs are quite cheap, the limit on FPGAs is really how many MMUs can be placed on a FPGA for max Memory throughput and that seems to be a pin & special clocks limit rather than core limit. Perhaps using spare BlockRams as an L1 RLDRAM intermediate, one could get many more busy cpus inside the FPGA sharing the RLDRAM bandwidth on L1 misses. > > More interested in prototyping some RISC centric soft-IP designs. > > You can do this using existing development boards. > > Best regards > Piotr Wyderski regards John Jakson transputer guy (paper at wotug.org)Article: 101831
Peter Alfke wrote: > If I remember right, 704 is 11 times 64, so the multiplication would > take 121 of those 64-bit multipliers, not "roughly sixty"... My comment was to Thomas Womack, not to you dimwit. If you had half a brain you would realize that it's not necessary to do 121 multiplies because the upper and lower halves of the multiplication matrix above and beneath the diagonal are symmetric. Please do not respond to comments (it wasn't a question, BTW) that you don't understand. > > I am glad we got away from the obscenities, and now deal with basic > math... > Peter Alfke And you obviously need to take some remedial math courses Peter. I have plenty more of what you call "obscenities" for you Xilinx scumbags who use this forum to spread FUD and peddle your overpriced goods. Admittedly I made the mistake of asking for a hobbyist discount on your obscenely priced software design tools when I started this thread, but now that I know what despicable cretins you are, I would appreciate it if in the future you and the other Xilinx creeps would KEEP OUT of the Usenet discussion threads I initiate. Thank you, RonArticle: 101832
Thanks for the education. I am always eager to learn. Peter AlfkeArticle: 101833
Ron - I've seen a lot more valuable input on this newsgroup from Peter and Austin then from you. If you don't want to read comments from the Xilinx folks, then don't. Let the rest of us decide what we want to read and whose opinions we value. As much as I dislike some of the thing Xilinx does, or as much as I gripe about their software, their contributions to this newsgroup are a lot more useful than your rants. Name calling adds nothing to any discussion in this forum. John ProvidenzaArticle: 101834
Thanks for all your support. I do it now with counters, and it works :-)Article: 101835
johnp wrote: > Name calling adds nothing to any discussion in this forum. The Xilinx employees have gone out of their way not to play nice in other discussions reciently, one really has to expect that they set the tone in how they want to be addressed and treated, by how they treat others. Addmittedly Ron is a bit over the top and direct, but so are Austin, Peter, and a few other Xilinx folks that bash others in this forum regularly. Austin's FUD regarding Grey Market parts hurts Xilinx customers that end up with excess inventory, and the companies that resell or build product using it. Certainly there is conterfeiting fraud of Xilinx parts, just as there is in every industry, including jeans. But the reality is that the main stream Xilinx distributors will not give small businesses the time of day, much less hobbiests. The couple that do, will not stock a full line, and ask for minimum qty purchases on the rest with long lead times that exceed their requirements. Reputable Gray Market sources are a critical resource for hobbiests and small companies, and the FUD just isn't necessary or warranted. Xilinx's "choice" to not support this secondary market is about as helpful as a car dealership unwilling to accept factory warranty service on cars they did not directly sell or lease. 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. When Xilinx refuses to open up enough to allow third parties to provide competitive design software tools, including open source alternatives, then being bashed for the high costs of their software is fair game. Especially when they don't play nice with other folks in this forum. And openly disrespect any project that doesn't have a billion dollar ROI. The size limit of the free web software, also greatly limits what end user boards can be built in volume for this market. Since the high cost of Xilinx tools cuts the market size for boards with larger parts dramatically, so does it drive up the cost of boards ith larger parts because of reduced volume. As I've noted before, this also kills the reconfigurable computing market, with a Xilinx "tax" to use that board each year by paying the high annual subscription costs just to write new software requiring the place, route and bit stream tools. When Xilinx either releases the bit stream generation specifications for their parts, or includes full product line support for place, route and bitstream generation in the free tools, the reasons for bashing them for their software costs will mostly go away. Till then Xilinx can continue it's FUD regarding second and third teir companies that feed off the Gray Market, crow about the High Margins as a measure of success .... and eat crow from hobbiests and smaller businesses about the high costs and lack of support. >From my perspective, it would be better if Xilinx dealt with the fraud issues independently of cutting off support to compaies that need the Gray Market. It would be a lot better if the tools cost issues where removed and open up the market for boards with larger parts, and third party software. If would be much better, if Xilinx employees didn't bash others here either. JohnArticle: 101836
Hi all, I am trying to do a novel kind of experiment using a spartan II FPGA. I want to measure the impedence profile (spectrum) of the Vdd and ground planes on the FPGA. To do that, I am planning to do the following (a) fill up the FPGA with a lot of synchronous logic (b) clock it at different frequencies (c) measure the voltage and current consumed at every frequency. To make the measurements independent of the program running on the FPGA, I am planning to hold all the logic on the FPGA in the reset state. Right now, I am planning to implement a few Picoblaze cores on my 50k gate spartan II . (each picoblaze roughly takes up 9% of the slices), tie them up and implement some test logic on the FPGA. I am basically using the forum as a sounding board for my idea. Any suggestions on what cores I should implement for maximum sensitivity ? Is picoblaze a good idea ? Thanks MammoArticle: 101837
For a worst-case look, I would implementa maximum-lemgth shift register and toggle its front end. Driven by a global clock,this generates the maximum amplitude of synchronous spikes on the Vcc distribution. Anything more realistic would spread out the spikes, thus lowering the amplitude. I suppose you know how to access the internal Vcc and Vdd levels, and bring them to the outside. My question is: What do you want to prove or disprove? Peter Alfke, from home.Article: 101838
mammo wrote: > Hi all, > > I am trying to do a novel kind of experiment using a spartan II FPGA. I > want to measure the impedence profile (spectrum) of the Vdd and ground > planes on the FPGA. To do that, I am planning to do the following > (a) fill up the FPGA with a lot of synchronous logic > (b) clock it at different frequencies > (c) measure the voltage and current consumed at every frequency. > > To make the measurements independent of the program running on the > FPGA, I am planning to hold all the logic on the FPGA in the reset > state. this bit has me lost, how can you use a picoblaze in the reset state ? > Right now, I am planning to implement a few Picoblaze cores on my 50k > gate spartan II . (each picoblaze roughly takes up 9% of the slices), > tie them up and implement some test logic on the FPGA. > > I am basically using the forum as a sounding board for my idea. Any > suggestions on what cores I should implement for maximum sensitivity ? > Is picoblaze a good idea ? yes, it is widely known, and is a more typical usage of PFGA, You could also implement a 'sea of 32 bit CE counters', which can be usefull to calibrate and verify your system - that is a pattern that should not overheat the FPGA, but will give a stable spectrum. Enable/disable of the ClockEnable, would also give results for the clock tree and (plus) the logic fabric. -jgArticle: 101839
Peter, >My question is: What do you want to prove or disprove? Thanks for your suggestion. This is essentially a curiosity driven experiment. We saw a paper in the Intel Technology journal , where they had such impledence measurements for the P4 processor. We were wondering if we could reproduce those measurements in our lab, and decided to start with FPGAs rather than processors as a first baby step. The paper is located at: http://www.intel.com/technology/itj/2005/volume09issue04/art02_powerdelivery/p01_abstract.htm Also, just checking if I understand you right : are you suggesting that I implement one huge shift register, and then just push a 10101... pattern through it ? it seems like a good idea. Jim, >> To make the measurements independent of the program running on the >> FPGA, I am planning to hold all the logic on the FPGA in the reset >> state. > >this bit has me lost, how can you use a picoblaze in the reset state ? Since I donot really want to do any real computations using the Picoblaze, i think its okay to hold it in the reset state. I just want to clock it at different frequencies and see what happens on the power delivery network Thanks for your suggestion about the clock enable. It makes a lot of sense. Regards, mammoArticle: 101840
Ron wrote: <rant filter on> > Peter Alfke wrote: > >> If I remember right, 704 is 11 times 64, so the multiplication would >> take 121 of those 64-bit multipliers, not "roughly sixty"... > > > My comment was to Thomas Womack. It's not necessary to do 121 multiplies > because the upper and lower halves of the multiplication matrix above > and beneath the diagonal are symmetric. > >> >> I am glad we got away from the obscenities, and now deal with basic >> math... >> Peter Alfke <rant filter off> Feeling better now Ron ? First you started asking for help : "...to work out a deal with the FPGA vendor or someone to lend me the necessary development board and s/w tools in exchange for the potential fame and glory, since I am but a humble retired engineer/hobbyist." then you later add this: "..also a $30,000 reward for factoring RSA-704.." 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 ? or will you donate that to a local school ? 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. -jgArticle: 101841
Jim Granville wrote: > 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. And a lot of potential, or possibly soon to be EX, customers.Article: 101842
Correction, before anybody points out my error: The long checkerboard shift register is a popular way to measure power consumption, but it is actually very benign with respect to Vcc spikes, since half the loads go Low and half go High, nicely compensting each other. The tougher test is to switch every bit in synchronism, from Low to High on one clock, and from High to Low on the next, etc. Needs a line to drive all D inputs together, and this line being toggled. This is of course not a realistic test, and it may show real ugly results. But I think that's what you were after... Sorry for the misleading previous posting. Peter Alfke, Xilinx (from home)Article: 101843
mammo wrote: > Jim, > >>>To make the measurements independent of the program running on the >>>FPGA, I am planning to hold all the logic on the FPGA in the reset >>>state. >> >>this bit has me lost, how can you use a picoblaze in the reset state ? > > > Since I donot really want to do any real computations using the > Picoblaze, i think its okay to hold it in the reset state. I just want > to clock it at different frequencies and see what happens on the power > delivery network > > Thanks for your suggestion about the clock enable. It makes a lot of > sense. There are two portions of clock consumption, one is the clock network itself, and the other is the Nodes/Fabric that toggle. Not all data makes that distinction. So Peter's more agressive test of a 101010 shift register will have two power levels, depending on the ClockEnable. Wide counters have a more typical logic % usage. If you Pinmap, and add an OE term, you can also get the IO fabric power values. The separate supplies on FPGA makes probe of the internal power rails more difficult. -jgArticle: 101844
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. It would be nice (and I've asked for this before with very negative responses) that Xilinx openly document the dynamic power and thermal limits. As a side note, this problem is partially mitigated by clock skew as the parts get larger, but that doesn't help realize designing for worst case loading, or even having a clue to predict why one placement works and another fails, when the skew stacks up worst case in your design. Have fun!! ... and I look forward to your results :) John mammo wrote: > Hi all, > > I am trying to do a novel kind of experiment using a spartan II FPGA. I > want to measure the impedence profile (spectrum) of the Vdd and ground > planes on the FPGA. To do that, I am planning to do the following > (a) fill up the FPGA with a lot of synchronous logic > (b) clock it at different frequencies > (c) measure the voltage and current consumed at every frequency. > > To make the measurements independent of the program running on the > FPGA, I am planning to hold all the logic on the FPGA in the reset > state. > > Right now, I am planning to implement a few Picoblaze cores on my 50k > gate spartan II . (each picoblaze roughly takes up 9% of the slices), > tie them up and implement some test logic on the FPGA. > > I am basically using the forum as a sounding board for my idea. Any > suggestions on what cores I should implement for maximum sensitivity ? > Is picoblaze a good idea ? > > Thanks > MammoArticle: 101845
Peter Alfke wrote: > Correction, before anybody points out my error: > The long checkerboard shift register is a popular way to measure power > consumption, but it is actually very benign with respect to Vcc spikes, > since half the loads go Low and half go High, nicely compensting each > other. > The tougher test is to switch every bit in synchronism, from Low to > High on one clock, and from High to Low on the next, etc. > Needs a line to drive all D inputs together, and this line being > toggled. > This is of course not a realistic test, and it may show real ugly > results. > But I think that's what you were after... > Sorry for the misleading previous posting. > Peter Alfke, Xilinx (from home) To implement both would be a good idea. That way, you have two tests with similar node-toggle rates, but different Icc profiles. Another would be to configure (tiled) half the device as PosEdge and half as NegEdge, as that shifts the fabric currents. (but not the Clock-tree currents ). -jgArticle: 101846
johnp wrote: > Name calling adds nothing > to any discussion in this forum. On the contrary, it will hopefully keep them OUT of any discussion threads I may initiate in the future. RonArticle: 101847
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).Article: 101848
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. 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). For that matter, I'd be willing to send someone who already possesses the necessary hardware and software, a copy of the bitstream file so that they could run it themselves on their own hardware. Eventually I'll probably open a SourceForge.com project for it and open source my work, but I'd rather wait until my project comes to fruition first. > 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. At least they could have done so politely without being condescending and rude as though I were some snotty nose kid who hasn't a clue. I wonder what they think I was doing during my 35 year career as an engineer? I am generally very respectful to those who also show me some respect. For that reason, I can't believe Xilinx let those jerks out of their cages without a leash. "Back in the day" a salesman would never even let an applications engineer visit a customer unaccompanied for fear they would alienate the customer. Now I can see why. RonArticle: 101849
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... 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...) 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... 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. Peter Alfke
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