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
V5LX50 have been available for several months. I don't want to get into a fight with your distributor, but he is feeding you nonsense data. Unless you want a peculiar combination of package-speed-temp range there should be no problem getting many samples now. If you have trouble, send me an e-mail. But I will be gone through labor day, Sept 4. Peter Alfke, peter@xilinx.com ========================== jeffnewcomb@nci-usa.com wrote: > I questioned the availability of the Virtex5 back in July on this group > and got some responses from Xilinx people saying it was being sampled > and to get a sample I needed to get an order in immediately. I did that > even though the parts were not even in distributors systems and the > local Xilinx reps initially were not sure what delivery would be. I > did get a response back from the rep saying there was a 13 week > delivery for an engineering sample which would be in late Sept. and you > could not get production parts until next year. I could live with that > and proceeded with my design using a V5LX50. Yesterday we got a FAX > from our distributor /rep saying delivery of the engineering sample > would not be until May 2007!!!. This is a full year after the part was > anounced. I have seen numerous advertisements for the Virtex 5 > "Shipping NOW". Does anyone know the truth behind this part ???? Are > there major problems with the part?Article: 107301
Peter Alfke schrieb: > V5LX50 have been available for several months. > I don't want to get into a fight with your distributor, but he is > feeding you nonsense data. Distributors like to do that to small companies.... :-( Kolja SulimmaArticle: 107302
On Fri, 25 Aug 2006 12:41:38 -0700, Martin E. wrote: > I am looking for a way to read/write to a SATA drive from an FPGA. I've > looked around. Nothing seems to fit the bill. Any ideas worth > considering? > > Thanks, > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin > > To send private email: > email = x@y.com > where: > x = "martineu" > y = "pacbell.net" Not ideal pin count wise but how about a SATA-PATA bridge? We're using the JMicron chip, its inexpensive and goes both ways (host & device) Peter WallaceArticle: 107303
fpga_toys@yahoo.com wrote: > Replacing LUT SRL's with LUT RAM's certainly helps by removing the SRL > bit shifting power, but doesn't lower the design toggle rates below 50% I don't understand this. LUT SRL's are not shift registers if I understand them correctly. They don't move the data, they move the pointer. So the only power used is in the internal address counter and the writing of the data to one cell in the LUT. Is that really so much power? If you use the LUTs as RAM and make your own counter, I expect the power per shift register is actually higher at that point.Article: 107304
On Thu, 24 Aug 2006 12:36:56 -0700, PeteS wrote: > A recent thread went over the maximum permitted power on a device. > > So why don't we have a sensing diode (well, a transistor with collector > tied to base works better) on the die somewhere? It's fairly easy to do, > according to my VLSI acquaintances, and with faster and faster IO > [implying as it does faster and faster logic switching as well], it > would make sense to see these on any largescale (more than 100 pins > perhaps) FPGA package. > > Comments? > > Cheers > > PeteS A little awkward but what about forward biasing one of the input protection diodes with a mA or so? Peter WallaceArticle: 107305
Antti .... what you say would be true IF and ONLY IF the SATA-IO was a closed organization to FPGA vendors, such that the NDA was part of a deliberate means to exclude ALL FPGA vendors. However, the opposite is true ... Every FPGA vendor is certainly free to join SATA, and to licence the SATA technology, just as the ASSP vendors are .... making access to the NDA material equal access between both FPGA vendors and ASSP vendors. So the exclusive rights conspiracy theory presented by both you and Austin is a piece of crap. And as far as I can tell both of you have your heads in the clouds flying kits, and need to get your head back on the ground and learn how to COOPERATE with people rather than complain that others can band together as the SATA-IO organization and actually produce a usable industry wide standard that is available for license to all cooperating members participating in that standards process.Article: 107306
Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift register that transfers all data bits to their respective neighbors. So it will probably consume more power than a pointer-addressed RAM. But you don't need the pointer, and it's also a neat way to load a LUT with its 16 bits. Peter Alfke ================== rickman wrote: > fpga_toys@yahoo.com wrote: > > Replacing LUT SRL's with LUT RAM's certainly helps by removing the SRL > > bit shifting power, but doesn't lower the design toggle rates below 50% > > I don't understand this. LUT SRL's are not shift registers if I > understand them correctly. They don't move the data, they move the > pointer. So the only power used is in the internal address counter and > the writing of the data to one cell in the LUT. Is that really so much > power? If you use the LUTs as RAM and make your own counter, I expect > the power per shift register is actually higher at that point.Article: 107307
Nico Coesel wrote: > "PeteS" <PeterSmith1954@googlemail.com> wrote: > > >Jim Granville wrote: > >> Austin Lesea wrote: > >> > Martin, > >> > > >> > No, and No. Sorry, even V5 does not have the frequency tracking agility > >> > to track the SATA spread spectrum clock. And because of that, we have > >> > no IP for it, either. > >> > > >> > The ASSP vendors are very protective about their business: they > >> > continue to make their little applications as tough to do as possible, > >> > to keep out the 'big bad FPGA vendors' who seem to be eating up all > >> > their businesses. (Hey, we are just trying to make our customers happy!) > >> > > >> > Too bad: when an industry is spending time being defensive, they have > >> > already lost - any time spent not innovating means you are doomed to > >> > failure. > >> > >> That probably depends on where you are standing. > >> > >> Could be, that the FPGA sector needs to innovate, and include > >> sufficent agility to track a SATA spread spectrum clock ? > >> > >> Sounds more an issue of who decides the market is large enough to > >> bother with, than any perceived fpga-vs-assp battles ? > >> > >> -jg > > > >I'll second this with an added comment: Spread spectrum clocks are an > >absolute must in some areas, and very desirable in others; I would > >*love* to use a spread spectrum clock in my newest design because it > >does not have a metal enclosure and EMI/EMC is a major issue. > >When you make FPGAs (or ASICs or any other chip for that matter) for a > >living but not shipping board and enclosure level products it's easy to > >forget 'little details' like this (regulatory compliance) that systems > >and board designers live with day in and day out. > > > >Spread spectrum obviously alleviates the problem significantly (in some > >very subtle ways too). A lot of vendors offer the ability to track a > >spread spectrum clock; why not FPGA vendors too? > > You can as long as you don't use the DCM (or anything like it) and > route the fpga for the highest allowed clock frequency. If you use an > external device to create your clocks and feed them into the fpga, > there is no reason why an fpga won't work with spectrum spread clocks. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nl My point is there is nothing I am using (or generating) in the design that would suffer from spread spectrum (indeed, my design would benefit higely) and I would love to generate all system clocks except a processor from a spread spectrum master. That implies using the DCM (or it's equivalent). A spread spectrum oscillator can be modelled as a device with (introduced) jitter, and are quite well documented [if they aren't, I don't use them]. I am astounded (in a way) that a DCM can't handle the (relatively minor) deviation of a master clock to generate new ones with the same percentage variances. If I have to use a PLL (which can be tuned to track such things), it would mean either changing the device to a 'well known competitor' or adding hardware (which adds power consumption I can not afford). Cheers PeteSArticle: 107308
PeteS wrote: > I'll second this with an added comment: Spread spectrum clocks are an > absolute must in some areas, and very desirable in others; I would > *love* to use a spread spectrum clock in my newest design because it > does not have a metal enclosure and EMI/EMC is a major issue. I understand that spread spectrum helps pass EMI testing. But does a spread spectrum clock actually help reduce interference? It seems to me that by relatively changing the clock frequency, all you are doing is fooling the test equipment which operates slowly in comparison. In reality you have not reduced the energy transmitted and unless your interference is very narrow band in nature, it will not fix the problem. Many applications that care about EMI are not helped by a "trick" that gets through the testing without actually solving the problem. For example self interference in a radio. I don't think a spread spectrum clock on the digital circuits would actually reduce the amount of interference seen. Am I wrong about this?Article: 107309
Peter Alfke wrote: > Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift > register that transfers all data bits to their respective neighbors. So > it will probably consume more power than a pointer-addressed RAM. > But you don't need the pointer, and it's also a neat way to load a LUT > with its 16 bits. I wasn't aware of that. Is this only true for the V5 parts, or has this always been true for SRLs in Xilinx parts that have them?Article: 107310
Tim Verstraete wrote: > Hey, > > I just updated to ISE8.2SP2 but still the same issue ... > > i started debugging the issue and found that for some reason it has a > problem with the IFF1:\#FF\ statement and still Xilinx makes the same > attribute when i use the records script option and do the changement > manually? i've mailed to my FAE just in case ... > > thanks for the feedback, > > kind regards, > > Tim > > John_H schreef: > >> I don't have an answer, but a suggestion: break the config into its parts. >> If you set the Config IFF1 in one line and Config INIT_Q4 in another - just >> one per line - you might find out what "really" fails. >> >> If I had to guess I'd think the line length in your command is a problem. >> Breaking it up eliminates this issue and can let you debug the problem to >> its core. >> >> >> "yttrium" <yttrium@telenet.be> wrote in message >> news:%RHGg.127097$YS7.119815@blueberry.telenet-ops.be... >>> Hey, when i run a script through FPGA editor i get the following error: >>> >>> setattr comp >>> c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) >>> Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ >>> IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ >>> IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4 >>> ERROR:FPGAEditor:25 - "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1 >>> IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0 >>> IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" is not a >>> valid value for the Config attribute. BRBCF ILOGIC Failure: INVALID_RB: >>> "IFF1::\#FF" CFG: "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1 >>> IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0 >>> IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" >>> >>> even when i make this change manually and then save and record this a >>> script and then run it, it gives me that error. So when FPGA editor >>> generates the following statement: >>> >>> setattr comp >>> c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) >>> Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ >>> IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ >>> IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4 >>> >>> and that one is exactly the same as the one in my script then what am i >>> doing wrong??? to get me that answer? >>> >>> Thanks in advance for your help, >>> >>> kind regards, >>> >>> Tim > I have found that you should write IFF1:FF instead of IFF1:\#FF\ ... only the Xilinx tools also write the second version instead of the first one ... so if you just correct this one it works fine again ... thanks for the feedback anyway...Article: 107311
Is it possible to use adiabatic computing with today FPGAs? It uses less power by stretching the time for loading capacitors and uses LC tanks for energy storage: http://www.eecs.umich.edu/acal/energyrecovery/papers/soc03.pdf The ultimate power reduction would be to use reversible computing: http://en.wikipedia.org/wiki/Reversible_computing because in theory the energy dissipation is zero. You can use the Fredkin gate as the base gate for implementing all logics: http://en.wikipedia.org/wiki/Fredkin_Gate which can be implemented with collision-based computing, like the billiard ball model: http://tinyurl.com/gbarb But how can this be implemented in ICs? Some ideas are presented in this article and one implementation of the Fredkin gate with collision-based computing elements: http://www.zyvex.com/nanotech/helical/helical.html Are there any plans from the major FPGA vendors to incorporate some of these ideas in their devices? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 107312
rickman wrote: > I understand that spread spectrum helps pass EMI testing. But does a > spread spectrum clock actually help reduce interference? It seems to > me that by relatively changing the clock frequency, all you are doing > is fooling the test equipment which operates slowly in comparison. In > reality you have not reduced the energy transmitted and unless your > interference is very narrow band in nature, it will not fix the > problem. I agree fully ... the peak energy is still there, just prevents the test equipment from integrating it. And all you are doing is poluting more of the band with energy. When the computer device is near the reciever which is also trying to listen to a transmitter that is relatively VERY far away, the small amount of near energy spread across more spectrum is still a major interference source, with a higher likelyhood for interference. I can't wait for someone to come out with a fast integrator that can truely measure peak energy ... at which point these idiots will be caught with their pants down trashing far more spectrum than needed.Article: 107313
Austin Lesea wrote: > Oops, > > You still need to have the X7 clock, the the ISERDES does all the work. > > Austin > > Austin Lesea wrote: >> Antti, >> >> Thank you. Yes, it does look like this is a X7 deserializer. In which >> case the cheapest, fastest and easiest may be to just buy the ASSP that >> was designed to do that job. >> >> I still think that V4 could also do this without any need for the ASSP >> as the SSIO features include X7 sampling, without having to mutliply the >> clock. >> >> http://direct.xilinx.com/bvdocs/userguides/ug070.pdf >> page 355 >> >> Austin >> >> Antti wrote: >>> Austin Lesea schrieb: >>> >>>> Rob, >>>> >>>> Here goes, >>>> >>>> See below: >>>> >>>> Austin >>>> >>>> -snip- >>>>> Serious question: Does Altera's PLL's offer an advantage (veratility, >>> [snip] >>>> I am confused, however, the 45 MHz ports should be trivial, and won't >>>> even require a DCM. It is the 315 MHz ports that will make use of the >>> Austin, >>> >>> the OP desing looks very much like CameraLink. >>> >>> so the incoming clock would be multiplied by x7 to get bit clock. >>> >>> it is doable with Virtex and DCM, but for what I would suggest >>> (if it is CameraLink) is still to use the dedicated deserializer. >>> >>> if you look at Virtex boards with Cameralink support than most >>> of them (but not all) have dedicated serializers. >>> >>> of course if it not Cameralink (or those deserializers can not >>> be used) then it has to be checked if it makes sense to >>> use only virtex LVDS + DCM or have external circutry too. >>> >>> Antti >>> http://xilant.com >>> why not use the x3.5 clock and then use a DDR FF at the input => lower clock frequency, we use this all the time in video processing units ... xilinx even has a core for it: <http://www.xilinx.com/bvdocs/appnotes/xapp265.pdf>Article: 107314
JustJohn wrote: > Now I'm totally confused TC. What does "highly random" data mean? Data > with a 75% toggle rate is halfway towards the ultimate pathological > case of "0101010101...". To me, highly random data implies a fairly > flat distribution with a 50% average toggle rate, period. If any given > flop has a 50% chance of toggling on any given clock cycle, your > summation seems to imply that some flops (or srl cells) are toggling > twice per cycle. That's a neat trick, and I don't get it. yep ... my error ... was tired and starting thinking in terms of run probability which is clearly wrong. I should have simply stood on my real concern, which is for bit serial machines, they will have worst case data from time to time, or even more likely near worst case data, and have to eat the power for that state for a word length of clocks. Which means, the power system needs to be able to deliever worst case power for a word latency, or get a power rail "THUMP" and reset, or worse, corrupted data. > The caustic expletives > don't help your cause, and really puts folks off here. you are right ... and at the same time, my tollerance for Austin and Peter is near zero, when they assert things on reputation and their employers name, that are direct personal attacks. I'll be nice and mind my language better. My respect level for Xilinx is at a near all time low.Article: 107315
rickman wrote: > Many applications that care about EMI are not helped by a "trick" that > gets through the testing without actually solving the problem. For > example self interference in a radio. I don't think a spread spectrum > clock on the digital circuits would actually reduce the amount of > interference seen. I think the assumption was that the spread spectrum clock would get filtered by the decoder, and not affect signal decoding. That is certainly true in respect to voice/analog transmissions. However, for high rate data, the clock spread frequency isn't rejected at the symbol sampling rate, and certainly doesn't prevent symbol corruption or decode lock problems.Article: 107316
Antti Lukats wrote: > 3) think twice before claiming to know the contents of the heads of the > others Both YOU and Austin are crazy to assert the ASSP's are blocking access to SATA-IO membership. By joining Austin's conspiracy theory, you violate this very rule of yours. Frankly, when I read down the SATA-IO membership list, I see a large number of companies that should actually prefer the FPGA vendors were part of the standards process and shipping SATA enabled FPGA's. Even some of the ASSPs, since that would provide a prototype path to their volume production.Article: 107317
Peter, It is the substate to s,d pn junction, but it does not resemble the 1N914 that is the "standard" for measuring temperature. I have no idea if it would work, or not. Before we had temp diode, people would calibrate the frequency shift on a ring oscillator, with nothing else in the part, forcing the temperature. Then, with the design running, all you had to do was measure the frequency of the ring oscillator to get a reading. Since the temp diode, the ring oscillator method has been abandoned. Austin Peter Wallace wrote: > On Thu, 24 Aug 2006 12:36:56 -0700, PeteS wrote: > > >>A recent thread went over the maximum permitted power on a device. >> >>So why don't we have a sensing diode (well, a transistor with collector >>tied to base works better) on the die somewhere? It's fairly easy to do, >>according to my VLSI acquaintances, and with faster and faster IO >>[implying as it does faster and faster logic switching as well], it >>would make sense to see these on any largescale (more than 100 pins >>perhaps) FPGA package. >> >>Comments? >> >>Cheers >> >>PeteS > > > A little awkward but what about forward biasing one of the input > protection diodes with a mA or so? > > Peter WallaceArticle: 107318
rickman wrote: > PeteS wrote: >> I'll second this with an added comment: Spread spectrum clocks are an >> absolute must in some areas, and very desirable in others; I would >> *love* to use a spread spectrum clock in my newest design because it >> does not have a metal enclosure and EMI/EMC is a major issue. > > I understand that spread spectrum helps pass EMI testing. But does a > spread spectrum clock actually help reduce interference? It seems to > me that by relatively changing the clock frequency, all you are doing > is fooling the test equipment which operates slowly in comparison. In > reality you have not reduced the energy transmitted and unless your > interference is very narrow band in nature, it will not fix the > problem. You are correct that the energy transmitted is the same. The test equipment isn't fooled: it still reads the same energy. The trick is that the energy is spread over a larger bandwidth. The higher the harmonic, the wider the bandwidth and the lower the maximum power since the energy is constant in that harmonic. While 30 kHz might not seem like a "wide" bandwidth for interference purposes, when is interference noticed above noise? Typically when it's rather narrow-band. 30 kHz isn't broad, but it isn't narrow-band. The interference should appear as a degraded noise floor but with no narrow band troubles. > Many applications that care about EMI are not helped by a "trick" that > gets through the testing without actually solving the problem. For > example self interference in a radio. I don't think a spread spectrum > clock on the digital circuits would actually reduce the amount of > interference seen. > > Am I wrong about this? The application will tell you if the increased noise floor is a problem. For the case of self interference in a radio, a degraded noise floor will degrade the performance when highest sensitivity is needed but the annoying tones won't be there.Article: 107319
rickman wrote: > Peter Alfke wrote: >> Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift >> register that transfers all data bits to their respective neighbors. So >> it will probably consume more power than a pointer-addressed RAM. >> But you don't need the pointer, and it's also a neat way to load a LUT >> with its 16 bits. > > I wasn't aware of that. Is this only true for the V5 parts, or has > this always been true for SRLs in Xilinx parts that have them? SRLs have been actual shift registers for quite some time. A recent discussion pointed out that the Pre-V5 SRLs shifted charge from one memory cell to the next (I'm assuming like a CCD) but this "trick" didn't scale well beyond 90 nm so the V5 parts use master/slave latches to halve the number of available elements in the SRLs. SRLs physically have a Din and a MUX out with a Dout optionally available to extend the SRL length.Article: 107320
On Thu, 24 Aug 2006 13:18:37 -0700, Austin Lesea <austin@xilinx.com> wrote: >The heatsinking has to be able to remove the heat such that the 85C >(commercial) or 100 C (industrial) junction temperature is not exceeded, Junction or case? regards, GerhardArticle: 107321
Martin E. wrote: > We are designing with a V2P30 right now for migration to an equivalent V5 > Q1'07. The SATA solution won't be needed until early next year. Would V5 > work then? > > Also, is SATA IP commercially available? > > I guess an alternative might be to go PCI X/e and then use an off-the shelf > SATA controller that talks to PCI. The problem is that I need lots of > drives in parallel (I do mean LOTS) for this application. It'd be easier to > hang them right off an FPGA with a PHY (which seem to be impossible to get). Ignoring all the paranoid nonsense that is being posted about this, I was able to Google search and find at least one potential PHY from Atmel, the AT78C5091. They have a summary data sheet although I don't see a full sheet. They provide a contact which I assume means they will only sell it if you are interested in high volumes. It may well be that external PHY chips are not used because of the high power or the high data rate. It would be a lot cheaper and lower power to integrate the PHY into your controller chip.Article: 107322
John_H wrote: > You are correct that the energy transmitted is the same. The test > equipment isn't fooled: it still reads the same energy. The trick is > that the energy is spread over a larger bandwidth. ummm ... yes and no. The test equipment has a specific bandwidth (either from front end filters, or from FFT resolution) and a specific integration time, both of which can be, and are likely to be, affected by the spread spectrum effects. The mV/m^2 remains the same, it's just time shifted across the 30KHz bandwidth, with the assumption that is less evil. Which is the case for signals that are integrated at 15KHz and below. At the reciever, the MV/m^2 power from all sources is summed. Without spread spectrum, two interference sources would have to have the same frequency to sum. With spread spectrum they sum if within 30KHz of each other (or whatever the spreading bandwidth is). However, for data rate signals with symbol times greater than 30KHz, the symbol decoder is integrating at a much faster rate, and the 30KHz shift is a full power interference for one or more symbol times. For recievers which are wide band, such as most data modems, the 30KHz shift keeps the same mV/m^2 energy completely inside the channel that is a MHz wide or two. The spread spectrum doesn't reduce the interference at all, and may actually make it worse by additively being integrated with non-spread spectrum narrow channel power sources, taking the peak power at a specific frequency above what the reciever can reject. or, Did I miss something?Article: 107323
John_H wrote: > rickman wrote: > > Peter Alfke wrote: > >> Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift > >> register that transfers all data bits to their respective neighbors. So > >> it will probably consume more power than a pointer-addressed RAM. > >> But you don't need the pointer, and it's also a neat way to load a LUT > >> with its 16 bits. > > > > I wasn't aware of that. Is this only true for the V5 parts, or has > > this always been true for SRLs in Xilinx parts that have them? > > SRLs have been actual shift registers for quite some time. A recent > discussion pointed out that the Pre-V5 SRLs shifted charge from one > memory cell to the next (I'm assuming like a CCD) but this "trick" > didn't scale well beyond 90 nm so the V5 parts use master/slave latches > to halve the number of available elements in the SRLs. > > SRLs physically have a Din and a MUX out with a Dout optionally > available to extend the SRL length. I thought the reason that SRLs were added was that they took little extra resources. This sounds like it requires significantly more logic in the LUT. But I guess the utility of the feature has allowed it to be practical in spite of the increased complexity.Article: 107324
Peter Alfke wrote: > I almost threw up when I read John Bass explain how he uses a > deliberately dumb-sounding name plus naive questions to light some fire > and create controversial flames. > > Really destroys my enthusiasm for this newsgroup. > It's like a rich guy pretending to be homeless, and then hitting you in > the groin while you are reaching for your wallet. Scum is the word > describing that kind of behavior... A better analogy, is that you and Austin have been having great fun kicking the homeless, and are pissed because you got busted for assault by an undercover cop. It's never fair to shoot down someones statements with a totally lost, clueless assertion unless you also make the effort to defend that statement with a sound reasoned argment. Trashing someone, on your reputation alone, or Xilinx's reputation alone is simply calling them clueless because you and Xilinx say they are, to hide the failings in your product line.
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