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
On Jun 26, 7:37=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > jack.gassett <jack.gass...@gadgetfactory.net> wrote: > > Hello, > > I was wondering if anyone has any advice on ways to use the Xilinx > > tools such as Impact, EDK, and Chipscope with a custom board that uses > > a ft2232 chip connected to JTAG? > > I have a custom open source board, > >http://www.gadgetfactory.net/gf/project/butterfly_main/, > > that uses a ft2232 chip for jtag communication. I am currently able to > > load svf files using urjtag but I am trying to work out a way to use > > the Xilinx tools with this custom board. Searching through the forums > > seems to indicate that there are no official Xilinx published API's to > > support custom programming cables. The only thing I can find is the > > libusb-driver project athttp://www.rmdir.de/~michael/xilinx/. It > > looks like this will allow me to accomplish what I am trying to do > > under Linux but I'm not sure if this will work under windows with > > cygwin or mingw. > > For programming, verify and readback, look at sourceforge xc3sprog SVN. N= o > help for Chipscope. It's a pity, that Xilinx keeps both sides of the > interface under the hood. Bug the Xilinx people at all exhibitions on thi= s > subject... > do not bother... they do not listen, ever. pity AnttiArticle: 141526
Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote: (big snip) < scenarion 1: < start programming, erase, write sync written, POWER OFF, POWER ON FPGA < ---> PUFFFF BLOW UP < the above is not 1:MIO odds case or is it? < now, i did include partial info, not only 11111 but also "just bad" < bit file can damage < i mean bit files that are INVALID, without proper CRC and trailer < and this seems to be so SEVERE and common to happen, that xilinx < issued special case HOW TO WRITE FLASH < (in order to prevent blow up) I had thought that previous FPGA families (I might be remembering XC4000 series) didn't exit reconfiguration mode until a valid CRC was seen. That would make it unlikely that a random or incomplete bit stream would cause damage. It seems that isn't the case anymore. -- glenArticle: 141527
Andy wrote:
> I have worked with some SW engineers that fairly quickly grasped the
> HW nature of HDL code, and some that didn't ever get it. I have also
> worked with some HW engineers that grasped the SW nature of their
> design, and some that didn't. Those that do understand the
> similarities and the differences between the two, and exploit the
> similarities while observing the limitations of the differences, are
> the ones I want on my team.
I agree. Thanks for the posting.
I would only add that it is curious that the same
software engineers that insist on careful version
control and unit testing for their own code,
are often content to accept a binary fpga image file
directly into their firmware without insisting
on having any of the supporting sources or build processes.
-- Mike Treseler
Article: 141528
Fredxx wrote:
> At the same time blind reliance of simulators is just as bad.
As is blind reliance on anything.
> There is the old saying garbage in = garbage out.
An rtl sim is a pretty good garbage filter.
It is only sufficient with a well-tested set of design rules.
> In the past I have also come across instances where simulation has taken so
> long, and created such large files, that reality has been quicker with a few
> debugging flags in the code!
I have worked on projects where a few debugging
flags in the code would never have found
all of the logical errors.
A good testbench doesn't produce large files.
It reports pass or fail.
-- Mike Treseler
Article: 141529On Jun 26, 8:28=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Antti.Luk...@googlemail.com <Antti.Luk...@googlemail.com> wrote: > > (big snip) > > < scenarion 1: > < start programming, erase, write sync written, POWER OFF, POWER ON FPGA > < ---> PUFFFF BLOW UP > > < the above is not 1:MIO odds case or is it? > > < now, i did include partial info, not only 11111 but also "just bad" > < bit file can damage > < i mean bit files that are INVALID, without proper CRC and trailer > > < and this seems to be so SEVERE and common to happen, that xilinx > < issued special case HOW TO WRITE FLASH > < (in order to prevent blow up) > > I had thought that previous FPGA families (I might be remembering > XC4000 series) didn't exit reconfiguration mode until a valid CRC > was seen. =A0That would make it unlikely that a random or incomplete > bit stream would cause damage. =A0It seems that isn't the case anymore. > > -- glen yes, ASFAIK all FPGA's except Spartan-6 remain in CONFIG mode until valid CRC and post-amble... well, i think it all is really ES errata but for some reason there is no errata sheet available, and it is described in regular datasheet AnttiArticle: 141530
Hi! Does anyone would accept to sell to me his good old Live Design kit by Altium ? Actually, Altium does not sell it anymore :-( and I need one board. Please contact denis.vion@laposte.net Thank you. DenisArticle: 141531
Hello, I am using XC9572XL High Performance CPLD. Just for a try i wrote simple program just to equate input to output. The code is synthesized but when I try to download code on CPLD through iMPACT it fails. Then I checked with all other options. Device is detected and erased properly but 1. Checksome fails 2. functional test fails. Error -- ERROR:iMPACT:431 - '1':No vectors present. ERROR:iMPACT:432 - '1':Functional test terminated Please help me out. Regards SanikaArticle: 141532
Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote: (snip) > yes, ASFAIK all FPGA's except Spartan-6 remain in CONFIG mode > until valid CRC and post-amble... > well, i think it all is really ES errata > but for some reason there is no errata sheet available, and it is > described in regular datasheet Without making too many guesses about the internal structure of FPGAs, it might take fewer transistors if some internal signals are active as the bits are loaded. It sounds like zeros are good and ones are bad. -- glenArticle: 141533
"Aldorus" <him@hereonearth.com> wrote in message news:EFQ0m.184232$2p1.60648@en-nntp-08.dc1.easynews.com... >> I connected pins 1, 2 and 44 to ground as the pin report suggested and >> it worked for me. > > pin report? > theres a seperate pin report from the Quartus II software? > where? > would it be there if i assigned the pins manually? > I have a .pin file in the project folder.Article: 141534
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote:
>(big snip)
>
>< scenarion 1:
>< start programming, erase, write sync written, POWER OFF, POWER ON FPGA
>< ---> PUFFFF BLOW UP
>
>< the above is not 1:MIO odds case or is it?
>
>< now, i did include partial info, not only 11111 but also "just bad"
>< bit file can damage
>< i mean bit files that are INVALID, without proper CRC and trailer
>
>< and this seems to be so SEVERE and common to happen, that xilinx
>< issued special case HOW TO WRITE FLASH
>< (in order to prevent blow up)
>
>I had thought that previous FPGA families (I might be remembering
>XC4000 series) didn't exit reconfiguration mode until a valid CRC
>was seen. That would make it unlikely that a random or incomplete
>bit stream would cause damage. It seems that isn't the case anymore.
I did destroy two Spartan2 devices while developing a JTAG download
implementation and numerous times a chip got very hot.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 141535sanika wrote: > Hello, > I am using XC9572XL High Performance CPLD. Just for a try i wrote simple > program just to equate input to output. The code is synthesized but when I > try to download code on CPLD through iMPACT it fails. Then I checked with > all other options. Device is detected and erased properly but > 1. Checksome fails > 2. functional test fails. > > Error -- > > ERROR:iMPACT:431 - '1':No vectors present. > ERROR:iMPACT:432 - '1':Functional test terminated > > Please help me out. If you don't write the test vectors yourself, or use a program to create them, then there are no test vectors to test the chip against. Functional test applies a stimulus to the chip and observes for correct output. You probably just want to readback the programming pattern to verify correct programming, but impact does that every time anyway. JonArticle: 141536
Has anyone else here used the "Universal File Writer" to merge bitstreams? I have a project that loads two ECP2 devices from one SPI flash, so I need to create the merged file. The problem is that the UFW GUI has no option to save my settings, so each time I change either project I need to re- browse to my bitstreams, and output file, as well as change all the required settings (bitstream output type, CCLK frequency, etc.). Needless to say this is a bit of a pain, and it could become more so if someone else ever needs to update the project (including me if it is long enough from now that I don't remember all the settings). So my thought was to look up how to run the UFW from the command line and make a batch file. The problem is that my command line causes the UFW to crash (an error has occurred, do you want to tell Microsoft about it, etc.). Here's my command line: <tools_path>\ispUFW.exe -if "<fpga1>.bit" "<fpga2>.bit" -oft -merge - of "<merged>.mcs" -format intel -frequency 34 -merge_format intelligent Filenames have been changed to protect the innocent :) When I attempt to run it I get a log file before the crash, but it only seems to get as far as loading the first bitstream, or perhaps only reading the command line parameters: Lattice Semiconductor Corporation Universal File Writer V2.44 Tue Jun 23 08:48:11 2009 Generating Bitstream..... Tue Jun 23 08:48:11 2009 Reading Input File: <fpga1>.bit Tue Jun 23 08:48:11 2009 Merge Format: Intelligent I'm using ispLever 7.0 I tried using complete paths and relative paths to the files with no change in the outcome :( Any help would be appreciated. Regards, GaborArticle: 141537
On Jun 27, 4:29=A0am, "Antti.Luk...@googlemail.com" > the above is not 1:MIO odds case or is it? > > now, i did include partial info, not only 11111 but also "just bad" > bit file can damage > i mean bit files that are INVALID, without proper CRC and trailer See Ed's post. Is this a case of a step-back in the Silicon, or a Step back in the DOCs ? Did they explicitly say the CRC check was bypassed ? ["is possible to damage an FPGA with a badly corrupted bitstream, but it takes more than a sync word followed by ones to do this. "] Is that 'design-corrupted', but with a valid CRC ? -jgArticle: 141538
On Jun 26, 12:29 pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Jun 26, 7:04 pm, Prevailing over Technology <steve.kn...@prevailing- > > technology.com> wrote: > > On Jun 24, 12:14 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > Bitstreams must not contain a sync word followed by all 1=92s. This > > > condition might > > > cause damage to the device. > > > > Is this an feature or bug? should this go into ERRATA and be fixed > > > ASAP?? > > > > Antti > > > Hmm, I put this in the same category as a warning stating "DO NOT > > CRAWL ACROSS BROKEN GLASS." I see it more as a matter of "warning, and don't blame us if...". I'm sure this doesn't happen often and when it does it is not in any way intentional or even inadvertent as in, "I didn't think to prevent that...". I can only think this would be a real fluke, but if your $1000 chip fries because of such a fluke, someone is going to ask you a few questions. But then I guess there are no $1000 Spartans, eh? BTW, aren't you the guy I owe a punch in the nose... er, I mean a pint of beer? I think you told me that Xilinx "was committed to supporting partial reconfiguration in the Spartan 3 devices". That wouldn't be why you fled Xilinx would it? ;^) > > What are the odds of "accidentally" sending a sync. word followed by a > > few million '1' bits? I'm sure that someone must have done it, hence > > the errata notice. I'm not sure this would be worth a $1M mask spin > > to fix (unless there are more important issues as well). > > > You can damage lots of semi's by misprogramming them. Have the > > outputs from two interface devices fight on a bus and just watch the > > gladiatorial fun! > > > -- Steve Knapp > > Prevailing Technology, Inc. > > www.prevailing-technology.cm > > its not that, only 11's > you did not read all the fine print > > scenarion 1: > start programming, erase, write sync written, POWER OFF, POWER ON FPGA > ---> PUFFFF BLOW UP > > the above is not 1:MIO odds case or is it? > > now, i did include partial info, not only 11111 but also "just bad" > bit file can damage > i mean bit files that are INVALID, without proper CRC and trailer > > and this seems to be so SEVERE and common to happen, that xilinx > issued special case HOW TO WRITE FLASH > (in order to prevent blow up) I was with you up to this point. "so SEVERE"??? That is a matter of damned if they do and damned if they don't. The fact that Xilinx has pointed out a flaw and even taken steps to help users prevent the inadvertent misuse of the parts certainly shouldn't be used against them. There has always been the possibility of a bad bit stream getting past the security logic and doing damage to a chip. Ed's post above seems to be saying that the reports of the Spartan-6's death has been greatly exaggerated. > so from Xilinx docs for S-6 > > procedure for writing nv memories for S-6 > ERASE > skip over sync (do not write it), WRITE the bitstream > seek back, write SYNC > > for any other FPGA except S-6 this like procedure for configuration > memory is not required or recommended > > ASFAIK at least > > of course it is possible to write KNOWN BLOW UP MY FPGA bitstream, but > those would be > valid bitstreams that will overstress the silicon, but INVALID > bitstreams (that should not release > the FPGA to be functional) should not damage the FPGA... How does the chip know a valid bitstream from an invalid one? There are always bitstreams that the logic can't see as invalid, good checksum but bad configuration bits. RickArticle: 141539
-jg wrote: > On Jun 27, 4:29 am, "Antti.Luk...@googlemail.com" >> the above is not 1:MIO odds case or is it? >> >> now, i did include partial info, not only 11111 but also "just bad" >> bit file can damage >> i mean bit files that are INVALID, without proper CRC and trailer > > See Ed's post. > Is this a case of a step-back in the Silicon, or a Step back in the > DOCs ? > Did they explicitly say the CRC check was bypassed ? > > ["is possible to damage an FPGA with a badly corrupted bitstream, but > it takes more than a sync word followed by ones to do this. "] > > Is that 'design-corrupted', but with a valid CRC ? > > -jg Assuming that the bitstream information is correct up until the real configuration frame data starts, damage may occur with a corrupted bitstream after that point. Loading all ones can be particular problematic as most configuration cells are active high. Configuration of an FPGA is a continual process and as each frame is filled the data is written in to the actual configuration cells. If a corrupt bitstream starts connecting multiple drivers with different states to the same nets then contention can occur and damage may result if the contention is severe enough and left in that state for long enough. The CRC check at the end of the bitstream won't avoid the contention as it is already occurring in the device. Back in the original Virtex days, we had one customer that had poor source code control and communication between designers and board techs coupled with different die sizes on the same board. On more than one occasion the bitstreams were loaded into the wrong device leading to catastrophic failure of the device. This was fixed in all future families with additional header information and configuration state machine logic to prevent the wrong bitstream from being loaded. Spartan-6 is as robust in this area than previous Spartan families. Ed McGettigan -- Xilinx Inc.Article: 141540
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:h233ph$de8$1@naig.caltech.edu... > It sounds like zeros are good and ones are bad. > That's been my experience too...it's due to the pointy-ness of the 1. Those 1s can nick some of the internals of the FPGA which can lead to internal shorts between power and ground. If you have a bitstream with ~million or so 1s in them you have a fairly good chance of running into this problem. The 0s have no sharp edges and generally load just fine, the only problem can be if some of them inadvertantly become Os which can get stuck in the bitstream causing blockage and a bloating of the device which will then fail to load. KJArticle: 141541
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: < Assuming that the bitstream information is correct up until the real < configuration frame data starts, damage may occur with a corrupted < bitstream after that point. Loading all ones can be particular < problematic as most configuration cells are active high. Given that many programmable memories clear to 1's, it would have been convenient to include an inverter such that 1's were safer than 0's. I remember in the early EPROM days, I believe the 1702 cleared to zeros, and then the 2708 cleared to ones. Zero was convenient for processors with NOP at X'00'. -- glenArticle: 141542
Kolja <ksulimma@googlemail.com> wrote in news:02857ee3-ab27-4bb9-835e- 01eb0518f323@j14g2000vbp.googlegroups.com: > On 10 Jun., 10:44, recoder <kurtulmeh...@gmail.com> wrote: >> Dear All, >> We have implemented a high speed qpsk demodulator in a FPGA >> demodulator board. >> Until now we fed the I and Q inputs from another board by wire. >> Now we are looking for an IF board that can take a 70 Mhz RF signal >> and output the I and Q signals to be fed to our FPGA board. >> Can anybody recommend one? >> Thanx in advance > > > Kolaj Sulimma > We have a board like this based on either ADI AD9238 or ad9248. It interfaces with a ADSP-21369 SHARC and Cyclone III combo http://www.danvillesignal.com/dspblok/dspblok-a9238-analog-devices-ad9238-hi- speed-adc-i/o-board.html Al Clark Danville SignalArticle: 141543
On Jun 27, 3:22=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > -jg wrote: > > On Jun 27, 4:29 am, "Antti.Luk...@googlemail.com" > >> the above is not 1:MIO odds case or is it? > > >> now, i did include partial info, not only 11111 but also "just bad" > >> bit file can damage > >> i mean bit files that are INVALID, without proper CRC and trailer > > > See Ed's post. > > Is this a case of a step-back in the Silicon, or a Step back in the > > DOCs ? > > Did they explicitly say the CRC check was bypassed ? > > > ["is possible to damage an FPGA with a badly corrupted bitstream, but > > it takes more than a sync word followed by ones to do this. "] > > > Is that 'design-corrupted', but with a valid CRC ? > > > -jg > > Assuming that the bitstream information is correct up until the real > configuration frame data starts, damage may occur with a corrupted > bitstream after that point. Loading all ones can be particular > problematic as most configuration cells are active high. > > Configuration of an FPGA is a continual process and as each frame is > filled the data is written in to the actual configuration cells. If a > corrupt bitstream starts connecting multiple drivers with different > states to the same nets then contention can occur and damage may result > if the contention is severe enough and left in that state for long > enough. =A0 The CRC check at the end of the bitstream won't avoid the > contention as it is already occurring in the device. > > Back in the original Virtex days, we had one customer that had poor > source code control and communication between designers and board techs > coupled with different die sizes on the same board. =A0On more than one > occasion the bitstreams were loaded into the wrong device leading to > catastrophic failure of the device. =A0This was fixed in all future > families with additional header information and configuration state > machine logic to prevent the wrong bitstream from being loaded. > > Spartan-6 is as robust in this area than previous Spartan families. > > Ed McGettigan > -- > Xilinx Inc. Ed, this can not be, see SYNC + 1111.... will not even start the configuration as there is no valid pre-amble and frame header !!!! so ___none___ of the 1's following the SYNC actually change any bits of the internal configuration ram at all...(so FPGA should stay fully UNCONFIGURED!) if such event still is dangerous, it is more likely similar to the NBTI problem in Virtex-4 where silicon was damaged if POWERED and NOT CONFIGURED so now silicon gets damaged if SYNC seen, but no valid bitstream seen well, this is how i understand the documentation the way the it is published. maybe its error in documentation or in my understanding AnttiArticle: 141544
On Jun 26, 10:49=A0pm, Gabor <ga...@alacron.com> wrote: > Has anyone else here used the "Universal File Writer" to merge > bitstreams? > > I have a project that loads two ECP2 devices from one SPI flash, so I > need > to create the merged file. =A0The problem is that the UFW GUI has no > option > to save my settings, so each time I change either project I need to re- > browse > to my bitstreams, and output file, as well as change all the required > settings (bitstream output type, CCLK frequency, etc.). =A0Needless to > say this is a bit of a pain, and it could become more so if someone > else > ever needs to update the project (including me if it is long enough > from now that I don't remember all the settings). > > So my thought was to look up how to run the UFW from the command > line and make a batch file. =A0The problem is that my command line > causes the UFW to crash (an error has occurred, do you want to > tell Microsoft about it, etc.). =A0Here's my command line: > > <tools_path>\ispUFW.exe -if "<fpga1>.bit" "<fpga2>.bit" -oft -merge - > of "<merged>.mcs" -format intel -frequency 34 -merge_format > intelligent > > Filenames have been changed to protect the innocent :) > > When I attempt to run it I get a log file before the crash, but it > only seems > to get as far as loading the first bitstream, or perhaps only reading > the > command line parameters: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Lattice Semiconductor Cor= poration > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Universal File Writer V2.= 44 > > Tue Jun 23 08:48:11 2009 =A0Generating Bitstream..... > Tue Jun 23 08:48:11 2009 =A0Reading Input File: <fpga1>.bit > Tue Jun 23 08:48:11 2009 =A0Merge Format: Intelligent > > I'm using ispLever 7.0 > > I tried using complete paths and relative paths to the files with no > change in the outcome :( > > Any help would be appreciated. > > Regards, > Gabor write your own merge tool, its less time than troubleshooting vendor tools that crash AnttiArticle: 141545
Thanks But what could be the reason for program fail..Is CPLD faulty in that case? Regards SanikaArticle: 141546
seems some V6 boards have been shipped, here http://sls.smugmug.com/gallery/5440422_Wj6jD#524855270_G47y9 pricing for the FPGA, also available online http://www.abnuniversal.ru/catalog/details/40546930.htm pricing for s/v 6: "The Spartan-6 family is priced at between about $3 and $54 in high volume of 10,000 units, according to Brent Pryzbus, director of product marketing. The Virtex-6 range is priced at between $50 and $2,000, depending on FPGA logic capacity and volume." now, problems is WHEN:( XC6SLX4 (assumed this is the 3$ device) was intially planned with 16KB BRAM, latest doc say it should have 24KB and for ISE 11.2 does NOT support SLX4, it is just not available and the VERY first design i used to benchark resource useage S3 vs V6 it FROZE running delay-based LUT packing... goes forever.. hmm idea maybe it will finish by the time S6 become available? too bad i can not leave this computer running on this process and wait up i wonder how can it be that Xilinx claims they DO TEST their software if it really runs to fatal failure with the FIRST design i try out? oh, well i guess there will be SP released before any 6 devices go to the distributors, so xilinx has still time to fix the new 11.2 bugs hum, the ONLY small package (CFP196) for S6 is also not supported by 11.2 hopefully the package will be available at some time AnttiArticle: 141547
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:5649564a-20b0-495f-8dfc-d3e8114df2d9@j19g2000vbp.googlegroups.com... > seems some V6 boards have been shipped, here > > http://sls.smugmug.com/gallery/5440422_Wj6jD#524855270_G47y9 > > pricing for the FPGA, also available online > http://www.abnuniversal.ru/catalog/details/40546930.htm > > pricing for s/v 6: > > "The Spartan-6 family is priced at between about $3 and $54 in high > volume of 10,000 units, according to Brent Pryzbus, director of > product marketing. The Virtex-6 range is priced at between $50 and > $2,000, depending on FPGA logic capacity and volume." > > now, problems is WHEN:( > > XC6SLX4 (assumed this is the 3$ device) was intially planned with 16KB > BRAM, latest doc say it > should have 24KB > > and for ISE 11.2 does NOT support SLX4, it is just not available > > and the VERY first design i used to benchark resource useage S3 vs V6 > it FROZE > > running delay-based LUT packing... > > goes forever.. hmm idea > > maybe it will finish by the time S6 become available? > too bad i can not leave this computer running on this process and wait > up > > i wonder how can it be that Xilinx claims they DO TEST their software > if it really runs to fatal failure with the FIRST design i try out? > > oh, well i guess there will be SP released before any 6 devices go to > the distributors, so xilinx has still time to fix the new 11.2 bugs > > hum, the ONLY small package (CFP196) for S6 is also not supported by > 11.2 > hopefully the package will be available at some time > > Antti Hi Antti - why do you get worked up over X - I started with them when 100 Logic Blocks was the biggest part they made but gave about three years ago when it became apparent that no matter who I spoke to at X or dealers it was just impossible to tell which bits they actually made and where I could buy them. I moved over to Lattice and the FPGA part of my life is much nicer since. Michael KellettArticle: 141548
On Jun 27, 12:40=A0pm, "MK" <m...@nospam.please> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:5649564a-20b0-495f-8dfc-d3e8114df2d9@j19g2000vbp.googlegroups.com... > > > > > seems some V6 boards have been shipped, here > > >http://sls.smugmug.com/gallery/5440422_Wj6jD#524855270_G47y9 > > > pricing for the FPGA, also available online > >http://www.abnuniversal.ru/catalog/details/40546930.htm > > > pricing for s/v 6: > > > "The Spartan-6 family is priced at between about $3 and $54 in high > > volume of 10,000 units, according to Brent Pryzbus, director of > > product marketing. The Virtex-6 range is priced at between $50 and > > $2,000, depending on FPGA logic capacity and volume." > > > now, problems is WHEN:( > > > XC6SLX4 (assumed this is the 3$ device) was intially planned with 16KB > > BRAM, latest doc say it > > should have 24KB > > > and for ISE 11.2 does NOT support SLX4, it is just not available > > > and the VERY first design i used to benchark resource useage S3 vs V6 > > it FROZE > > > running delay-based LUT packing... > > > goes forever.. hmm idea > > > maybe it will finish by the time S6 become available? > > too bad i can not leave this computer running on this process and wait > > up > > > i wonder how can it be that Xilinx claims they DO TEST their software > > if it really runs to fatal failure with the FIRST design i try out? > > > oh, well i guess there will be SP released before any 6 devices go to > > the distributors, so xilinx has still time to fix the new 11.2 bugs > > > hum, the ONLY small package (CFP196) for S6 is also not supported by > > 11.2 > > hopefully the package will be available at some time > > > Antti > > Hi Antti - why do you get worked up over X - I started with them when 100 > Logic Blocks was the biggest part they made but gave about three years ag= o > when it became apparent that no matter who I spoke to at X or dealers it = was > just impossible to tell which bits they actually made and where I could b= uy > them. > =A0I moved over to Lattice and the FPGA part of my life is much nicer sin= ce. > > Michael Kellett ROTFL eh you are not the first one, telling about the same I am free, free to use any parts from any vendors, but some work i do get paid for is with Xilinx parts, and some friends need help with Xilinx, so yeah giving up Xilinx fully would make life easier of course, less bugs and worries but life isnt meant to be so easy all the time, so i still struggle with Xilinx too (still have to..) but if comparing just the features, Xilinx is not the first choice for many different types of projects, and from many different reasons. AnttiArticle: 141549
On Jun 27, 12:22=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > The CRC check at the end of the bitstream won't avoid the > contention as it is already occurring in the device. Interesting. So when the CRC finally trundles into the device some ms later, does that 'disable' config and save the possible contention ? - if not, what exactly is the CRC for (given that config occurs prior to it arriving) ? -jg
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