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
In article <4205FE3C.AE4D86E2@earthlink.net>, Robert Baer wrote: > "Gary J. Tait" wrote: > > > > On Sat, 05 Feb 2005 14:23:50 GMT, Robert Baer > > <robertbaer@earthlink.net> wrote: > > > > > > > > France?? > > > > No Canada, where ATI and Matrox hail from. > > I understood that. > However, when one hears French over the phone on such a call, it is > possible that the help desk could also be in France...or in parts of > Africa (theoretically). And no US citizens speak french, and happen to work at a call centre in the states? In today's world, it helps not to have any notions about where you are getting service from. Wheater state, or country, or even company. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 78701
Hi Peter, > There are three ingredients to this "surprise": All are reasonable comments/questions which I will address below. But let's first step away from Altera's direct Stratix II to Virtex-4 result, and like good engineers sanity check the +39% number by trying to compare things another way. Virtex-4 vs. Virtex II-Pro is around 5% faster (I don't have the exact result on hand). Whatever perceived bias there may be, this is the result we get when we run those two chips head-to-head, using the same designs, same software, and same methodology. And we've heard this from Xilinx users who have been surprised at the lack of performance increase when comparing the two chips. There have been postings on this subject in this very newsgroup. Yes, some IP blocks have got faster, and there have been changes to various aspects of the chip, but the basic logic + routing fabric really hasn't improved much. As an architect, I am not surprised at the lack of performance increase. Nothing has changed in V-4 on the logic or routing front vs. VIIpro that would lead to speed. The stripping of SRL16s from the M slices should lead only to some area reduction. And going to 90 nm from 130 nm doesn't automatically confer a speed advantage, since this depends on choices of exactly where you target the process, what gate lengths you use, what threshold voltages you use (and where), and even things like using slow thick-oxide transistors. As an example of this, moving from Cyclone (130 nm) to Cyclone II (90 nm), we're only seeing somewhere in the neighbourhood of a 10% performance advantage. Contrast this to Stratix II. Stratix II is 45-50% faster than Stratix. Again, same designs, same methodology, same tools. Perhaps we cannot be trusted to run Xilinx tools fairly, but we had better know how to run our own tools and chips. Why are we seeing this much advantage? A small part comes from process. But most of it is as a result of the new logic architecture -- to first order, larger LUTs mean fewer logic levels with roughly equivalent delay per level, thus faster overall performance. And there are numerous other changes under-the-hood relating to the routing architecture and electrical design that lead to further performance improvements. If we had not innovated, we also would have been left with a product that was not much faster than its predecessor. So is a performance advantage in the 39% range that difficult to believe? Well, unless you think that Virtex II Pro was way faster than Stratix (numerous head-to-head battles in the field do not support this), a big advantage for Stratix II is reasonable to expect. > 1. Altera used its fastest (of three) speed grade against the middle of > three Xilinx speed grades. I guess you could say that's the marketing of our results. The science behind the +39% is valid -- we clearly state what we are comparing to and why we are comparing that way. And from a customer (today) perspective, that is what they would see too. There are no speed files for -12 and no entries in the data sheet. Assuming your fastest speed grade (whenever it finally comes out) is 10-15% faster than the middle speed grade, we'll still be talking about a ~25-30% advantage for Stratix II. > 2. Altera did not exercise the Xilinx software as strongly as they > pushed their own. The software tools are quite different, and require a > different approach if absolute highest speed is the goal. Which it was. I disagree. We spent months trying the default settings, the best settings, and every combination of settings we could in order to maximize the performance of designs run on ISE. The performance of ISE is difficult to compare against, since it tends to do a crappy job when over-constrained or under-constrained. This means we have to spend a lot of time finding just the right set of constraints to determine the best (per-domain) performance. To get a result for a Virtex-4 design, we run the tool ~15 times on average in order to find the best constraints for that design. Please publicly post the best-effort methodology you would like us (and your customers) to employ, or be more specific about what about our approach leads to a tool bias. I would be happy to discuss the merits of various benchmarking approachs. > 3. It is reasonable to assume that Altera's stored designs are more > Stratix-friendly. I'll agree that there *could* be some unintentional bias here. Its tricky -- a lot of our benchmark designs come from customers who engage with us because they are having troubles, sometimes with meeting performance. This may be on an older chip (say, APEX) or it may be that they were having tool issues. What this means is part of our benchmark set comprises designs that *did not* do well on our chips. Some of our designs are targetted originally at Xilinx devices and we've been called in to try to hit performance in an Altera part because the customer was having availability issues. And yes, some of our designs are just plain old design-to-Stratix designs. So its a bit of a mess to try to decipher whether or not we have a bias based on the benchmark set... One point I would make is that Stratix II's logic architecture is radically different from Stratix's. So even if we had a bias towards Stratix designs, I'm not sure that would mean we should automatically see an advantage for Stratix II vs. Virtex-4 since in many ways Virtex-4 and Stratix are more similar than is Stratix II to either architecture. > So, don't you guys play the surprised innocent onlookers. Nobody > expected Altera to be fair. I don't think I've ever expressed surprise at the response. I sometimes wonder whether we should have screwed being fair and instead just posted totally unfair results like +60% or +70%, or to take a page from Xilinx's books, "up to +230%" so that once people de-rate for assumed unfairness, they'd end up somewhere near the right result. > Hell, I think the whole business of competitive benchmarks being run > and promoted by an interested party is a sham and a disgusting > deception. That's why I refused to enter the mudbath... And Xilinx has never dared to make any performance claims in the past? At least our +39% result is a step forward in that we are using averages (real, geometric averages with a full data set) and not "up to" numbers, and we are posting details on our methodology, and are doing our best not to stack the deck. Regards, Paul Leventis Altera Corp.Article: 78702
Hi Rick, > Correct me if I am wrong, but didn't Altera use the most current speed > file data that was available at the time? Or was the data available in > the speed file and just the parts are not available? Lets face it. You are correct. No speed files are available for -12. No numbers are in the datasheet. So we compare to -11. > Even if the speed file data was available, data based on estimates is > pretty pointless. We have seen significant changes in speed files even > *after* a chip is in production. So the data is pretty meaningless > *before* the parts are in production. I think performance comparisons based on preliminary timing models are still valid. Regardless of how correct speed files are, that is the performance a customer will see, and is what customers are using to select devices and speed grades. Of course, performance comparisons need to be updated with each release of speed files (and cad software too -- algorithms are always improving). I cannot speak for Xilinx and their speed files. But on the Altera side of things, I would not expect much change in core performance. For all families I've been involved with (Stratix, Cyclone, and beyond), our core performance predictions made in the preliminary timing models have been very close (within 5%) of final production numbers. Stratix II core (logic + routing) speed will not be changing more than a few % in the future. Our models have already been correlated to silicon and compare very well. The toggle rate limitations on DSP and memory blocks will likely increase (again) since we're still in the process of finishing off our characterization of these blocks and we like to stick with conservative limits until that characterization is completed. Regards, Paul Leventis Altera Corp.Article: 78703
Hello
I have implemented an multiplier in the following way: I always take 4 bits
of my first operand and multiply it with the second operand. So in every
step I generate 4 partial products which have to be added. This sum is
stored in the accumulator. In the next clock cycle I take the next 4 bits,
multiply it with the second operand, sum up the partial products and add
this to my accumulator. This is performed a few times until I have processed
all the bits of operand one. Then my result is stored in the accu.
My implementation works fine but when I synthesize it I get a lot of
"warnings", can somebody tell me what went wrong here?
Mapping all equations...
Building and optimizing final netlist ...
Register outp_0 equivalent to accu1_8 has been removed
Register outp_1 equivalent to accu1_9 has been removed
Register outp_2 equivalent to accu1_10 has been removed
Register outp_3 equivalent to accu1_11 has been removed
Register outp_4 equivalent to accu1_12 has been removed
Register outp_5 equivalent to accu1_13 has been removed
Register outp_6 equivalent to accu1_14 has been removed
Register outp_7 equivalent to accu1_15 has been removed
Register outp_8 equivalent to accu1_16 has been removed
Register outp_9 equivalent to accu1_17 has been removed
and so on...
The code for accu1 and outp looks the following:
if rst = '1' then
op1 <= (others => '0');
op2 <= (others => '0');
outp <= (others => '0');
accu1 <= (others => '0');
elsif clk'event and clk = '1' then
if load = '1' then
op1 <= inp0;
op2 <= inp1;
end if;
if shift = '1' then
op2 <= op2((2*width-10 downto 0) & (7 downto 0 => '0');
end if;
if acc = '1' then
accu1 <= accu((2*width-1) downto 0) & (7 downto 0 => '0');
outp<= "00" & accu((2*width-3) downto 0);
end if;
end if;
end process;
accu represents always the newest Accumulator value. Hope somebody can
explain me how to get rid of all these warnings
Cheers
Philipp
Article: 78704dear all I encountered tremendous of warning messages (2 types). First type is ------------------------------------------------------------------------------ WARNING:NgdBuild:454 - logical net 'microblaze_0/Trace_Instr_EX<30>' has no load ------------------------------------------------------------------------------ In xilnx answer browser, ------------------------------------------------------------------------------ This warning indicates that the signal referenced in the warning has no load and will be removed during implementation. ------------------------------------------------------------------------------- What does this mean? In case the signal is removed, what heppens? How can we avoid this warning? Second type is ------------------------------------------------------------------------------ WARNING:DesignRules:331 - Blockcheck: Dangling G output. G of comp microblaze_0/microblaze_0/Data_Flow_I/Register_File_I/Register_File_Bit_I15/R egFile_X2/microblaze_0/microblaze_0/Data_Flow_I/Register_File_I/Register_File _Bit_I15/RegFile_X2/SP.G is configured, but output is not used. ------------------------------------------------------------------------------ I could not find the answer browser, but similar answer browser, ----------------------------------------------------------------------------- To check for this, search for these components in FPGA Editor, and see if they are configured ----------------------------------------------------------------------------- If this is a problem, how can we configure in FPGA editor?Article: 78705
outp and accu have many bits which will always have the same value. The synthesis tool notices this, and thus decides to reusue the accu register to feed whatever the corresponding bits of the outp register feed. For example, outp(0) is always accu(0). So is accu1(8). So using accu1(8) everywhere that outp(0) is used is logically equivalent, and uses fewer resources. - Paul "Philipp" <sportfreund@gmx.at> wrote in message news:36n438F50qb8bU1@individual.net... > Hello > > I have implemented an multiplier in the following way: I always take 4 > bits of my first operand and multiply it with the second operand. So in > every step I generate 4 partial products which have to be added. This sum > is stored in the accumulator. In the next clock cycle I take the next 4 > bits, multiply it with the second operand, sum up the partial products and > add this to my accumulator. This is performed a few times until I have > processed all the bits of operand one. Then my result is stored in the > accu. > My implementation works fine but when I synthesize it I get a lot of > "warnings", can somebody tell me what went wrong here? > > Mapping all equations... > Building and optimizing final netlist ... > Register outp_0 equivalent to accu1_8 has been removed > Register outp_1 equivalent to accu1_9 has been removed > Register outp_2 equivalent to accu1_10 has been removed > Register outp_3 equivalent to accu1_11 has been removed > Register outp_4 equivalent to accu1_12 has been removed > Register outp_5 equivalent to accu1_13 has been removed > Register outp_6 equivalent to accu1_14 has been removed > Register outp_7 equivalent to accu1_15 has been removed > Register outp_8 equivalent to accu1_16 has been removed > Register outp_9 equivalent to accu1_17 has been removed > and so on... > > The code for accu1 and outp looks the following: > > if rst = '1' then > op1 <= (others => '0'); > op2 <= (others => '0'); > outp <= (others => '0'); > accu1 <= (others => '0'); > > elsif clk'event and clk = '1' then > if load = '1' then > op1 <= inp0; > op2 <= inp1; > end if; > if shift = '1' then > op2 <= op2((2*width-10 downto 0) & (7 downto 0 => '0'); > end if; > if acc = '1' then > accu1 <= accu((2*width-1) downto 0) & (7 downto 0 => '0'); > outp<= "00" & accu((2*width-3) downto 0); > end if; > end if; > end process; > > accu represents always the newest Accumulator value. Hope somebody can > explain me how to get rid of all these warnings > > Cheers > Philipp >Article: 78706
This is getting tedious, but Paul did write " we were so surprised that Virtex-4 came out so poorly." That's where I got the SURPRISE from. :-) It looks like everybody agrees: the evolution from 130 nm to 90 nm does not automatically give a big performance boost. (it lowers the cost, though). So Altera and Xilinx used additional means to improve Stratix-II and Virtex-4 performance, but the two companies did this in very different ways. Altera changed the LUT structure significantly, and I can believe that this makes certain applications faster, if they can tolerate shared inputs. But Altera made no systems-oriented functional changes, added no new functions or structures. Xilinx did the opposite, leaving the LUT structure pretty much as before, but adding and improving functionality in many ways (as I emphasized in the web-seminar). What does that mean for the old benchmarks? Since all Altera benchmark use established legacy designs, and only designs available to Altera, they will benefit from LUT-level improvements, but will of course have no clue about major structural and functional improvements, as introduced by Virtex-4. I bet there are no dual-clock FIFOs in the Altera benchmarks, or 32-tap FIR filters, or Gigabit SerDes, or microprocessors, or even SRL16s or LUT-RAMs. Such applications do not exist in the old designs, or they are implemented in such different, less efficient ways that they do not migrate. Altra evolved Stratix-II in a direction that old legacy benchmarks can easily take advantage of. Xilinx evolved Virtex-4 into a more systems-oriented direction. I am convinced the Virtex-4 innovations provide a bigger performance boost for new designs that can take advantage of the new features. Who cares about porting obsolete designs? This also answers the quest for public benchmarks: There is no way that otherwise nice guys like Paul and Peter would ever agree on such benchmarks. I would insist on SRL16s, FIFOs etc, and Paul would load up with applications that are favored by the complex LUTs with their shared inputs. Both of us would have to be selfish, since there is so much at stake. There can be no common ground, since there is no "typical benchmark". Benchmarks are dead, long live performance! Peter AlfkeArticle: 78707
Thanks Paul, is this okay when I leave it this waz and let the synthese tool do the work to get rid of the redundant information? cheers Philipp "Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message news:Tf6dnecnorC8wJvfRVn-jA@rogers.com... > outp and accu have many bits which will always have the same value. The > synthesis tool notices this, and thus decides to reusue the accu register > to feed whatever the corresponding bits of the outp register feed. > > For example, outp(0) is always accu(0). So is accu1(8). So using > accu1(8) everywhere that outp(0) is used is logically equivalent, and uses > fewer resources.Article: 78708
Peter Alfke wrote: > This is getting tedious, but Paul did write " we were so surprised that > > Virtex-4 came out so poorly." That's where I got the SURPRISE from. > :-) > > It looks like everybody agrees: the evolution from 130 nm to 90 nm does > not automatically give a big performance boost. (it lowers the cost, > though). > So Altera and Xilinx used additional means to improve Stratix-II and > Virtex-4 performance, but the two companies did this in very different > ways. > Altera changed the LUT structure significantly, and I can believe that > this makes certain applications faster, if they can tolerate shared > inputs. But Altera made no systems-oriented functional changes, added > no new functions or structures. > Xilinx did the opposite, leaving the LUT structure pretty much as > before, but adding and improving functionality in many ways (as I > emphasized in the web-seminar). > What does that mean for the old benchmarks? > Since all Altera benchmark use established legacy designs, and only > designs available to Altera, they will benefit from LUT-level > improvements, but will of course have no clue about major structural > and functional improvements, as introduced by Virtex-4. > > I bet there are no dual-clock FIFOs in the Altera benchmarks, or 32-tap > FIR filters, or Gigabit SerDes, or microprocessors, or even SRL16s or > LUT-RAMs. Such applications do not exist in the old designs, or they > are implemented in such different, less efficient ways that they do not > migrate. > > Altra evolved Stratix-II in a direction that old legacy benchmarks can > easily take advantage of. Xilinx evolved Virtex-4 into a more > systems-oriented direction. I am convinced the Virtex-4 innovations > provide a bigger performance boost for new designs that can take > advantage of the new features. Who cares about porting obsolete > designs? > > This also answers the quest for public benchmarks: There is no way that > otherwise nice guys like Paul and Peter would ever agree on such > benchmarks. I would insist on SRL16s, FIFOs etc, and Paul would load up > with applications that are favored by the complex LUTs with their > shared inputs. Both of us would have to be selfish, since there is so > much at stake. > There can be no common ground, since there is no "typical benchmark". > > Benchmarks are dead, long live performance! > Peter Alfke I think most of what Peter has said is very reasonable. But I think you *can* have common public benchmarks if you start at a higher level rather than try to share HDL code. Typically, a project will know which vendor is going to be used and can design their architecture to fit. So why not spec a design function and let the vendor write their own code to implement it? -- Rick Collins rick.collins@XYarius.com Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design http://www.arius.com 4 King Ave. 301-682-7772 Voice Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.comArticle: 78709
Paul Leventis (at home) wrote: <snip> > I cannot speak for Xilinx and their speed files. But on the Altera side of > things, I would not expect much change in core performance. For all > families I've been involved with (Stratix, Cyclone, and beyond), our core > performance predictions made in the preliminary timing models have been very > close (within 5%) of final production numbers. Stratix II core (logic + > routing) speed will not be changing more than a few % in the future. Our > models have already been correlated to silicon and compare very well. <snip> Funny, I was sure this was an Altera link ( you have seen this ? ) http://www.altera.com/corporate/news_room/releases/products/nr-perf_power.html To me that looks rather more than a 5% nudge ? Does this mean the prelim models were not as good as you claim, or are you more carefully qualifying the best ones, to better compete with Xilinx's claims ? In all this speed/benchmark hoopla, I see one thing that is never mentioned is price. Will we see a 'bragging rights' bin, that is the three sigma yield limit, and so very expensive, but hey, look how fast we are !! -jgArticle: 78710
rickman wrote: > Peter Alfke wrote: <snip> >> This also answers the quest for public benchmarks: There is no way that >> otherwise nice guys like Paul and Peter would ever agree on such >> benchmarks. I would insist on SRL16s, FIFOs etc, and Paul would load up >> with applications that are favored by the complex LUTs with their >> shared inputs. Both of us would have to be selfish, since there is so >> much at stake. >> There can be no common ground, since there is no "typical benchmark". >> >> Benchmarks are dead, long live performance! >> Peter Alfke > > > I think most of what Peter has said is very reasonable. But I think you > *can* have common public benchmarks if you start at a higher level > rather than try to share HDL code. Typically, a project will know which > vendor is going to be used and can design their architecture to fit. So > why not spec a design function and let the vendor write their own code > to implement it? Exactly, this is the 'optimised' branch I was talking about. Uses do not care what tricks you use, they want to know the peak MHz, MHz/$, or mW/MHz or whatever, for a particular application. They EXPECT differences in fit and ideal usage, by end application, but right now, this type of information is sparse indeed. They also are more interested in a design broadly in their field, than in how fast one node can spin. FPGAs are getting more complex, with the dedicated blocks, so HDL designers need vendor-tuned examples of how to efficently use those blocks. -jgArticle: 78711
There is a lot of negative baggage associated with the term Benchmark. Yet there is a lot of performance related info that would help designers, both in choosing between chips and when working on a design. I'm thinking of things like the speed of a 32 bit counter. It's a reasonably basic building block. It's not the whole story, but it's one very useful data point. The next question is how many variations make sense? Do they have major impacts on the speed and/or take extra resources? Enable, load, overflow flag, ... Maybe the info I'm looking for should be printed in green if there is a good fit with the hardware (sweet spot) and flagged with red if the answer might surprise you (say because it takes an extra level of logic). Other basic things I'd like to see... Data rate between 2 chips (same type/speed). Routing delays to go N steps H or V. Maybe that's all BS because most engineering time is spent working at a higher level. (But I always get involved with the details.) Maybe a handful of medium size tasks would be interesting. Maybe library elements. Maybe just good examples. Pulse width modulators - fixed and programmable parameters. FIR filters. State machines - need several examples. DRAM controller >I think most of what Peter has said is very reasonable. But I think you >*can* have common public benchmarks if you start at a higher level >rather than try to share HDL code. Typically, a project will know which >vendor is going to be used and can design their architecture to fit. So >why not spec a design function and let the vendor write their own code >to implement it? I was thinking about that too. One complication is that you can push some things off to the non-FPGA parts of the system or pull things in. What sort of problem would be a good whole-system example? Vendor neutral would be nice, but I'm also interested in good examples that take advantage of special features, and I'm willing to push things around and/or change the problem if that makes things fit better for the total system. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 78712
Hello, I'm working on a simple hardware design lab -Microblaze.When I start a new project with BSB in Xilinx Platform Studio(XPS)and select target development board I face a problem. The board which I have is Spartan-3 and the lab exercise is based on Spartan-3. But the software(XPS) 6.2i which i have in system does'nt show all the xilinx board names. When i select Xilinx in the board vendor, it shows only 2 names in Board Names(AFX Virtex and Virtex II). I wish to select Spartan-3 which isnt there. how to include Spartan-3? . Is there any alternative way to include spartan-3 board name? please help me Thank youArticle: 78713
Philipp <sportfreund@gmx.at> wrote: > is this okay when I leave it this waz and let the synthese tool > do the work to get rid of the redundant information? yes, that's ok. But keep care about other warnings. One drawback of XST is the generation of warnings: if your project grow it is near to impossible to avoid warnings. Some of them are harmless and more "informative". But other could be essential and it is possible that you overlook some. WD --Article: 78714
The Xilinx Spartan-3 Starter Kit board was released after EDK 6.2. Have you installed EDK 6.2 service pack 2? The service pack should include board support for the Spartan-3 Starter Kit board. The service pack can be downloaded from: http://www.xilinx.com/ise/embedded/edk_download.htm Cheers, Shalin- Ram wrote: > Hello, I'm working on a simple hardware design lab -Microblaze.When I > start a new project with BSB in Xilinx Platform Studio(XPS)and select > target development board I face a problem. The board which I have is > Spartan-3 and the lab exercise is based on Spartan-3. But the > software(XPS) 6.2i which i have in system does'nt show all the xilinx > board names. When i select Xilinx in the board vendor, it shows only 2 > names in Board Names(AFX Virtex and Virtex II). I wish to select > Spartan-3 which isnt there. how to include Spartan-3? . Is there any > alternative way to include spartan-3 board name? please help me > Thank you >Article: 78715
Hal Murray wrote: <snip> > What sort of problem would be a good whole-system example? How about: Frequency/Pulse Counter [24/32/40/48 bits ] This needs counters, and capture. Counters can be either Decimal, or Binary, with some Bin-BCD post conversion, for display of the results. DDS - same widths, this needs wide adders Expanding to Waveform generation, and pulse generation... These are complex enough to push the FPGA, have easily verifiable output everyone can relate to, and would be genuinely usefull for education.. Some would be simple enough for the MAX II or smallest ProASIC3... and more ambitious: a Storage Oscilloscope, that needs a timebase, and wide data path pumping, [assume external fast-enough ADC] to any choices of USB / Firewire / ATA / SerialATA (etc) for the results. > Vendor neutral would be nice, but I'm also interested in > good examples that take advantage of special features, > and I'm willing to push things around and/or change the > problem if that makes things fit better for the total > system. Of course.. -jgArticle: 78716
I am seeing a very strange behavior. Till last week I was using ISE6.1i03 succesfully in any design. Before I start a new design I did upgrade it to ISE6.3i03 and while debuging the new design's PCB I noticed when using iMPACT after any sucessfull device command like Erase, blank check or Program the XCF02S, or Programming the XC2S200E on board, the next JTAG command returns error (ERROR:iMPACT:1210 - '2':Boundary-scan chain test failed at bit position '1'). In the FPGA command case, the configuration is sucessfull (DONE goes high) but I/O pins still in Hi-Z. Mode pins are in JTAG. XCF02S memory is erased. When JTAG starts with this problem I have to cycle power in the design's PCB to have JTAG access again. Power supply (1.8V and 3.3V) is ok and no voltage dip is seen. I returned to ISE6.1i03 to see if there were something wrong with ISE6.3 under Windows XP+SP2 but there still the same problem (note that the old installed ISE6.1i03 was working perfectly under XP+SP2). I am using Xilinx original Parallel Download Cable-III. Now I am wondering if ISE6.3i installation did change some XP's system file (not returned by re-installation of ISE6.1i) that could lead to this error. I am currently two days under this fault and customer is already asking why a simple board test (to be sure all devices are working properly) cannot be done. Any clue will help a lot. Best regards,Article: 78717
Jim, I like your idea, but it is not all that straightforward. I mentioned in the seminar that there is a loadable synchronous counter inside every DSP Slice, and it runs at 500 MHz, no ifs, no buts. Now, I will build a 5 GHz counter using the MGT. Is that allowed? DDS obviously runs at 500 MHz in the DSP slice, but I will run a virtual 8 GHz DDS either by using 16 accumulators, or by doing some clever math. Is that kosher? If you saw my seminar, I mentioned those things, and there will be app notes, etc. Storage oscilloscope is dear to my heart, but it has many arbitrary parameters. Its performance and cost are determined by the A/D at the input, not the FPGA. I suggest we keep generating creative app notes, reference designs, and evaluation boards, without calling them benchmarks. BTW: Choosing between X and A isn't all that difficult, it's only between two suppliers. Selecting between umpteen brands of breakfast cereals, washing mashines, cars, or colleges for your kids is a much tougher task. ( Life in NZ may be simpler, but the choices in the US are mindboggling. ;-) Peter AlfkeArticle: 78718
hello all, I'm drawing the layout of my Xilinx XC9572XL (TQ100)evaluation board but I wonder wether it is necessary to connect all GND and VCC pins to the power tracks. Could somebody tell me that? Thanks by advance.Article: 78719
"Mouarf" <moi@chezmoi.fr> wrote in message news:4206bc40$0$17118$626a14ce@news.free.fr... > hello all, > > I'm drawing the layout of my Xilinx XC9572XL (TQ100)evaluation board but I > wonder wether it is necessary to connect all GND and VCC pins to the power > tracks. Could somebody tell me that? > > Thanks by advance. > > Yes. Don't try to second-guess the chip designers. BobArticle: 78720
Yes, connect all. On-chip and going of-chip current transitions ( di/dt ) are so fast, that they create v=L di/dt ground bounce voltage over the unavoidable inductance between chip and pc-board. You must keep this inductance as small as possible = connect all supply pins. Peter Alfke, Xilinx ApplicationsArticle: 78721
Then we must be in a similar position, as I was also browsing that website (albeit before getting my board). :-) C3Article: 78722
OK, I'll connect all power pins but are all GND (and VDD) pins connected together inside ? "Peter Alfke" <alfke@sbcglobal.net> a écrit dans le message de news: 1107738800.425885.182090@g14g2000cwa.googlegroups.com... > Yes, connect all. On-chip and going of-chip current transitions ( di/dt > ) are so fast, that they create v=L di/dt ground bounce voltage over > the unavoidable inductance between chip and pc-board. You must keep > this inductance as small as possible = connect all supply pins. > Peter Alfke, Xilinx Applications >Article: 78723
Yes, they are. But you should not rely on this. It's your job to minimize the resistance and inductance. Peter AlfkeArticle: 78724
Just got round to firing up my ML401 last weekend. The quality of the video output is terrible. Do I have a faulty board, or is it a design/layout issue? The video out has asynchronous resonant spikes running through it. The spikes are about 100 mV p-p, and have a resonant frequency of about 250 MHz, with about 6 half-cycles present. There is also about 15 mV p-p of pixel clock and harmonics. Jitter is about 5ns p-p. I have not yet poked around with a scope or stared at the layout. I was hoping this is a board rather than a design problem, as I had intended to use the board for some video tests. Also, the V4 is quite toasty. After running the slideshow for a few minutes the temperature is in the high 60s. Is this reasonable? (It's an ES part). Thanks Pete
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