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
Antti Lukats wrote: > > XAPP780 uses 2 unrelated on-chip ring oscillators to provide true random > tokens for the security challenge. > > those ringoscillators use directed routing constraints and fail to > synthesize :) > > Antti > > You can instantiate the primitives to obtain a ring oscillator without having to resort to directed routing. That way, the design can still be completely specified with your favorite HDL. Been there done that. The problem with ring oscillators implemented in the FPGA to obtain a random seed is that the ring oscillators on the same die will tend to synchronize through coupling of the parasitics, making the relative phases much less random than an analysis of just the primitives would indicate. I'm pretty sure Austin has noted this effect here before; I think Xilinx also saw the effect in the development of their chip testing. Coincidently, my sister is doing her Master's thesis on the randomness of random variables generated by a pair of ring oscillators on a Xilinx FPGA. She hasn't finished the research yet, so I can't tell you what her findings are. I suppose if you just used one sample long enough after configuration to allow the relative phases to get away from the starting point, but soon enough that the ring oscillators haven't synchronized to one another, you could get a decent random variable. What I don't know is the limits of that window where the results still have decent random properties. Perhaps it is good enough to generate a challenge.Article: 93151
jaxato@gmail.com wrote: > Actually I believe that the stream is different everytime the design > needs to authenticate. The protection ip contains some pseudo random > number gen and with this, has the ability to generate unique stream. It > would be too obvious to record and playback the same stream. > Right, but where is that PR generator getting its seed? If it starts with the same seed every time, it will produce the same sequence every time, and therefore the same challenge. There is nothing in the FPGA that comes up in a random state, so in order to have a non-deterministic challenge, you need to supply a random seed from outside the FPGA. Antti did mention using a pair ring oscillators to generate the random challenge, which will generate something that is not as deterministic as a digital pseudo random generator. The randomness of a RV generated by a pair of ring oscillators depends on the frequencies and phase of those oscillators being independent. When they exist on the same chip, the parasitics of the ring oscillator circuits will couple and tend to get them to sync up, so at least in the long term, the randomness may not pass a randomness test. Still, it is probably sufficient for seeding a PR generator.Article: 93152
Hi All, when I synthesize my design in xilinx project navigator, I get an error message, "ERROR:MapLib:681 - LOC constraint Y4 on SW<2> is invalid: No such site on the device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'. However when I open the Xilinx Pace editor, I can see that the pin exists. Does anyone know how to rectify this error. Thanks, ShanthaArticle: 93153
kl31n wrote: > The timing report tells me that I can run my block at 157MHz and I'm > running it at 100Mhz, so it has to be 330ns the latency(the core, being in > basic mode to take advantage of the handshaking, has a 33 cycles latency). > > By parallelizing to n dividers I expected I could pretend to have a latency > of (ceil(33 / n) * T), while I cannot get under 260ns and this with > whatsoever the number of dividers. Parallelizing units only speeds up the latency of the completion of multiple operations, but each operation still takes the same latency of when using just a single unit, no matter how many units are in parallel. For instance, one divider would take 66 cycles for 2 divides (at an average rate of 1 divide per 33 cycles), but 2 (or even 500) dividers would take 33 cycles for 2 divides (for an average rate of 16.5 cycles per divide). But in either case you don't get the first divide result in less than 33 cycles. If anything parallelizing units might actually slow down max single operation latency, due to wire load, muxing, buffering or pipelining required to fan-out operands and control signals to the multiple pipes, plus fan-in the results. And running the clock faster than worse case timing allows might only result in garbage. IMHO. YMMV. -- rhn A.T nicholson d.O.t C-o-MArticle: 93154
Benoit, You need to learn how to search Google groups! ;-) Look here for example code:- http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/b2e060b33fd0a0a2/c1a2d891c6d6ca77 HTH, SymsArticle: 93155
"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag news:cP%nf.30509$Mi5.16830@dukeread07... > Antti Lukats wrote: > > >> >> XAPP780 uses 2 unrelated on-chip ring oscillators to provide true random >> tokens for the security challenge. >> >> those ringoscillators use directed routing constraints and fail to >> synthesize :) >> >> Antti > > You can instantiate the primitives to obtain a ring oscillator without > having to resort to directed routing. That way, the design can still be > completely specified with your favorite HDL. Been there done that. > > The problem with ring oscillators implemented in the FPGA to obtain a > random seed is that the ring oscillators on the same die will tend to > synchronize through coupling of the parasitics, making the relative phases > much less random than an analysis of just the primitives would indicate. > I'm pretty sure Austin has noted this effect here before; I think Xilinx > also saw the effect in the development of their chip testing. > Coincidently, my sister is doing her Master's thesis on the randomness of > random variables generated by a pair of ring oscillators on a Xilinx FPGA. > She hasn't finished the research yet, so I can't tell you what her > findings are. I suppose if you just used one sample long enough after > configuration to allow the relative phases to get away from the starting > point, but soon enough that the ring oscillators haven't synchronized to > one another, you could get a decent random variable. What I don't know is > the limits of that window where the results still have decent random > properties. Perhaps it is good enough to generate a challenge. tuff guy :) yes I know the ways of doing ring oscillators too, done them in plenty of different ways - I just said that xapp780 uses directed routing what is not any more routable, there is no need in that. Another xilinx own design uses an approuch with 4 sr registers, that works with no constraints applied at all. the xap780 "random", well I havent looked it in so detail, but I think its not done the maximum possible true random, this may need the ring oscillator to be made way differently and have the frequencies and co-operation to be adjusted properly to achive the most true random out of it. I think that relativly good results can be actually achived. but no matter how it is done this approuch has way less protection when used with ngs or edif flow, in bitstream only version the protection level could be pretty high if all the system (the security challenge module, and its integration to the rest) is really designed properly. attachin some secure device to FPGA doesnt mean instantly that it makes the design secure, there could still be means of bypassing even without getting the keys ever pulled. AnttiArticle: 93156
Hi, I was trying to implement my design in Xilinx ISE using Xst as the Synthesis tool. It gave me a error INTERNAL_ERROR:Xst:cmain.c:3020:1.146 - To resolve this error, please consult the Answers Database and other online resources at <http://support.xilinx.com>. To give you a basic idea, my program is IF Generate Structures and my guess is this is causing the Xst to crash. I am unable to find any information about this particular error. Thanks, Ramakrishnan.Article: 93157
Are you using the latest ISE service pack? I don't know if any issues but Generates are newish and there has been a lot of improvements in recent versions of the tools. If it still persists, then file a webcase online with Xilinx: http://www.xilinx.com/support/clearexpress/websupport.htm Paul Ramakrishnan wrote: > > Hi, I was trying to implement my design in Xilinx ISE using Xst as the Synthesis tool. It gave me a error INTERNAL_ERROR:Xst:cmain.c:3020:1.146 - To resolve this error, please consult the Answers Database and other online resources at <http://support.xilinx.com>. To give you a basic idea, my program is IF Generate Structures and my guess is this is causing the Xst to crash. I am unable to find any information about this particular error. > > Thanks, > > Ramakrishnan.Article: 93158
The descriptions you give are accurate but the standard numbers are 1149.1 for boundary-scan and 1532 for in-system configuration. Both are published by the IEEE and can be purchased from the IEEE store. PeteS wrote: > Antti Lukats wrote: > >>"ABS" <abhishekbedi@gmail.com> schrieb im Newsbeitrag >>news:1134518668.567217.216410@o13g2000cwo.googlegroups.com... >> >>>hi all >>> >>>has anyone got any documents or refferals for 'J Tag Protocol ' , for >>>reconfigurable hardware. >> >>I bet almost anyone here has... >> >>but JTAG primary function is BOUNDARY SCAN and not hardware reconfiguration, >>even though lots (virtually all) current FPGA allow configuration over JTAG >>interface >> >> >>>i would appreciate if any tutorials or realted links/documents can b >>>passed on . >>>thanks >>>abhishek >>> >> > > On the grounds I want to find out if the OP is creatively lazy... > > The relevant specifications are: > > for pure JTAG (testing) IEEE 1149.1 - (year) [there are a number of > releases. Most devices comply with the 1994 release] > For In System programmable devices using JTAG > IEEE1532. Note that the 'BSDL' files for ISP specify the 1536 > compatibility (See Altera or Xilinx docs) > > For testing cores with 'standard' interfaces, such as EJTAG (MIPS) or > such as ARM core access, you would need to search for the specific > information. EJTAG and ARM core JTAG access protocols are published, > but not necessarily free. > Both 1149.1 and 1532 are published, but not free, although there is a > wealth of available information if you want to learn about it. > > Cheers > > PeteS > > >>it takes a few seconds to find those documents by googling for them, if you >>are too lazy for that there is no one who can help you. >> >>Antti >>PS I admire 'creative lazyness' but not people who are just lazy. > >Article: 93159
avishay wrote: > This wasn't my meaning. In the main SOPC builder screen, a clock is > assigned to each component, and the frequency of each clock is entered > at a separate table. I need access to this information. A quick look in <C:\altera\kits\nios2_51\bin\gtf> shows a file called MODULE_FREQ.gtf which apparently 'returns the frequency of the indicated PTF module'. My guess is you need to somehow call this in a customised build script, and quite possibly generate a VHDL source file from this information?!? Regards, MarkArticle: 93160
I am wondering if it is possible to reduce switching activity in the next state logic if I use consensus theorem (term). Any thoughts group? I am interested in this discussion from an academic standpoint and not in the fact that most of the tools will optimize away the consensus term in a synchronous design. Thanks. -sanjayArticle: 93161
Guys, Interesting thread. I wonder if an attacker could hack at the ring oscillators, say using FPGA editor, so the same bitstream gets sent to the SHA-1 device every time? I guess the ROs would be easy to track down thanks to the timing tool complaining about combinational feedback. I've not looked at the XAPP, does it (can it?) have any protection against this? Cheers, Syms.Article: 93162
>Weng wrote: >I have read the paper and I think it is an excellent paper. Thank you very much, I liked that one too. Nobody has yet shown me a better way. I was stimulated to work on the median by an article of Alan Paeth's in "Graphics Gems" (the original, volume 1). He presented an algorithm that used 20 comparisons, and mentioned that the minimum bound was 19. I e-mailed him and asked if he had the 19 comparison graph, but never got a reply, had to work that one out myself. I later saw (in Knuth's "Searching and Sorting", volume 3 of "The Art of Computer Programming" (this is a must have for people serious about algorithms)) that exchange networks are typically diagrammed differently. Just now you've inspired me to look through Knuth again, and there is a formula on page 212 (formula (11)) that to implies the median of 9 can be done with only 16 comparisons. Perhaps this leads to a better solution, but I doubt it can be pipelined as nicely. >What I want to know is how many products and applications will use it >or have been using it? Median filter is found in any decent image processing library. Beats me how many others have used it. In 1996, FPGA was the only reasonable implementation; now with 3+GHz processors common, it can be done without FPGA, but still cheaper in FPGA I think (hmmm, I don't have a feel for a DSP performance on this). If you want a book describes median applications, try any introductory image processing textbook. On my shelf I have Pratt "Digital Image Processing", and Gonzales/Wintz "Digital Image Processing". Regards, John (a median kind of guy)Article: 93163
>sanjay wrote: >I am wondering if it is possible to reduce switching activity in the >next state logic if I use consensus theorem (term). I don't know what you mean by "consensus term", could you elaborate? If you are talking about overlapping logic terms, these don't make much difference for LUT logic, which is guaranteed glitchless for single input transitions. JohnArticle: 93164
jaxato@gmail.com wrote: > We have a very good and expensive design that we want to give freely, > as an NGC file, with our generic FPGA products. How can we make the > design work only on our board. > > Our current technology is S3 and the user needs to be able to compile > their project with our NGC file, but on OUR fpga product. > > I thought of keeping a key in an external serial memory, but this is > futile if the netlist cost $100K. > > Again, the points are: > > Very expensive and useful NGC file > Want to avoid reverse engineer and copy to other FPGA stations > What should the best solution be. > > Well if we had some die ID, we could hardwired it to the netlist, so > that it checks that everytime it runs. > > Any suggestion from you ppl? Actel are probably your best choice, in present technology. They are doing something similar for their ARM7 marketing efforts. FPGA vendors COULD add a Factory-Unique Serial number, but don't currently bother. (Surprising given the customer bases ) Intel does this, but that's for revenue protection.... :) Have you looked at the Rolling code security systems for CAR Alarms ? That's designed to avoid simple record-playback hacking, and 'protects' something worth a few 10K from theft. If you have your own boards, you could add a small uC, that decrypts the bitstream - improves security of shipping, and if you use BGA packages, physical probe of the loading stream can be hiked to require package removal. That same small uC could have a mapped virtual memory, where some areas acted as RAM, some as ROM, and some as Rolling-Code echo - and only you know which does what, and the rules used. If the repeat cycles are long enough, it makes hacking by sniffing impractical. The attack method then is probably to try and hack the uC.. And you only really have to elevate it above the cost of bribing one of your employees :) -jgArticle: 93165
hiii i need immeadite help... i have to deliver a presentation. suppose i have to verify a D flip flop, what are the verification stages, how will i proceed with it. what are the steps to begin till end. its important so can any one out here just brief it out to me. thanks a million. byeArticle: 93166
"Gabor" <gabor@alacron.com> wrote in message news:1134566369.414038.120080@g49g2000cwa.googlegroups.com... > > Frank wrote: > > Just got the old PC from the storage of the lab which has ISE 4.2 installed. > > I only need the PC to program Virtex 6000 and xc18v04, do I need to upgrade > > to ISE 6 or above? > > > > Thank you. > > These devices are supported in Foundation 4.1i which I believe was > released > at the same time as ISE 4.2, so I would assume you can use it. If > you're > not using any legacy features (support for older devices or Aldec-based > schematics) though I would recommend updating. > Thank you Gabor.Article: 93167
hey mate that was just i heard from some one about the protocol while on the group that i posted it ! I have already googled it--it's pretty basic for anyone to google the general stuff,but if some one asks u over the group then obviously it has to be some thing special which every one doesnot have acess to ! thanks anyways for ur efforts abhishekArticle: 93168
"ABS" <abhishekbedi@gmail.com> schrieb im Newsbeitrag news:1134635322.265145.307520@z14g2000cwz.googlegroups.com... > hey mate > that was just i heard from some one about the protocol while on the > group that i posted it ! > I have already googled it--it's pretty basic for anyone to google the > general stuff,but if some one asks u over the group then obviously it > has to be some thing special which every one doesnot have acess to ! > thanks anyways for ur efforts > abhishek > you asked in very unclear manner... so my non so friendly reply was based on that, there are lots of documents about JTAG standards but the original standard docucs are on 'paid only' bases unfortunatly. you did not ask for special just thing, just 'any docuements...' the 1149.1 is no problems to handle without having the access to the original specification docu, the 1532 is a bit harder just reading the 1532 BSDL files helps a bit but having the 1532 real documentation would be better of course AnttiArticle: 93169
> Maybe I'm missing something here, but with a 1 wire device providing >the key that lets the FPGA function, all you need to do is monitor the >bits that are read out of the device, and then duplicate that bit >pattern to enable the FPGA. Unless the query is different every time >the FPGA starts up (which would either require different bitstreams or >different external stimulus to the FPGA), you just play back the >bitstream you recorded off a known good product. The FPGA itself is >deterministic, and other than the battery backed encryption in V2, there >is no key kept in the FPGA that isn't part of the device configuration. I could be all wet, but I think we are talking about two types of one-wire chips. The old ones are just serial numbers. No good for crypto. The new ones have a write only secret and an SHA1 engine so they can hash whatever you feed them using that secret. DS2432: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2914 You do have to put a random number generator into the FPGA. My guess is that a pair of ring oscillators would be good enough for this application. It would be cheaper to patch the bit stream via something like FPGA Editor than to break the crypto with some modest amount of entropy feeding it. There may be simpler ways to get entropy - depends upon your application. -- 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: 93170
hey.. this is a presentation that has to be delivered to my team,to teh members of my team itself. what if in case they ask, explain with an example, say u givn a D Flip Flop to verify, how will u proceed. what do u plan n how u cary on with the verification. What m i suppose to say. how will i proceed. can u plzzzzz tell me in brief..!! thanksArticle: 93171
As the appnote says: It is vulnerable to bitstream attack. The method uses a Picoblaze to do the final go/nogo check (amongst others). Just modify the bitstream with an other blockram contents (DATA2MEM), even by trial and error, and you can overrule the whole mechanism. By replacing the BlockRAM with distributed ROM could help here. Regards, Henk van Kampen Mediatronix.com Austin Lesea wrote: > http://www.xilinx.com/bvdocs/appnotes/xapp780.pdf > > Austin > > Thomas Stanka wrote: > > > Why Ngc? > > And is it necessary to stay on S3? Maybe you should think about Flash > > based Fpgas (Actel, Lattice,..). > > > > bye Thomas > >Article: 93172
Daveb wrote: > Thanks Peter. I wonder what devices the Mars Beagle2 Lander used :) > makes no difference if the landing airbag has mechanicaly fail and beagle2 is 6 foot under, embedded into Mars landscape. AurashArticle: 93173
IMHO, if those Ring Oscillators can generate a 'random' number then this method is hard to hack using the yo-yo guy with the scope and an external uC ;o). As JustJohn mentioned it has taking 10 years to crack SHA1... What about the Foe mechanism, isn't that easy to hack unless you put some thought on it? I haven't used JBits but I've read that you can actually modify the BIT file, do partial changes... (it must be paradise for hackers) I am not sure if you get some kind of 'FPGA Editor' but if you do even the guy with the yo-yo can spot a signal coming from the Foe logic with big fan-out and is not a clock and can invert it... Every design is different but you could inject errors when Foe is not asserted instead of enabling/disabling things, or mask some bits in some key counters... -- Ignacio Ulises Hernandez " I'm not normally a praying man, but if you're up there, please save me, Superman!" - Homer Simpson ;O) "Hal Murray" <hmurray@suespammers.org> wrote in message news:1tOdnQTBKuxEsDzenZ2dnUVZ_vudnZ2d@megapath.net... >> Maybe I'm missing something here, but with a 1 wire device providing >>the key that lets the FPGA function, all you need to do is monitor the >>bits that are read out of the device, and then duplicate that bit >>pattern to enable the FPGA. Unless the query is different every time >>the FPGA starts up (which would either require different bitstreams or >>different external stimulus to the FPGA), you just play back the >>bitstream you recorded off a known good product. The FPGA itself is >>deterministic, and other than the battery backed encryption in V2, there >>is no key kept in the FPGA that isn't part of the device configuration. > > I could be all wet, but I think we are talking about two types of > one-wire chips. The old ones are just serial numbers. No good > for crypto. The new ones have a write only secret and an SHA1 > engine so they can hash whatever you feed them using that secret. > > DS2432: > http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2914 > > You do have to put a random number generator into the FPGA. > > My guess is that a pair of ring oscillators would be good enough > for this application. It would be cheaper to patch the bit > stream via something like FPGA Editor than to break the crypto > with some modest amount of entropy feeding it. There may > be simpler ways to get entropy - depends upon your application. > > -- > 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: 93174
Peter Alfke wrote: > Daveb, your question indicates your suspicion that modern ICs ( like > FPGAs) offer less reliable system solutions than the older technology. > That suspicion is not shared by the (admittedly biased) IC industry, > nor by the user community which accepts the newer technologies and > higher capabilities gladly (even while they complain about the usual > teething problems). Well, I think it depends. We are doing electronics for radiation areas I from my experience I can say that old-good devices are doing much bette job than new ones. Specially if we for example take ICs in DIL compare to their counterparts in SOIC package. I don't know what is the internal structure difference, but these DILs can widthstand more of radiation. For FPGAs it's the same thing. Higher integration = more transistors in sq. mm -> less tolerant to single event radiation effects. (of course you have radiation tolerant fpga, but if you compare a cost, you find out that it's better to do that with standard fpgas and change pcb every year :) d.
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