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
Ben Twijnstra wrote: > Hi Rick, > > What about Arrow? > One of the worst distributors here besides Memec... Can try..but takes probably at 1 or 2 weeks until they reply (o; rickArticle: 86451
Joseph H Allen wrote: > So... you should make the entire design in just one always block? :-) It can be done. http://www.designabstraction.co.uk/EXAMPLE/HTML/verilog.htm -- Mike TreselerArticle: 86452
Antti Lukats wrote: > with some trick a RAM based FPGA can be made secure as well but generically > its nogo for security related stuff No tricks. > XP10 is available. When I asked a disti (WBC) where I could get XP, the > answer was "from me", ie the disties are able to ship immediatly. And what is the price of LFXP3? This chip seems to be very promising and if it is less than 30$, it would be perfect. > I guess, any comment: "comparable to Quartus" is understood as > VERY bad insulting comment in the Xilinx side of the world. :o))) Quartus is extremely good (but quite slow), especially the full version, and since Xilinx is a really big player, I anticipate that their software is also very good, however I have no experience with ISE. It's a compliment, not an insulting comment. ;-) > expensive, yes expect any V4 to be >=100USD Too much for this application. Thank you for your comment, PiotrArticle: 86453
Vladislav Muravin wrote: > In the past, we had to choose FPGAs for ASIC prototyping and I was greatly > disappointed by Altera tools Well, I'm amazed by Quartus. :-) > Yes, Altera tools, but not FPGAs! FPGAs are always extraordinary stuff, > regardless of their vendor! ProASIC+ LEs cannot compute multi-input xors -- big disappointment. :-( Only one RAM read port: even bigger disappointment. > yet it still has some completely useless warnings. Generally, I prefer 100 not important warnings than the lack of one, important. :-) > If you are not planning massive production and you need only a few units, > think no further. Today I need only a prototype, but I am not planning mass production, at most 1000 devices in the best case. Best regards Piotr WyderskiArticle: 86454
allanherriman@hotmail.com wrote: > I'm curious. Why do you need an FPGA with bitstream encryption? Because I need a safe place to store the symmetric key. The best option would be to store it inside the chip, but it can't be done using a SRAM-based device. So the best I can do is to store it in an external encrypted memory. But since the device has volatile configuration memory, the decoder (and its key!) must also be encrypted. The best soulution would teleport the key from a smartcard directly into the FPGA, but no such technology is available... ;-) Best regards Piotr WyderskiArticle: 86455
Comment: -snip- >>expensive, yes expect any V4 to be >=100USD > > > Too much for this application. > Virtex 4 in the smaller parts (LX15, LX25, FX12) are all less than $100 (based on forward pricing in quantities, see the various press releases). If this is a hobby project, then you are better off going to the Xilinx web store and buying a Spartan 3 (or buying the Digilent S3 pcb complete). AustinArticle: 86456
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> schrieb im Newsbeitrag news:d9roji$rlv$1@panorama.wcss.wroc.pl... > Antti Lukats wrote: > > > with some trick a RAM based FPGA can be made secure as well but > generically > > its nogo for security related stuff > > No tricks. > > > XP10 is available. When I asked a disti (WBC) where I could get XP, the > > answer was "from me", ie the disties are able to ship immediatly. > > And what is the price of LFXP3? This chip seems to be very promising > and if it is less than 30$, it would be perfect. I dont have pricing handy, but from face to face talk, the Lattice person promised to meet any Xilinx S3 price for comparable density for EC, and XP is projected 10% more than EC. Well there was a small misunderstanding at the conversation, when I mentioned the S3-1000 price then Lattice said at first that they would not get that price, but he heard me wrong, I said 16, and it was understood a 6 (EUR), so as per Lattice direct promise they have no problems with 16EUR price for a device that is comparable to s3-1000, but they would not give it for 6 :( I can not guarantee what price you will actually get, but check them out. Notice that the only device from XP currently available is XP10. Just say that your target price is $30 and force them (nicely) to meet the price. As they don not have any other silicon to offer rigth now as XP10 I am sure you will get XP10 priced to meet your target price. > > I guess, any comment: "comparable to Quartus" is understood as > > VERY bad insulting comment in the Xilinx side of the world. > > :o))) > > Quartus is extremely good (but quite slow), especially the full version, > and since Xilinx is a really big player, I anticipate that their software is > also very good, however I have no experience with ISE. It's a compliment, > not an insulting comment. ;-) > > > expensive, yes expect any V4 to be >=100USD > > Too much for this application. > > Thank you for your comment, Piotr >Article: 86457
Thanks Ben! >From my existing testing the inner loop will be iterated all 50,000,000 times on >99.9% of runs. Even if I do one loop per clock cycle (highly unrealistic) on the 50MHz Spartan-3 I' looking at one test per second per siever, and only 512bits going in and out of the siever per test. There's no memory access whilst in the main loop so I mind if it's a bit slow grabbing data or returning results. As for the memory the main chip (XC3S200FT256) has 12 18kbit block RAM (216K bits) the board comes with a 1M-Byte SRAM (in two 256Kx16 chips) on the back. No SDRAM to worry about. Ta. -AlexArticle: 86458
Good point: A lot of folks get the issues of security and encryption all mixed up. Why, in fact, do you need anything at all? Best to start from the beginning, and build your requirements from the basics. What is needed? Do you need to authenticate (is this the system to whom I am speaking....)? Do you need to pass secure keys (update keys in an insecure channel)? There are many things which are really nice, and clever, but are they needed? Who is the attacker? Will they have physical access? I am guessing that Piotr has thought all this through, so I will not question his requirements. If local secure storage is required for information (pads, session keys, etc.), and the attacker has physical access, then one way to maintain security is to use a device with encrypted bitstreams, as readback is prohibited when the decryptor is being used (in V2, V2P, V4). Austin Piotr Wyderski wrote: > allanherriman@hotmail.com wrote: > > >>I'm curious. Why do you need an FPGA with bitstream encryption? > > > Because I need a safe place to store the symmetric key. The > best option would be to store it inside the chip, but it can't be > done using a SRAM-based device. So the best I can do is to > store it in an external encrypted memory. But since the device > has volatile configuration memory, the decoder (and its key!) > must also be encrypted. The best soulution would teleport > the key from a smartcard directly into the FPGA, but no such > technology is available... ;-) > > Best regards > Piotr Wyderski > >Article: 86459
Rudolf Usselmann wrote: > What cypher are you going to use ? 128 bit AES and a good hashing method to generate "session" keys. > We are getting about 20 Gbps in a Virtex 2 3000, for 1Gbps > you can get away in a Spartan 3. Exactly, even the smallest Cyclone, 1C3-8, would perform this task easily. But there is no way to send the key securely to the FPGA and hence my favourite FPGA family can't be used. > My guess is that you can do 1 Gbps in any low cost/low end > FPGA with the right architecture ... The problem is not with a proper implementation, I can do it easily, but with the word "any". ;-) Any low cost SRAM -based FPGA has enough performance, but there is no way to store the key securely (there's no "secure environment" and no secure communication channel between the scrambler and a smart card, so I can't just send the key and I can't send an encrypted version of the key, because the majority of available chips is unencrypted, i.e. it's impossible to implement a secure key exchange protocol). Flash-based and SRAM-based devices have no such problem, you can store the "auxilary" key(s) inside the chip. Best regards Piotr WyderskiArticle: 86460
Laurent Gauch wrote: > Piotr wants to do crypto in the FPGA. Also, he certainly needs secret > keys inside the FPGA for working with digital crypto (speudo). Piotr > needs FPGA bitstream encryption to make sure the secret key is safe EXACTLY! :-) > and to protect his design and encryption method ! Well, there's no need to protect these parts of my design. Only the secret key must be stored in an extremely secure location, because there's no way to change the key. Best regards Piotr WyderskiArticle: 86461
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:d9rpon$lbe1@cliff.xsj.xilinx.com... > Comment: > > -snip- > > >>expensive, yes expect any V4 to be >=100USD > > > > > > Too much for this application. > > > > Virtex 4 in the smaller parts (LX15, LX25, FX12) are all less than $100 > (based on forward pricing in quantities, see the various press releases). > > If this is a hobby project, then you are better off going to the Xilinx > web store and buying a Spartan 3 (or buying the Digilent S3 pcb complete). > > Austin Hi Austin, I think my estimate was more realistic, it is for the small volume project (at least the way I understood the OP) and I did mean pricing as of today. Sure the prices for the devices you mentioned do fall below $100 margin, some day in some qty. But for buying small qty of V4 as of today I would expect near 100$ pricing or am I mis understanding the pricing policy? I dont remember seeing V4 price forecasts going much lower than $80 USD for 5-10k yearly volumes. Sure I would welcome a lower pricing :) as of 1 off testing, it sure makes sense to buy a low cost kit for evaluation, here are you absolutly right AnttiArticle: 86462
How much do you want to spend? Which brand of FPGA (Altera or XIlinx)? What other features needed - DVI in/out Analog out? I am working on a board with DVI In/out, RGB analog in/out, It will have 2, Xilinx 3S400's on it.Article: 86463
allanherriman@hotmail.com wrote: > 'Doing crypto' does not imply a requirement for bitstream encryption. Of course, but... > One needs to change the keys from time to time ... here it is impossible. No frequent key updates, no forward secure protocols, nothing can be used. Only a secure key storage is allowed, which means a physically secure storage, i.e. storing the key in an FPGA or at least an external, unprotected storage with encrypted contents. > so they can't be part of the bitstream. Unencrypted bitstreams can be modified (it doesn't mean reserse engineering of the chip, just simply modify several bits of the bitstream and update the CRC) and then the "enemy" can analyse the errors produced by the chip to reconstruct the key. It's one of the simplest methods of breaking (wanna be) secure devices -- no extensive number crunching etc., is needed, just "inject" some bugs into the chip, record the results and then extract statistical correlations between the errors and the key bits. > IP protection makes sense There's no particularly valuable IP to protect. Best regards Piotr WyderskiArticle: 86464
Hi Xilinx answer record 21127 and related information, - I am still a little unsure if I did understood it all correctly and what the actual impact of the NBTI issues actually are. I have had some trouble with DCM lately, so I am little bit more worried, AR21127 says that if the V4 is powered but not configured the DCM performance will start to degrade (there are actuall changes of the silicon!), but this process is reversable, like self healing so if the V4 is later powered and configured for the same amount of time then DCM performance will slowly be restored to be inside the specification again. We have a design were we really can not guarantee that the V4 is configured withing 10 minutes from power on, as the bitstream is on removeable media and the media may not be inserted or may not contain a valid bitstream. I also have 2 LX25 based boards and both have been poered and not configured for some time, I wonder if I should start healing the boards or maybe the DCMs have not been damaged at all. So a direct question: The DCM performance degration when powered and not configured, is it damging the silicon or not? And if it is, is it fully self healing (unlimited number of times, unlimited time of being powered and not configured) or is there some limit how many times the V4 can self heal itself? or maybe somebody has a better explanation how to understand this issue. Also little more worring is the fact that AR21127 promises the 'workaround' macros for V4 for the case of low DCM input frequency to be available in mid June, but they are still not available, its now 28 june in Europe I guess its past 'mid-June' on the US westcoast as well. Is there anyone around who could clarify the issue once and for all? Austin, can you comment please? AnttiArticle: 86465
Austin Lesea wrote: > Virtex 4 in the smaller parts (LX15, LX25, FX12) are all less than $100 Still three times too much, Virtex4 chips are just to big, the goal is to design a device with the price of less than ~$70 @ 1000 specimen. But this must include a smart card, a small PCB, several connectors and wires etc., so the chip should cost below $30. > If this is a hobby project Well, it isn't, or better: it should not end up as a non-profit project. It's current status is "small research project". Best regards Piotr WyderskiArticle: 86466
Austin Lesea wrote: > Best to start from the beginning, and build your requirements from the > basics. I have all of them. > Do you need to authenticate (is this the system to whom > I am speaking....)? Yes, definitely. > Do you need to pass secure keys (update keys in an > insecure channel)? Yes. > Who is the attacker? A company with the budget of 20--100k$. > Will they have physical access? To the PCB: yes, virtually unlimited, but they will have no access to the die. > I am guessing that Piotr has thought all this through, so I will not > question his requirements. Thank you. :-) Best regards Piotr WyderskiArticle: 86467
Antti Lukats wrote: > I said 16, and it was understood a 6 (EUR), so as per Lattice direct promise > they have no problems with 16EUR price for a device that is comparable to s3-1000 16EUR would be perfect, my sweet dreams come true. :-) > but they would not give it for 6 :( Actually, I wouldn't either. :-P Thank you Antti once again! It seems that I have to find a Lattice distributor in Poland and purchase a single XP chip.Article: 86468
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> schrieb im Newsbeitrag news:d9rt9f$6h$1@panorama.wcss.wroc.pl... > Antti Lukats wrote: > > > I said 16, and it was understood a 6 (EUR), so as per Lattice direct > promise > > they have no problems with 16EUR price for a device that is comparable to > s3-1000 > > 16EUR would be perfect, my sweet dreams come true. :-) > > > but they would not give it for 6 :( > > Actually, I wouldn't either. :-P > > Thank you Antti once again! It seems that I have to find > a Lattice distributor in Poland and purchase a single XP > chip. > check the disti, yes. but you are bette off to by the XP low cost eval board. the XP10 you would get in BGA and it doesnt makes sense togo doing anything with it. and íf you have some FPGA then you can simple test your design on whatever you have ready and at the same time verify that your design is also synthesizeable for XP using lattice tools. BTW the lattice tools look almost 100% the same as xilinx tools as they are both based on Neocad :) AnttiArticle: 86469
Antti, As usual, I will answer your questions below, Austin Antti Lukats wrote: -snip- > So a direct question: > > The DCM performance degration when powered and not configured, is it damging > the silicon or not? No, no damage at all. It is the classic NBTI Vt shift of the pmos devices (trapped charges). This is 30 years old. Nothing new here, except that the DCM balance for high frequency operation (anything greater than 300 MHz falls into this category because of the new differential balanced delay lines) is affected by non-use (ie the DCM is stuck at 0, or stuck at 1). The effect is slight, and only affects the DCM for high frequency mode. It also requires a high ambient temperature (like 85C). It also requires time. Any interruption or change allows recovery. And if it is, is it fully self healing (unlimited number > of times, unlimited time of being powered and not configured) or is there > some limit how many times the V4 can self heal itself? Unlimited. The time to shift back is roughly equal to the time to shift. The more shifting that goes on, the more the shift diminishes, and actually stops (becomes a total non-issue, all charge traps are filled). Just leaving the device unpowered allows shift back as well. The only way we were able to affect the operational specifications was in the burn in (>1000 Hrs, all Vcc's at ABS MAX, temp at ABS MAX). Taking one of these devices after burn-in, and using it for awhile, made it meet specifications again... > > or maybe somebody has a better explanation how to understand this issue. > > Also little more worring is the fact that AR21127 promises the 'workaround' > macros for V4 for the case of low DCM input frequency to be available in mid > June, but they are still not available, its now 28 june in Europe I guess > its past 'mid-June' on the US westcoast as well. Don't know about the availability of the macros. I do know that some of it is now built into the software (so you don't even need to know). The need for the work-around macros diminshes as we see that this issue is probably a complete NON ISSUE. Obviously, anyone who thinks they will be subjetc to this, please contact your FAE to discuss it in full. The last 10 discussions have resulted in "no problems" so I doubt you are affected, but one can never be sure. > > Is there anyone around who could clarify the issue once and for all? Austin, > can you comment please? Just did my best. As for 'once and for all,' I doubt I am that good. Anything more?Article: 86470
I am looking for a Future Electronics Cyclone NiosII Development Kit with a 1C12 Cyclone FPGA. It was on sale last month for $50 and sold out. Please respond to ppilabs@yahoo.com.Article: 86471
Hi Austin you are pretty good ! :) nothing more at the moment, thank you, Antti "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:42C17CE0.5040101@xilinx.com... > Antti, > > As usual, I will answer your questions below, > > Austin > > Antti Lukats wrote: > > -snip- > > > So a direct question: > > > > The DCM performance degration when powered and not configured, is it damging > > the silicon or not? > > No, no damage at all. It is the classic NBTI Vt shift of the pmos > devices (trapped charges). This is 30 years old. Nothing new here, > except that the DCM balance for high frequency operation (anything > greater than 300 MHz falls into this category because of the new > differential balanced delay lines) is affected by non-use (ie the DCM is > stuck at 0, or stuck at 1). The effect is slight, and only affects the > DCM for high frequency mode. It also requires a high ambient > temperature (like 85C). It also requires time. Any interruption or > change allows recovery. > > > And if it is, is it fully self healing (unlimited number > > of times, unlimited time of being powered and not configured) or is there > > some limit how many times the V4 can self heal itself? > > Unlimited. The time to shift back is roughly equal to the time to > shift. The more shifting that goes on, the more the shift diminishes, > and actually stops (becomes a total non-issue, all charge traps are > filled). Just leaving the device unpowered allows shift back as well. > The only way we were able to affect the operational specifications was > in the burn in (>1000 Hrs, all Vcc's at ABS MAX, temp at ABS MAX). > Taking one of these devices after burn-in, and using it for awhile, made > it meet specifications again... > > > > > or maybe somebody has a better explanation how to understand this issue. > > > > Also little more worring is the fact that AR21127 promises the 'workaround' > > macros for V4 for the case of low DCM input frequency to be available in mid > > June, but they are still not available, its now 28 june in Europe I guess > > its past 'mid-June' on the US westcoast as well. > > Don't know about the availability of the macros. I do know that some of > it is now built into the software (so you don't even need to know). > > The need for the work-around macros diminshes as we see that this issue > is probably a complete NON ISSUE. Obviously, anyone who thinks they > will be subjetc to this, please contact your FAE to discuss it in full. > The last 10 discussions have resulted in "no problems" so I doubt you > are affected, but one can never be sure. > > > > > Is there anyone around who could clarify the issue once and for all? Austin, > > can you comment please? > > Just did my best. As for 'once and for all,' I doubt I am that good. > Anything more? > :) no, question answered! AnttiArticle: 86472
Slightly off topic since I don't know this proth sieve If you are interested in trully huge primes, perhaps the mersenne primes search might be something to consider as background material. If you google comp arch group for FPGA Mersenne you should find a recent (1-2 month or so) mention about an engine that did huge 64 bit int FFTs on I think 2^24 points, this is used to do huge number arithmetic in shorter order. It used 384 18.18 muls on biggest V2Pro to drive the FFT kernal. The 64b math was needed to prevent loss of accuracy to do these huge muls needed for prime checking. The math was mostly beyond me but the FPGA HW was quite interesting. Ofcourse it turns out the memory management was the real problem here, if you can imagine doing a 2^24 pt 64 precision FFT. This must be some sort of Uni assignment right? better than what I was offered johnjakson at usa dot comArticle: 86473
Antti Lukats wrote: >Hi > >Xilinx answer record 21127 and related information, - I am still a little >unsure if I did understood it all correctly and what the actual impact of >the NBTI issues actually are. > >I have had some trouble with DCM lately, so I am little bit more worried, >AR21127 says that if the V4 is powered but not configured the DCM >performance will start to degrade (there are actuall changes of the >silicon!), but this process is reversable, like self healing so if the V4 is >later powered and configured for the same amount of time then DCM >performance will slowly be restored to be inside the specification again. >We have a design were we really can not guarantee that the V4 is configured >withing 10 minutes from power on, as the bitstream is on removeable media >and the media may not be inserted or may not contain a valid bitstream. I >also have 2 LX25 based boards and both have been poered and not configured >for some time, I wonder if I should start healing the boards or maybe the >DCMs have not been damaged at all. > >So a direct question: > >The DCM performance degration when powered and not configured, is it damging >the silicon or not? And if it is, is it fully self healing (unlimited number >of times, unlimited time of being powered and not configured) or is there >some limit how many times the V4 can self heal itself? > >or maybe somebody has a better explanation how to understand this issue. > >Also little more worring is the fact that AR21127 promises the 'workaround' >macros for V4 for the case of low DCM input frequency to be available in mid >June, but they are still not available, its now 28 june in Europe I guess >its past 'mid-June' on the US westcoast as well. > >Is there anyone around who could clarify the issue once and for all? Austin, >can you comment please? > >Antti > > > > > Antti, you can download the verilog macro from the website. In order to get the VHDL one, you have to ask. The VHDL one is not really ready, it has a number of things in it that won't synthesize properly under synplify. Both versions use a pair of counters that are asynchronously reset by a level on the incoming clock. The design has some potential metastability hazards, and because of the set up, I suspect won't detect clock presence reliably with higher frequency clocks. The design is also a little on the resource intensive side, and can be made quite a bit smaller by rethinking the clock detection and using a shift register for saving the calibration constants rather than lut ram (eliminates the addressing and decodes). The other issue is that you really need to jump through hoops to keep the macro from getting trimmed out during map if it is for an unused DCM. The patch in 7.1 puts the macro in after map, so that it doesn't get trimmed out, however, if the other gotchas in 7.1 are forcing you to 6.3 then you need to come up with a null DCM on your own (there is supposedly a strategic patch for 6.3, but I have not been able to find it yet).. Either way, you need to load a bitstream right away to avoid the NBTI all together. The function of the macro is actually rather simple. Basically, it has a clock sense circuit that detects missing clock in and missing feedback (you don't need the feedback detect logic if you are doing the feedback inside the FPGA). The sense logic in the macro is a little hokey, and uses more area than it needs to. A state machine basically waits for no clock to be detected, then it reads the DRP port on the DCM at addresses 42h, 51h and 4Eh and stores them in LUT RAM. It then writes "0000" to 4E, apparently this shuts off the DCM outputs, and then it cycles through 4 states in sequence that write values alternately to 42 and 51. These apparently tweak the internal calibration to keep the delay lines toggling. It continues to cycle through those 4 states until clock is restored (or reset is released). When that happens, it writes the stored values for 42,51 and 4E back into the DRP port, triggers a DCM reset and goes back to the initial state. I rewrote the macro using srl16s for the drp value storage (this eliminates the addressing logic), and used my own clock detection circuit that cuts the clock detection circut size to less than 30% of the original. I also cleaned up the state machine so that it is a single machine rather than a conglomeration of smaller machines. The clock for the detect circuit is a ring oscillator divided down to about 8 Mhz. Xilinx routes it on local routing rather than on a clock net, probably to avoid using up clock nets for designs that use a lot of clocks. I also made a null DCM macro which basically removes the clock detect logic, and alters the reset logic. -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 86474
Hello, I get a strange INFO message in ISE 7.1 that i have not got in ISE 6.x ------------------------------------------------------------------------------------ INFO:Par:252 - The Map -timing placement will be discarded and your design will be placed using the command line options specified in PAR. ------------------------------------------------------------------------------------ Can somebody explain to me why it is discarding timing driven packing & placement? Could it be that the highest place and route effort overrides timing driven packing & placement? Thanks Vladislav
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