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
Does anyone know where I can get a good book or article on timing diagrams? I haven't had a lot of experience when it comes to stuff like timing violations as far as I need something that will explain how to understand clock to output times, setup and hold times and their importance in simulation. Thanks Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19626
Hi all, from the XAPP132(Figure 13,15), i can't see why a SRL16 is introuced at the output of the LOCKED pin, from where it's drived, from the "ordinary" slices.... any explanation please Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19627
hi all, Many of you mention that the virtex-startup has not to be used for high frequency designs. i have created a "dummy" design (one FDC) , i want to know what is the delay of GSR. i have found that the GSR width increase by really small amount (<2ns) comparing to the reset pulse so can we conclude that if the reset pulse is too narraow, the virtex-startup can be even incorporated in high frequency design by the way for real time operating system, let's say video for example, from where the reset pulse is derived thanks in advance Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19628
hi all, Many of you mention that the virtex-startup has not to be used for high frequency designs. i have created a "dummy" design (one FDC) , i want to know what is the delay of GSR. i have found that the GSR width increase by really small amount (<2ns) comparing to the reset pulse so can we conclude that if the reset pulse is too narraow, the virtex-startup can be even incorporated in high frequency design by the way for real time operating system, let's say video for example, from where the reset pulse is derived thanks in advance Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19629
In article <3873489A.62646EDE@nospam.erols.com>, rk <stellare@nospam.erols.com> wrote: >John Cain wrote: > >> Ray, >> >> I have found that intermittant pin connections on FPGA PLCC sockets are >> usually due to scope probing during development which bends the contact >> leafs inward. This is especially severe when the SW guys are checking the >> HW. >> >> Ray Andraka wrote in message <38603C1A.8AB55592@ids.net>... >> >Rich. >> > >> >I'm surprised you've had good luck with the PLCC 84 sockets and FPGAs. >> I've had >> >some very bad experiences with those. THey seem OK the first time you put >> a chip >> >in. Remove and replace the chip once or twice and let the games begin. > >John, I agree 100%. When I first started using them it was very convenient to >slide the probe tip between the socket contact and the side of the device; it >sticks in rather nicely. It was one of those "nice thought, bad idea" sort of >things. As I said in a previous post, with the use of a good extraction tool >and some care, I haven't had any problems since then, even treating the boards >somewhat roughly. I also note that these sockets come on commercial test >equipment; HP is one vendor that uses them, and they're usually pretty careful >about reliability. I'd be interested in hearing about any problems other >people have had. > >Of course, me attempting to solder and then do a R&R on a PLCC84 which have >much lower reliability than the socket. :-) > I agree with John too. After finding it out we started using "bird's nest" adapters that would explode a PLCC socket to a 100mil pin array with another PLCC socket in the center. I have seen them for 44PLCC and 84PLCC. They are a great alternative to over-exuberant probers... Regards, -steenArticle: 19630
Ray, I have found that intermittant pin connections on FPGA PLCC sockets are usually due to scope probing during development which bends the contact leafs inward. This is especially severe when the SW guys are checking the HW. Ray Andraka wrote in message <38603C1A.8AB55592@ids.net>... >Rich. > >I'm surprised you've had good luck with the PLCC 84 sockets and FPGAs. I've had >some very bad experiences with those. THey seem OK the first time you put a chip >in. Remove and replace the chip once or twice and let the games begin. >Article: 19631
Hi, I have a query below, hope you can help: I use the std.textio and ieee.std_textio libraries for the program below: Can anyone explain why Option B don't work (by not giving the right result like for instance to read a decimal no of 20, option B gives me a value of x00??) Instead, i have to do a workaround by reading in as integer then convert to std_logic_vector to get a right answer? constant cSignalSize : integer := 5; process begin : : variable vValueField : std_logic_vector(15 downto 0) := (others => '0');; variable vTempInteger : integer; variable vInLine : line; variable vReadStatus : boolean; : : -- Option A read(vInLine, vTempInteger, vReadStatus); vValueField(cSignalSize - 1 downto 0) := conv_std_logic_vector(vTempInteger, cSignalSize); -- Option B read(vInLine, vValueField(cSignalSize - 1 downto 0), vReadStatus); end process; Thanks for your help. Wee KwongArticle: 19632
Eileen Haldeman wrote: > [...] Sure, I'm always up for an opportunity to synthesize... -- % Randy Yates % "Though you ride on the wheels of tomorrow, %% DIGITAL SOUND LABS % you still wander the fields of your %%% Digital Audio Sig. Proc. % sorrow." %%%% <yates@ieee.org> % '21st Century Man', *Time*, ELO http://www.shadow.net/~yatesArticle: 19633
That wouldn't surprise me. I'm usually called in after the customer has run into a dead end in the lab. By then, the sockets are already toast. I've also seen bad surface mount connections on those PLCC sockets that go onto a PLCC footprint. I guess they are hard to inspect or something. My other objection to sockets is that sockets pull the part farther away from decoupling and can introduce ugly reflections on pins. Not really an issue unless you are pushing the part's capability. Steen Larsen wrote: > In article <3873489A.62646EDE@nospam.erols.com>, > rk <stellare@nospam.erols.com> wrote: > >John Cain wrote: > > > >> Ray, > >> > >> I have found that intermittant pin connections on FPGA PLCC sockets are > >> usually due to scope probing during development which bends the contact > >> leafs inward. This is especially severe when the SW guys are checking the > >> HW. > >> > >> Ray Andraka wrote in message <38603C1A.8AB55592@ids.net>... > >> >Rich. > >> > > >> >I'm surprised you've had good luck with the PLCC 84 sockets and FPGAs. > >> I've had > >> >some very bad experiences with those. THey seem OK the first time you put > >> a chip > >> >in. Remove and replace the chip once or twice and let the games begin. > > > >John, I agree 100%. When I first started using them it was very convenient to > >slide the probe tip between the socket contact and the side of the device; it > >sticks in rather nicely. It was one of those "nice thought, bad idea" sort of > >things. As I said in a previous post, with the use of a good extraction tool > >and some care, I haven't had any problems since then, even treating the boards > >somewhat roughly. I also note that these sockets come on commercial test > >equipment; HP is one vendor that uses them, and they're usually pretty careful > >about reliability. I'd be interested in hearing about any problems other > >people have had. > > > >Of course, me attempting to solder and then do a R&R on a PLCC84 which have > >much lower reliability than the socket. :-) > > > > I agree with John too. After finding it out we started using "bird's nest" > adapters that would explode a PLCC socket to a 100mil pin array with another > PLCC socket in the center. I have seen them for 44PLCC and 84PLCC. They are > a great alternative to over-exuberant probers... > > Regards, > -steen -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19634
The problem is not that the pulse is too narrow to work, rather it is the fact that the pulse may not end on the same clock cycle for all flip-flops in the design because of distribution delays. In the absence of some other considerations in the design, this can lead to part of the design coming out of reset a clock cycle ahead of other parts of the design. Naturally, that can cause problems. erika_uk@my-deja.com wrote: > hi all, > > Many of you mention that the virtex-startup has not to be used for high > frequency designs. > > i have created a "dummy" design (one FDC) , i want to know what is the > delay of GSR. i have found that the GSR width increase by really small > amount (<2ns) comparing to the reset pulse > > so can we conclude that if the reset pulse is too narraow, the > virtex-startup can be even incorporated in high frequency design > > by the way for real time operating system, let's say video for example, > from where the reset pulse is derived > > thanks in advance > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19635
Christer Ericson wrote: > > On Tue, 04 Jan 2000 10:29:20 +0100, Terje Mathisen > <Terje.Mathisen@hda.hydro.com> wrote: > >[...] > >I disagree with the exact algorithm he chose for the cases where the > >reciprocal value ends with a fraction which is less than 0.5, but the > >final results are correct and the running speed is pretty much the same > >anyway. > > Terje, could you please elaborate on your prefered alternative > version for that case? OK. If the exact reciprocal is on the form 0xXXXXXXXX.0XXX... then a 33-bit reciprocal is needed. This reciprocal value will have both the top and the bottom bit set, so either of them can be added in after the multiplication. a) Remove the top bit, put remaining 32 bits into EBX ; EAX has number to be divided mov ecx,eax ; Make a copy of the input mov ebx,[bottom_32_bits_of_reciprocal] mul ebx add edx,ecx ; Add into the top dword, effectively mul by 2^32 ; At this point we can get an overflow, which must be handled: rcr edx,1 ; Find the final answer by shifting down EDX: mov cl,[bits_to_shift] shr edx,cl b) Remove the bottom bit: mov ecx,eax ; Make a copy of the input mov ebx,[top_32_bits_of_reciprocal] mul ebx shr ecx,1 ; Shift down the input, to correspond to a 0.5 multiplier add eax,ecx ; Add into the bottom dword adc edx,0 ; Propagate any carry ; Find the final answer by shifting down EDX: mov cl,[bits_to_shift] shr edx,cl With a couple of small tweaks, the same code can be used for all kinds of divisors: mov ebx,[top_32_bits_of_reciprocal] mov ecx,eax ; Make a copy of the input mul ebx and ecx,[mask_33rd_bit] ; -1 or 0 for 33 vs 32-bit reciprocals shr ecx,1 ; Shift down the input, to correspond to a 0.5 multiplier add eax,ecx ; Add into the bottom dword adc edx,0 ; Propagate any carry ; Find the final answer by shifting down EDX: mov cl,[bits_to_shift] shr edx,cl If powers of two are quite likely, esp. if a divisor of 1 is possible, then it becomes useful to specialcase this: mov ebx,[top_32_bits_of_reciprocal] mov ecx,eax ; Make a copy of the input mov edx,eax ; Multiply by 2^32 test ebx,ebx jz power_of_two mul ebx and ecx,[mask_33rd_bit] ; -1 or 0 for 33 vs 32-bit reciprocals shr ecx,1 ; Shift down the input, to correspond to a 0.5 multiplier add eax,ecx ; Add into the bottom dword adc edx,0 ; Propagate any carry ; Find the final answer by shifting down EDX: power_of_two: mov cl,[bits_to_shift] shr edx,cl Terje -- - <Terje.Mathisen@hda.hydro.com> Using self-discipline, see http://www.eiffel.com/discipline "almost all programming can be viewed as an exercise in caching"Article: 19636
Who wants to share his experiences with Generic Digital Crosspoints (GDX) of Lattice Vantis with me? All relevant info appreciated. Thanks. StefArticle: 19637
John Cain wrote: > Ray, > > I have found that intermittant pin connections on FPGA PLCC sockets are > usually due to scope probing during development which bends the contact > leafs inward. This is especially severe when the SW guys are checking the > HW. > > Ray Andraka wrote in message <38603C1A.8AB55592@ids.net>... > >Rich. > > > >I'm surprised you've had good luck with the PLCC 84 sockets and FPGAs. > I've had > >some very bad experiences with those. THey seem OK the first time you put > a chip > >in. Remove and replace the chip once or twice and let the games begin. John, I agree 100%. When I first started using them it was very convenient to slide the probe tip between the socket contact and the side of the device; it sticks in rather nicely. It was one of those "nice thought, bad idea" sort of things. As I said in a previous post, with the use of a good extraction tool and some care, I haven't had any problems since then, even treating the boards somewhat roughly. I also note that these sockets come on commercial test equipment; HP is one vendor that uses them, and they're usually pretty careful about reliability. I'd be interested in hearing about any problems other people have had. Of course, me attempting to solder and then do a R&R on a PLCC84 which have much lower reliability than the socket. :-) Have a good evening, ---------------------------------------------------------------------- rk The world of space holds vast promise stellar engineering, ltd. for the service of man, and it is a stellare@erols.com.NOSPAM world we have only begun to explore. Hi-Rel Digital Systems Design -- James E. Webb, 1968Article: 19638
The following book might be of help, although it is out of print. Perhaps
you can find it in a good library:
Schouhamer Immink, K.A.: Coding techniques for digital recorders.
Prentice Hall, New-York etc. 1991
You can also check the following web site which describes some research on
RS decoders on FPGAs:
http://www.ee.byu.edu/~ahlquist
Finally, if you click the "Recent Publications" button at our web site at
http://www.ece.wpi.edu/Research/crypt
you will find an article by Rosner/Paar about arithmetic for RS decoders
on FPGAs.
Hope that is of some help,
Christof
! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2000) !
! WPI, August 17 & 18, 2000 !
! http://www.ece.wpi.edu/Research/crypt/ches !
***********************************************************************
Christof Paar, Assistant Professor
Cryptography and Information Security (CRIS) Group
ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon:(508) 831 5061 email: christof@ece.wpi.edu
fax:(508) 831 5491 www: http://www.ece.wpi.edu/People/faculty/cxp.html
***********************************************************************
> MK Yap wrote in message <84savt$bo2$1@violet.singnet.com.sg>...
> >Hi,
> >
> >I'm writing a prog (VHDL or C) to enable block encoding and decoding of CD
> >sectors. In the ECC (error correction coding) field, RSPC(Reed Solomon
> >Product Code) is used. The RSPC is a product code over GF(2^8) producing P
> >and Q parity bytes. The GF(2^8) field is generated by the primitive
> >polynomial
> >P(x) = x^8 + x^4 + x^3 + x^2 + 1
> >The P parities are (26,24) RS codeword over GF(2^8) and the Q parities are
> >(45,43) RS codeword over GF(2^8).
> >
> >My question is: How can I write the encoding and decoding algorithm for the
> >ECC field?? The RS used are non standard RS codes (n,k) in which n is
> >usually n=2^m -1 which m=8 in this case...
> >I tried to look for more info from books but it is really limited... I came
> >across some books saying that conventional RS decoding can be used.. that
> is
> >the berlekamp, Peterson and Weldon algorithm. But I see no connection
> >between them coz the derivation is based on a fundamental which is
> >different.
> >
> >Pls enlighten... by providing some books, paper, web site or perhaps
> >explanation of theory behind them... Thank you very much!!
> >
> >Happy Millenium 2000!!
> >
> >MKYap
> >
> >
> >
>
>
>
Article: 19639FPGA Designers Location: Central Connecticut Salary: Open 5+ years experience in designing high speed FPGAs. Experience with ATM, Fram Relay, IP or SONET, very high speed data communications protocols is crucial. Track record of FPGA development using VHDL/Verolog Design simulation using Model Technology desirable. You will work with timing designer, schematic capture packages and provide written specifications for all phases of their design. BSCS or BSEE. A candidate should be comfortable working with the demands of a small startup company. Specifically, the ability to be self-directed, to be able to solve system and tool problems as they arise, etc., would be helpful. Candidates should have good design skills, coding skills, and debugging skills. Embedded Software Engineers Location: Central Connecticut Salary: Open Significant experience in C programming language. Experience in real- time embedded systems, especially for the Data Communications and/or Telecommunications markets. Experience with Data Communications protocols, especially TCP/IP, ATM, SONET, Ethernet, SNMP, etc. Experience with the VxWorks and Tornado operating environment or another real time operating system such as PSOS, VRTX, QNX, etc. Experience with RISC processors would be helpful, particularly Power PC microprocessor. Design and develop a real-time control and maintenance system for carrier class networking products. Experience in real-time embedded systems, such as VxWorks, PSOS, VRTX, etc. in the LAN/WAN area. Experience in fault tolerant systems highly desirable. BSCS or BSEE. The Client, located in central Connecticut, develops leading edge, high speed networking products for telecom service providers. Founded in 1/99 by a team of experienced networking professionals with a successful track record of developing innovative new networking products at companies such as Sahara Networks, Cascade, Ascend, Lucent, Fore Systems and General DataComm. The company is privately held pre- IPO, with 65 person staff and assets of $35M. They offer full benefits and relocation (lump sum). If interested, please send resume to: jobs@careergroupstaffing.com James LaMontagne, CPC Career Group Staffing 181 Park Avenue, PO BOX 772 West Springfield, MA 01090 (413) 785-1818 FAX (413) 785-1977 http://www.careergroupstaffing.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19640
In article <J2pb4.1167$B9.1464225@feed.centuryinter.net>, "Larry Edington" <larryeSpam.Me.Not@centuryinter.net> wrote: > I'm not concerned about a hacker obtaining the contents of the 'logic' in > the FPGA. That I know would be very difficult and those with the resources > to do so would spend those resources designing a new device from scratch. > A pirate could take your config eeprom to a chip vendor (Clear Logic turns Altera configs to ASICs; Chip Express would laser-cut a chip in a day; I think they could work from config file. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19641
In article <AAyb4.1186$B9.1484255@feed.centuryinter.net>, "Larry Edington" <larryeSpam.Me.Not@centuryinter.net> wrote: > So it looks like I do understand after all. Its a really interesting, important problem. Heavily related to crypto, tamper-resistance, watermarking, etc. If you add some extra logic you could prove (later, in court) that the copy is yours, even if you don't get inside the copy. E.g., pull the clone chip, and present an undocument signal to it which causes it to spit out "This IP is property of WidgetCorp". This would work even if the pirates went to ASIC from your config file. > It's not a military device and doesn't have to be super spook secure. I just > wanted to make it hard for casual copying. I know it can be reverse No one has yet mentioned physical packaging, perhaps because its weak, but a blob of opaque epoxy will present a small obstacle. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19642
Since the pirates will be doing a lot of reverse engineering, its worthwhile pointing out that a DES cracker is less than a quarter million U$D. 3DES (with a 56x3 bit key) would be slower but who cares, its just used at init time. There are probably some good compound-LFSR-based stream ciphers which would take less resources too, though less well known/historical as DES. Also, if you make each eeprom's key unique, you 'watermark' the eeprom: you can tell whose instance was cloned. It would be a pain by hand but the right combo of circuits and tools would make it worthwhile. Security always costs *some* convenience. In article <dPOb4.669$197.60977@news.goodnet.com>, "John Cain" <jjcain@goodnet.com> wrote: > Larry, > SRAM FPGAs could easily be made secure by the addition of a fixed DES > Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed. > Now you can OTP the FPGA device key & encript the external configuration > eeprom and everything remains protected. > > A DES cell would not be that big with current FPGAs based on <0.25u CMOS > processes. Better FPGA protection is definitely necessary as digital > embedded > products become a single chip system based on an FPGA. > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19643
One of the problems with encrypting the bitstream is that a large part of the bit stream and its timing is a known constant (header, and lots of zero bits), which makes it a bit easier for the attacker. randombit@my-deja.com wrote: > In article <AAyb4.1186$B9.1484255@feed.centuryinter.net>, > "Larry Edington" <larryeSpam.Me.Not@centuryinter.net> wrote: > > So it looks like I do understand after all. > > Its a really interesting, important problem. Heavily > related to crypto, tamper-resistance, watermarking, etc. > > If you add some extra logic you could prove (later, > in court) that the copy is yours, even if you don't > get inside the copy. E.g., pull the clone chip, > and present an undocument signal to it which causes > it to spit out "This IP is property of WidgetCorp". > This would work even if the pirates went to ASIC from > your config file. > > > It's not a military device and doesn't have to be super spook secure. > I just > > wanted to make it hard for casual copying. I know it can be reverse > > No one has yet mentioned physical packaging, perhaps because > its weak, but a blob of opaque epoxy will present a small obstacle. > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19644
As some might recall, I posted a couple of weeks ago regarding a bone-chilling Spartan problem that we'd been battling for a (large) number of weeks. Tonight it was solved, and you aren't going to believe it... To recap: The problem could be reproduced in about 20 lines of VHDL. We had experienced it in both the XCS40 (PQFP208) and the XCS10 (PLCC84), both in 5V. The short version is that upon completion of configuration (via JTAG, and yes, the DONE pin went high indicating successful config) the part's combinatorial logic (ie address decoders) would work flawlessly and the registered logic (ie a couple of latches off of a 2MHz data bus) would never accept data, instead holding their outputs permanently low despite probes indicating all the signals necessary for setting them were present. To cut to the smooching and violin music, the problem was not with the VHDL, constraints, or anything else. It was with Foundation 2.1i w/ service pack 3. We don't yet understand on a cycle-by-cycle basis exactly what was going on, but the essence of it is that there's a configuration option in the bitstream generator that tells the part how many CCLK cycles to wait after completion of configuration before letting all the registers out of reset. This is straightforward enough if you're doing serial configuration, but we're doing JTAG, and it's not entirely clear at this point what the precise relationship is between the JTAG timing and that of a serial clock not being used for configuration. In any event, the default setting for this is "3", and this is apparently one more than actually occurs in the course of JTAG programming. So it sat, holding every register in the part in reset, patiently waiting for a clock pulse that never came. Changing this setting to its lowest value, "2", caused the design to magically leap to life. Where to find this bit of pure evil? In the Design Manager: Design Options Configuration Edit Options Startup Release Set/Reset C2 C3 C4 If we'd been doing serial programming instead of JTAG, we would have never suffered this bizarre failure. Extensive thanks for the interminable perseverance demonstrated by Kirk Saban of Insight (our disty) and Harvey Ehrenholz of Electrosource, (the rep) both here in Calgary. It was another of Insight's FAEs that gave us the hint leading to the answer after the Xilinx factory app engs failed to reproduce the error. Presumably their software was not set to the out-of-box defaults. Xilinx will be getting the bill for the single malt. And thanks, of course, to all the comp.arch.fpga readers who responded to my pleas for help. JonathanArticle: 19645
Has anybody tried and used a Virtex in a BGA socket ? If yes which socket models ? It's for a 100MHz design. Thanks Marc BattyaniArticle: 19646
Marc Battyani <Marc_Battyani@csi.com> wrote in message
news:7F332B48B96A2E07.CD1B60C042D659F2.0650BA8808E3C344@lp.airnews.net...
> Has anybody tried and used a Virtex in a BGA socket ?
> If yes which socket models ?
> It's for a 100MHz design.
>
I've used BGA sockets from Advanced Interconnections
(http://www.advintcorp.com) for this ("TrueBGA" series, requires no adapter
soldered to BGA package, same footprint as BGA package itself) with a Virtex
BGA560 package. I had some trouble with the corner guides which were too
tight (had to remove some epoxy), Avanced claims that they have fixed this
now. The coin screw has been a bit difficult to tighten hard enough (partly
due to the previous problem), thus I've enlarged the cutout for a
screwdriver. Also had one socket delivered which lacked two solder balls.
Don't bee too scared by these faults, this was ~1 year ago when the product
was brand new.
I've only used 66 MHz externally with full scale operation, but have tried
some test signals at 100 MHz. Didn't show significant difference from the
expected behavious of a PCB mounted device with the same load (~8 cm track)
Regards,
- Olaf
Article: 19647On Tue, 04 Jan 2000 12:03:20 +0100, Armin Mueller <armin.mueller@stud.uni-karlsruhe.de> wrote: >Now, the "plain text" is (nearly) known. Altera config files consist >of e.g. 90% zeroes, 9% single bit bytes. Compression sort of helps that particular nasty. Add the use of a feedback based encryption scheme (so long as the compression didn't start with a "known" header that was also encrypted) and you'd be pretty safe. I would personally NEVER use DES in ECB mode. If greater design security than this is required, you will likely be building stuff with explosives rigged to an ejector seat, or the product will spend all of it's time guarded by men with attack dogs and automatic weapons. Cheers Stuart For Email remove "NOSPAM" from the addressArticle: 19648
On Wed, 05 Jan 2000 18:14:19 GMT, randombit@my-deja.com wrote: >Since the pirates will be doing a lot of reverse engineering, >its worthwhile pointing out that a DES cracker is less than >a quarter million U$D. 3DES (with a 56x3 bit key) would At that financial cost, the kind of people you will be dealing with STEAL designs, not crack them. They might also not be averse to a bit of "roughing up", or considerably, worse in the pursuit of what would have to be lucrative returns on their "investment". >be slower but who cares, its just used at init time. There are >probably some good compound-LFSR-based stream ciphers which would take >less resources too, though less well known/historical as DES. Stream ciphers range from the noddy continuous XOR with '1' to the "perfection" of the truly random one-time pad. The BIG problem with the use of a stream cipher is (just like a one-time-pad) it can NEVER be restarted with a different message. That's essentially going to prevent the field upgrading of the FPGA. Minor drawback, but there you go. >Also, if you make each eeprom's key unique, you 'watermark' >the eeprom: you can tell whose instance was cloned. Making each corresponding FPGA key unique is a nice way to "license" your hardware upgrades. Maintenance anyone? Cheers Stuart For Email remove "NOSPAM" from the addressArticle: 19649
This is a multi-part message in MIME format. --------------6C3E34CE8D1C75220EF226DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Marc We are using a 3M/TexTool BGA Socket that works pretty well. It clamps on the side above the centerline of the balls so that they can be soldered down later. We're using the sockets for an ASIC not an FPGA but its the same Amkor Super BGA package that the Virtex uses. We wanted to use the same board layout with the socket as we did with the soldered down part as you are doing. We accomplished this even though the socket is a through hole device by putting a via for each BGA pad and opening up the via hole size a little. The pins on the socket are very slim so we can solder the socket into the vias or we can solder the BGA directly onto the BGA pads. In this configuration, I believe this 3M/TexTool BGA Socket should work well above 100MHz. We're hoping to do above 500MHz because the ASIC is GaAs. Good Luck Pete --------------6C3E34CE8D1C75220EF226DE Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Peter Dudley Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Peter Dudley n: Dudley;Peter org: Sandia National Labs adr: box 5800;;Mail Stop 0505;Albuquerque;NM;87185;USA email;internet: padudle@sandia.gov title: SMTS tel;work: 505.844.5565 tel;fax: 505.844.2925 note: Digital Signal Processing in Hardware and Software x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------6C3E34CE8D1C75220EF226DE--
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