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
Heavy Sigh! This subject comes up about once every 6-9 months. SRAM FPGAs use cutting edge process (and in fact are ahead of what many of the asic foundries are using). THis is possible because the SRAM FPGAs are fabricated using the same process as memory. No extra steps for flash etc. Putting flash on the chip adds process steps and prevents the use of the latest process. You take a subtantial hit in speed, as well as a yield hit. The majority of FPGA users are not willing to take hits in these departments for bitstream security. Besides which, it is often possible with little in the way of special tooling to subvert the security bits to recover the data anyway. One technique which is very secure that is mentioned here is the battery retained power. While that is really secure, I wouldn't use it in a commercial product because of the possibility of losing the configuration. Instead, if you are that concerned about security, put an OTP device in the design as sort of a hardware dongle, and link its design tightly to the FPGA so that the FPGA design will not operate without the OTP device. The FPGA bitstream by itself is no good if you need something else without a visible bitstream to make it work. That said, My personal feeling is the FPGA bitstream is more secure than your typical microprocessor, other than those with internal flash (even those can sometimes be sucessfully attacked by manipulating the program voltages carefully or by forcing codes onto the external bus to snoop the internals). At least in the case of an FPGA, the FPGA won't work with a partial bitstream, so it is quite a bit harder to reverse engineer from the machine code. In any event, I'll take the power, speed density and cost over a small improvement in bitstream security any day. In the cases where I need more security and the customer is willing to pony up for it, an OTP part tightly coupled to the FPGA is probably a workable solution, or in those rare cases where it makes sense (military combat hardware loaded with mission parameters, for example) the battery backup. Also, for volume customers, you can get the chips marked with a custom logo or totally unmarked so it is not immediately obvious that there is "xilinx inside". In that case, do the programming from a microprocessor, if possible using a parallel interface (select map for virtex or one of the parallel modes for 4K, spartan you're stuck with serial) so you don't have the tell-tale serial ROM telling the whole world that the unmarked part is an FPGA. Bottom line, is if they want your IP bad enough they can get it. Of course it might cost less to walk into the company and just hijack the design. csjacobs@my-deja.com wrote: > Why couldn't the FPGA companies put some flash rom internal to the fpga > that can be written but never read...then just burn it once at the > factory and you are done...and since it's flash, you still have the > reprogramability option. > > Craig Jacobs > > In article <8eno4j$88j$1@nnrp1.deja.com>, > Greg Neff <gregneff@my-deja.com> wrote: > > In article <390F5925.CC48CA69@raytheon.com>, > > Robert Posey <muddy@raytheon.com> wrote: > > > > > > You also had better be really, really sure that external power > > transients can't > > > cause the FPGA to dump its memory, or trigger its reset circuit. I > > wouldn't > > > feel very good about using external power at all, but you will still > > face > > > ground spike problems. > > > > Correct. With our microprocessor circuit, the code SRAM was write > > protected unless it was connected to the production test fixture. > > Also, there is no reset and/or reconfiguration circuit to worry about > > in an SRAM. > > > > > In addition, you face potential problems with having > > > the FPGA outputs being powered, while the rest of the circuit is not > > powered. > > > This could damage the other circuits. > > > > Again correct. You could use a "power no good" signal to tri-state > all > > the FPGA outputs. > > > > I can see applications where this technique would be useful, outside > of > > mainstream production. For example, if a small company is > > demonstrating new technology to a potential licensee (or anyone else > > for that matter), then proof-of-concept hardware could be built like > > this, to prevent IP rip-off. > > > > -- > > Greg Neff > > VP Engineering > > *Microsym* Computers Inc. > > greg@guesswhichwordgoeshere.com > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- P.S. Please note the new email address and website url -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 or http://www.fpga-guru.comArticle: 22276
Hi I'm working on Xilinx Virtex XCV1000-6 BG560. any solution or check point about the error message below ? Error: Buffer allocation detected possible drivers on the same net as clock input '/ver7-optimized/clk'. (FPGA-buffermap-25) this error reported at compile-optimization step. 'clk' is the main clock of my design. 'ver7' : i tried 7 times to solve this error T.T any comment would guide me. please help gula@hitel.netArticle: 22277
This has some potential. The random number could be generated by running a counter (or a LFSR) for a period of time controlled by the internal configuration clock oscillator. This oscillator is relatively free running and has a period that varies within a known range. There may be some linking to the other clock in the circuit, but it should not dominate the oscillator enough to fix the frequency between units. Then the rest of it becomes a matter of using the CPLD as a "dongle" to protect the FPGA from being run without the "dongle". Or a uComp can be used rather than a CPLD. It may take a little more work to program it, but they can come in very small 8 pin packages. I am still looking for a two pin package that works like the Dallas One-wire parts, but even Dallas does not use anything smaller than 6 pins except for a two pin chip scale package which is likely very hard to use. I don't know of any logic devices that are as small (or as cheap?) as the smallest uComps. This would be pretty secure as a way to protect the FPGA load. Anyone care to try it? To test this you would only need to program up the two counters and see if they really generate random numbers. I expect to be working on the FPGAs for my board later this week. If I don't hear from anyone else, I will see if I have time to give it a try. Rick Filipkiewicz wrote: > > How about this as a mechanism: > > o The FPGA is paired up with a small Flash CPLD. > > o Both the FPGA & the CPLD implement the same algorithm that performs some > mangling/encryption on a shortish bits stream 50-100 bits. > > o The algorithm is configurable so that it is unique for each FPGA/CPLD pair. > > o Once the FPGA has loaded up it generates a random number which it both sends > to the CPLD & encrypts itself. > > o The CPLD encrypts the same random number and sends the result back to the > FPGA. > > o Unless the internal & external encrypted values are the same the FPGA > remains in reset. > > This then reduces the problem to 3 things: > > (1) Generating a random number in a way that is completely unrelated to the > FPGA configuration. > > (2) Finding an algorithm that can be configured for the FPGA by changing the > definitions of some ROMs so that different bit streams can be generated by > changing some ``init'' statements & not by rebuilding the whole device. > > Of course the positions of these bits could be detected by comparing a few bit > streams so some configuration ``noise'' would have to be introduced. > > (3) Protecting the CPLD from attack. > > I think that (1) is the most difficult. Maybe this is the thing that the FPGA > vendors could add to their parts. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22278
The problem is creating a random number in an FPGA. A potentially better solution is as follows: The FPGA sends number N to CPLD CPLD responds with E(N,K). FPGA also computes E(N,K) internally (the key is secret, contained in the FPGA bitfile). Then the FPGA increments N, and repeats the procedure indefinatly. To break it, one could do one of the following: Attack E to find K, reimplement CPLD. Extract K from the CPLD. Clone CPLD. Disassemble/reserse engineer the FPGA design enough to determine the key. Disassemble/reverse engineer the FPGA design enough to remove the encryption procedure. Record a sequence of challange/responses and just replay that, which only works if the device is run for a limited period of time. All these attacks work (except for the replay attack) for the other protocol (generate random N). It does not seem to raise the bar all that much over simple copying. I think, unless there is a built in mechanism for encrypted bitfiles (see my posts on how it would work and what added silicon would be required), the effective solutions are legal, not technical. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22279
You'll want to vigorously protect your random number generator algorithm. Once the algorithm is discovered it is a fairly simple matter to predict the stream and duplicate the circuit. Rickman wrote: > This has some potential. The random number could be generated by running > a counter (or a LFSR) for a period of time controlled by the internal > configuration clock oscillator. This oscillator is relatively free > running and has a period that varies within a known range. There may be > some linking to the other clock in the circuit, but it should not > dominate the oscillator enough to fix the frequency between units. > > Then the rest of it becomes a matter of using the CPLD as a "dongle" to > protect the FPGA from being run without the "dongle". Or a uComp can be > used rather than a CPLD. It may take a little more work to program it, > but they can come in very small 8 pin packages. I am still looking for a > two pin package that works like the Dallas One-wire parts, but even > Dallas does not use anything smaller than 6 pins except for a two pin > chip scale package which is likely very hard to use. I don't know of any > logic devices that are as small (or as cheap?) as the smallest uComps. > > This would be pretty secure as a way to protect the FPGA load. Anyone > care to try it? To test this you would only need to program up the two > counters and see if they really generate random numbers. > > I expect to be working on the FPGAs for my board later this week. If I > don't hear from anyone else, I will see if I have time to give it a try. > > Rick Filipkiewicz wrote: > > > > How about this as a mechanism: > > > > o The FPGA is paired up with a small Flash CPLD. > > > > o Both the FPGA & the CPLD implement the same algorithm that performs some > > mangling/encryption on a shortish bits stream 50-100 bits. > > > > o The algorithm is configurable so that it is unique for each FPGA/CPLD pair. > > > > o Once the FPGA has loaded up it generates a random number which it both sends > > to the CPLD & encrypts itself. > > > > o The CPLD encrypts the same random number and sends the result back to the > > FPGA. > > > > o Unless the internal & external encrypted values are the same the FPGA > > remains in reset. > > > > This then reduces the problem to 3 things: > > > > (1) Generating a random number in a way that is completely unrelated to the > > FPGA configuration. > > > > (2) Finding an algorithm that can be configured for the FPGA by changing the > > definitions of some ROMs so that different bit streams can be generated by > > changing some ``init'' statements & not by rebuilding the whole device. > > > > Of course the positions of these bits could be detected by comparing a few bit > > streams so some configuration ``noise'' would have to be introduced. > > > > (3) Protecting the CPLD from attack. > > > > I think that (1) is the most difficult. Maybe this is the thing that the FPGA > > vendors could add to their parts. > > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- P.S. Please note the new email address and website url -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 or http://www.fpga-guru.comArticle: 22280
Nicholas C. Weaver wrote: > > The problem is creating a random number in an FPGA. A > potentially better solution is as follows: > > The FPGA sends number N to CPLD > > CPLD responds with E(N,K). FPGA also computes E(N,K) > internally (the key is secret, contained in the FPGA bitfile). > > Then the FPGA increments N, and repeats the procedure > indefinatly. This is the scheme I called 'rolling code', where the stimulus changes. The NEXT N does not have to be N+1, and might be better chosen from a ROM table. The key is that the function E() is as complex as practical, and dummy signal pins could confuse this. Another level would be to ALSO bury a response in the CPLD, that is never called, so is non traceable, via FPGA. ( or via FPGA sources, extracted by $$$$ :-) Presented in court, genuine devices would report 'Yes Genuine' tag, whilst the cloned one would be very silent... A device like the SOL24 ATF750, where ANY FF can be clocked from ANY other, with choice of Rise.Fall edges, and that has Async RST, Sync Preset has to be just about impossible to 'solve'. > > To break it, one could do one of the following: > > Attack E to find K, reimplement CPLD. > > Extract K from the CPLD. > > Clone CPLD. > > Disassemble/reserse engineer the FPGA design enough to > determine the key. > > Disassemble/reverse engineer the FPGA design enough to remove > the encryption procedure. This is why the CPLD should also pass/scramble the bitstream - just makes this path harder, by making getting a known clean bitstream much more than turning on a programmer. - jgArticle: 22281
Peter Alfke wrote: > > Well, this newsgroup is supposed to be technical, not commercial. > But (the other) Peter asked the question, and here is the answer: > > As of May 2000 you can buy an XC2S15 in quantity 1 through 24 for $ 7.10 > : > > You get 96 CLBs, i.e 384 LUT / flip-flop combinations ( Logic Cells ) > plus four dual-ported BlockRAMs, each 4096 bits > plus four DLLs > plus 60 I/Os with lots of options. What package ? -jgArticle: 22282
How much would people be willing to pay for a secure way to load an FPGA? What sort of volumes are interesting in this market area? I'd guess it can't be too big or the infringing products would be easy to find on the open market where legal action would work yet still big enough to be worth the effort to steal the design. One approach is to make an ASIC. That has the obvious hard to reprogram problems. Does Xilinx offer the hardwire mode for the modern chips? How many vendors make ASICs from a Xilinx bit stream or perhaps the unrouted design. Tayloring the front end of an ASIC process to this type of input seems like a good business opportunity if the risk of theft is important. How complicated or rather expensive is laser programming or fusable links? Is reading them off a packaged chip expensive enough to prevent reverse-engineering in this market area? I'm thinking of some extra logic in the corner where a per-vendor crypto key could be blasted in. This assumes that the FTGA vendor would only sell more of the chip woth that key to the legitimate owner. -- These are my opinions, not necessarily my employers.Article: 22283
Hello, I have do a small design with a Xilinx FPGA (XC5200 but it's normaly the same thing on Spartan and 4000) on Slave Serial mode. When I program it, after N bits sended, it pull down the init/ line. I don't understand why I have a CRC error because each bit sended (on the pin DIN) is at each time compared with the DOUT pin after. All bits are correctly sended and the most strange thing is that the CRC error occurs after N bits, with N no constant ! (for example 90, 427, 123, 1515...) Have you already find the same problem ? I think perhaps it's due at a power problem, because the ouputs pin HDC and LDC/ are at 5V and 1.1 V (and no near 0V) respectivly. But if the FPGA is not correctly powered, why it accepts bit during configuration process and put DOUT correctly ?? %-( Stange case.... if anyone has an idea ? Thanks, Sebastien,Article: 22284
> Stange case.... if anyone has an idea ?
Mhm, an idea:
check if you are sending the bits in the right sequence
with respect to the bytes they are from.
Generate an raw bits file (bitgen option -b) and
check.
Just an idea - as you were asking.
Andreas
-----------------------------------------------------------------
Andreas C. Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Email: doering@iti.mu-luebeck.de
Home: http://www.iti.mu-luebeck.de/~doering
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 22285"Sebastien Favard (Gordh)" a écrit : > Have you already find the same problem ? I think perhaps it's due at a > power problem, because the ouputs pin HDC and LDC/ are at 5V and 1.1 > V (and no near 0V) respectivly. > > But if the FPGA is not correctly powered, why it accepts bit during > configuration process and put DOUT correctly ?? %-( > > Stange case.... if anyone has an idea ? Hi You could encounter some clock problems. I had something rather similar when trying to program a Virtex through the JTAG interface. When implementing the design in Foundation, you must say that the start-up clock is "User Clock", not "CCLK" (in the "Synthesis/Implementation settings" box, click on the "Options" button. In the box that appears, click on the Configuration "Edit Options..." button. Choose the "Startup" window and select the startup clock) Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel 00 33 1 46 67 51 11 92400 COURBEVOIE Fax 00 33 1 46 67 51 01 FRANCEArticle: 22286
> > You could encounter some clock problems. I had something rather similar > when trying to program a Virtex through the JTAG interface. > When implementing the design in Foundation, you must say that the > start-up clock is "User Clock", not "CCLK" (in the > "Synthesis/Implementation settings" box, click on the "Options" button. > In the box that appears, click on the Configuration "Edit Options..." > button. Choose the "Startup" window and select the startup clock) > I'll try this solution. But I think that's really suspicious because the mode by hardware default is the slave serial mode and the default constraint in the bitstream generator is the master: CCLK and not UserCCLK ! Very strange but I could try your idea, it's a very good idea :) Thanks,Article: 22287
> Mhm, an idea: > check if you are sending the bits in the right sequence > with respect to the bytes they are from. > Generate an raw bits file (bitgen option -b) and > check. > Just an idea - as you were asking. > Andreas I have already check all the bitstream file with a home program. I check the header, all start bytes, preambule code, fill bits and so one... In fact all but not the CRC bits ! So I think really that my bitstream is correctly. Thanks for your attention,Article: 22288
Hello, I'm JW, Kim , Xilinx Disti FAE Please, give me a mail for this message. Thanks, JW jwkim@seodu.co.kr º¸¶ó³Ý <leehg@hmec.co.kr>ÀÌ(°¡) ¾Æ·¡ ¸Þ½ÃÁö¸¦ news:am4Q4.561$Qf.10918@news2.bora.net¿¡ °Ô½ÃÇÏ¿´½À´Ï´Ù. > Hi > I'm working on Xilinx Virtex XCV1000-6 BG560. > any solution or check point about the error message below ? > > Error: Buffer allocation detected possible drivers on the same net as clock > input '/ver7-optimized/clk'. (FPGA-buffermap-25) > > this error reported at compile-optimization step. > > 'clk' is the main clock of my design. > > 'ver7' : i tried 7 times to solve this error T.T > > any comment would guide me. > please help > > gula@hitel.net > > >Article: 22289
> You could encounter some clock problems. I had something rather similar > when trying to program a Virtex through the JTAG interface. > When implementing the design in Foundation, you must say that the > start-up clock is "User Clock", not "CCLK" (in the > "Synthesis/Implementation settings" box, click on the "Options" button. > In the box that appears, click on the Configuration "Edit Options..." > button. Choose the "Startup" window and select the startup clock) > Yes I have try this but the synthesis tools don't want generate the bitstream file because my design don't support a external Oscilator wire at the FPGA pin... :( I have certainly not understand the difference between UserClk and Clk. If I use a slave serial mode, I drive the CCLK pin by a controler logic for example. So, the start-up clock is my external clock, no ? If I must use a "User Clock", how must I modify my design to support it and enable synthesis tool bitstream generation ? My bitgen help is : "OscClk: Determines whether in XC5200 oscillator is driven by the internal 16MHz clock (CCLK) or by a user clock (User Clk). If you specify UserClk, the clock must be connected to the OSC.CK pin of the device's OSC component." If I use bitgen : >> bitgen -w -g OscCLK:UserCLK -a fpga.ncd >> >>ERROR:x52bs:26 - There must be a OSC component with a signal on the C pin when >> OscClk is UserClk. ??? I don't undertand this message because I DRIVE the CCLK pin of FPGA, so how it ca say that ? Thanksssssssssssssss Sebastien,Article: 22290
"Sebastien Favard (Gordh)" a écrit : > "OscClk: Determines whether in XC5200 oscillator is driven by the > internal 16MHz clock (CCLK) or by a user clock (User Clk). If you > specify UserClk, the clock must be connected to the OSC.CK pin of the > device's OSC component." > > If I use bitgen : > > >> bitgen -w -g OscCLK:UserCLK -a fpga.ncd > >> > >>ERROR:x52bs:26 - There must be a OSC component with a signal on the > >>C pin when OscClk is UserClk. > > ??? I don't undertand this message because I DRIVE the CCLK pin of > FPGA, so how it ca say that ? I've never used an XC5200 part (the parts files are not installed on my computer) so I can't say much about that. For XC4000 or Spartan, what I said seems consistent. Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel 00 33 1 46 67 51 11 92400 COURBEVOIE Fax 00 33 1 46 67 51 01 FRANCEArticle: 22291
Hal Murray wrote: > > How much would people be willing to pay for a secure way to load > an FPGA? What sort of volumes are interesting in this market area? > I'd guess it can't be too big or the infringing products would be > easy to find on the open market where legal action would work yet > still big enough to be worth the effort to steal the design. > > One approach is to make an ASIC. That has the obvious hard > to reprogram problems. > > Does Xilinx offer the hardwire mode for the modern chips? > > How many vendors make ASICs from a Xilinx bit stream or perhaps > the unrouted design. Tayloring the front end of an ASIC process > to this type of input seems like a good business opportunity if > the risk of theft is important. > > How complicated or rather expensive is laser programming or > fusable links? Is reading them off a packaged chip expensive > enough to prevent reverse-engineering in this market area? > > I'm thinking of some extra logic in the corner where a per-vendor > crypto key could be blasted in. This assumes that the FTGA vendor > would only sell more of the chip woth that key to the legitimate owner. > > -- > These are my opinions, not necessarily my employers. I looked into the Xilinx Hardwire devices once. I believe I asked about several different sizes of smaller 4000 series parts. The prices and minimum quantities varied, but the one constant was a minimum order (for the first year) of $100K. So if you have a volume that is not going to be overly small a Hardwire approach would be viable. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22292
Jim Granville wrote: > > Nicholas C. Weaver wrote: > > > > The problem is creating a random number in an FPGA. A > > potentially better solution is as follows: > > > > The FPGA sends number N to CPLD > > > > CPLD responds with E(N,K). FPGA also computes E(N,K) > > internally (the key is secret, contained in the FPGA bitfile). > > > > Then the FPGA increments N, and repeats the procedure > > indefinatly. > > This is the scheme I called 'rolling code', where the > stimulus changes. > The NEXT N does not have to be N+1, and might be better chosen from > a ROM table. > The key is that the function E() is as complex as practical, and > dummy signal pins could confuse this. > > Another level would be to ALSO bury a response in the CPLD, that > is never called, so is non traceable, via FPGA. > ( or via FPGA sources, extracted by $$$$ :-) > > Presented in court, genuine devices would report 'Yes Genuine' > tag, whilst the cloned one would be very silent... > > A device like the SOL24 ATF750, where ANY FF can be clocked from > ANY other, with choice of Rise.Fall edges, and that has Async RST, > Sync Preset has to be just about impossible to 'solve'. > > > > > To break it, one could do one of the following: > > > > Attack E to find K, reimplement CPLD. > > > > Extract K from the CPLD. > > > > Clone CPLD. > > > > Disassemble/reserse engineer the FPGA design enough to > > determine the key. > > > > Disassemble/reverse engineer the FPGA design enough to remove > > the encryption procedure. > > This is why the CPLD should also pass/scramble the bitstream > - just makes this path harder, by making getting a > known clean bitstream much more than turning on a programmer. > > - jg First I don't see any advantage to encrypting the bitstream unless you use a random key which has to be burned into the FPGA. We have already explained why the FPGA vendors don't want to/won't build this into the chips. The cost is high in several ways. You guys are thinking way too hard about the encryption. If you use a 48 bit key "K", a 48 bit number "N" and a 48 bit response "E" and use an 8 bit microP (smaller than a CPLD) to implement the algorithm (keeping in mind that you have to duplicate it in the FPGA) you should be able to make this hard enough to break that your design is protected from most anyone other than NSA. We are not trying to protect state secrets. We are just trying to fool a PC board house that wants to clone our design. Not many outfits would have the expertise to break an encryption related design. And remember, it is not at all trivial to disassemble the bitstream of an FPGA. Another FPGA vendor may have done this, but not many board houses would have the technology. This is exactly like the technology they use in the more recent dongles for software protection. How many of those have been cracked other than attacking the software in the PC (FPGA design in this case which is harder). The more I think about this, the more I like it. If it weren't for the logistical problems of maintaining a list of unique serial numbers for production, I would think very hard about implementing this. So my next DSP boards may have this feature built in. But this will be for my customer's use only. I give away my source code and FPGA designs so that anyone can do anything with them while using my boards. They are only protected by the honesty of my customers. :-) -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22293
Hi, I got a warining during simultion about vital glitch on an internal signal of the low level structure. but I do not get any glitch on my output signals, Is it an important warining that I should take care of, or is it going to vanish on the real hardware (CPLD) Anyhow what is the meaning if the vital glitch? Thanks Jamil KhatibArticle: 22294
In article <3911102B.47E7C045@utc.fr>, Sebastien Favard (Gordh) <Sebastien.Favard@utc.fr> wrote: >Hello, > >I have do a small design with a Xilinx FPGA (XC5200 but it's normaly the >same thing on Spartan and 4000) on Slave Serial mode. When I program it, >after N bits sended, it pull down the init/ line. I don't understand why >I have a CRC error because each bit sended (on the pin DIN) is at each >time compared with the DOUT pin after. If you really have ALL the input bits appearing onthe DOUT, this is definitely not good. The data on the DOUT pin will be a delayed by 1 cycle version of the data on the DIN pin, but ONLY for the duration of the header (40 bits). After the header, the DOUT pin should be high for the duration of the bitstream, and then reverts to echoing the DIN data to load down stream parts. In a single chip situation, there is no downstream devices, so the device will complete and then go DONE. Here are my guesses: Is the config clock running before the configuration starts, and loads junk before the header? Is the config clock clean, both rising and falling edges, check with at least a 300MHz scope. Are you changing DIN data when the CCLK clock edge rises, You shouldn't Good luck, Philip Freidin > All bits are correctly sended and >the most strange thing is that the CRC error occurs after N bits, with >N no constant ! (for example 90, 427, 123, 1515...) > >Have you already find the same problem ? I think perhaps it's due at a >power problem, because the ouputs pin HDC and LDC/ are at 5V and 1.1 >V (and no near 0V) respectivly. > An unloaded HDC could be at 5V, but LDC should be near ground. What do you have connected to it? >But if the FPGA is not correctly powered, why it accepts bit during >configuration process and put DOUT correctly ?? %-( As I said above, this is not correct. DOUT only follows DIN during the header, and after the device is configured, not while configuring. Are the two pins shorted? > >Stange case.... if anyone has an idea ? > > >Thanks, > >Sebastien, >Article: 22295
Hi, When I use the BitGen program with argument StartupClk (on XC4000/Spartan) or the similar OscClk (on XC5200) an error appeared: "ERROR:x4kbs:35 - There must be a STARTUP component with a signal on the CLK pin when StartupClk is UserClk." Why I have this error when I must create a bitstream for a slave serial mode ? Sebastien,Article: 22296
Announcing new, lowest cost, no fuss FPGA prototyping kits for FPGA designers, students and enthusiasts. These are the lowest cost, easiest to use FPGA prototyping kits on the market! Your favourite FPGA vendor is supported - Xilinx, Altera, Atmel, Lucent and Actel. Strength in simplicity: - FPGA (5K to 10K gates) on a board - Easy connection - FPGA pin numbers labelled on both sides of the board - Prototyping area - add what you want - Canned crystal oscillator module plus other components included - Configuration download pod board included - PC parallel port interface capability - Low cost - Easy! ######################################## OPENING SALE - 20% off the normal price! ######################################## ...An excellent time to grab a bunch of these for your lab, or maybe one for your student project. Sale on for only a short time. Pictures, specs, resources and online shop at Burch Electronic Designs: www.BurchED.com.au P.S. Lots and lots of uses. Here's some: - Prototype a module of your design for demonstration purposes, or to increase confidence in the module for a final target design. - Build them into one-off systems or special purpose test equipment. - Have a couple on hand for when you need to try out that circuit quickly (generally happens at midnight :) ). - Student projects (digital logic design, computer architecture, DSP, telecomms etc. etc.).Article: 22297
Hi.
I have a problem with my FPGA device (Spartan XCS10 PC84)
When I download my program to the device via JTAG (Parallel cable III),
The programming tool write "programming successfully".
But when I connect my oscilloscop to the pins of the device, all pins
except ground are high ( '1' ).
I dont know what to do.
ALL Vcc are connected to ground via 0.1 uF capacitor.
INIT is connected to Vcc via 4700 ohm resistor.
Mode is unconnected. (because we use an external oscillator)
TCK,TDI,TMS,TDO,Vcc,GND, and the external clock are connected from the
JTAG according to the following:
TCK to pin 16
TDI to pin 15
TMS to pin 17
TDO to pin 75
Vcc to pin 2, 11, 22, 33, 42, 54, 63, 74
GND to pin 1, 12, 21, 31, 43, 52, 64, 76
external clock to pin 35.
My code at the bottum of the mail:
Thankful for help
Björn Lindegren
library IEEE;
use IEEE.std_logic_1164.all;
entity sampel is
port (
clk,reset: in STD_LOGIC;
input: in STD_LOGIC_VECTOR (7 downto 0);
output: out STD_LOGIC_VECTOR (7 downto 0);
Q2 : out STD_ULOGIC;
Q3 : out STD_ULOGIC;
Q1Q4 : out STD_ULOGIC;
DONEIN : out STD_ULOGIC;
--GSR : in STD_ULOGIC;
GTS_IN : in STD_ULOGIC;
cs: out STD_LOGIC
--int: inout STD_LOGIC
);
end sampel;
architecture sampel_arch of sampel is
signal sampelcounter: integer range 0 to 15;
component STARTUP
port(
Q2 : out STD_ULOGIC := 'H';
Q3 : out STD_ULOGIC := 'H';
Q1Q4 : out STD_ULOGIC := 'H';
DONEIN : out STD_ULOGIC := 'H';
GSR : in STD_ULOGIC;
GTS : in STD_ULOGIC;
CLK : in STD_ULOGIC);
end component;
begin
U1: STARTUP PORT MAP( GSR=>reset,clk=>CLK,Q2=>Q2, Q3=>Q3, Q1Q4=>Q1Q4,
DONEIN=>DONEIN,GTS=>GTS_IN);
sampelprocess: process(reset,clk)
begin
if reset ='1' then
output<=(others=>'0');
cs<='1';
elsif clk='1' and clk'event then
if sampelcounter=0 or sampelcounter=5 then
cs<='0';
elsif sampelcounter=10 then
cs<='1';
output<=input;
end if;
end if;
end process sampelprocess;
sampelcount: process(reset,clk)
begin
if reset ='1' then
sampelcounter<=0;
elsif clk='1' and clk'event then
sampelcounter<=sampelcounter+1;
if sampelcounter=11 then
sampelcounter<=0;
end if;
end if;
end process sampelcount;
end sampel_arch;
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22298Ray Andraka wrote: > Heavy Sigh! This subject comes up about once every 6-9 months. Exactly, and so why have we not come up with a reasonable solution before? I don't know... I have written an app note on this subject, and propose a simple solution using off the shelf technology. It can be read at The Free-IP Project web site: http://www.free-ip.com I welcome any comments on it, but my news server is flaky to say the least. So please follow up via email. David Kessner davidk@free-ip.comArticle: 22299
In article <391100B9.1DF1@designtools.co.nz>, Jim Granville <jim.granville@designtools.co.nz> wrote: >Nicholas C. Weaver wrote: > This is the scheme I called 'rolling code', where the >stimulus changes. > The NEXT N does not have to be N+1, and might be better chosen from >a ROM table. > The key is that the function E() is as complex as practical, and >dummy signal pins could confuse this. I'm assuming that E() is some government strength encryption. Thus N = N + 1 is fine, no easier or harder than anything else. E can be completely unbreakable, and as I mentioned, still has this being not very effective. > Presented in court, genuine devices would report 'Yes Genuine' >tag, whilst the cloned one would be very silent... If you jsut want a record in court, use some information hiding techniques to hide a serial number deep in the configuration, using, say, Jbits. This would allow you to specify the specific device that was cloned. > This is why the CPLD should also pass/scramble the bitstream >- just makes this path harder, by making getting a >known clean bitstream much more than turning on a programmer. Not really that much harder, either. Just put a capture on the output of the configuration pin, gives you a nice clean bitstream. To my mind, the solution is as follows, either A), convince the vendors to include bitstream encryption with an on-deviced stored key/serial #. B) Always on, no bitstream source or C), don't try. Instead, just embed tracking material in the bitfiles and let your lawyer take care of it. These other techniques aren't that much harder over just copying the bitfile. They can't offer that big a hurdle, because the bitstream going into the FPGA at the FPGA's pin is, and has to be, in the clear, and there has to be a secret in the FPGA for such protocols to work. -- Nicholas C. Weaver nweaver@cs.berkeley.edu
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