Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Mar 5, 6:28=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 4 Mrz., 18:55, John_H <newsgr...@johnhandwork.com> wrote: > > > That would be OK. I only need repeatability over time and temperature. > Different setups can have different skews. Even two identical setups > can have different skews. The skew only leads to a shift of the > resulting > image. That can be calibrated (or even ignored in many cases) > But if I start accumlating an image today and run the experiment for a > week > any shift in skew during that time will smear the image. > > =46rom your original post, it didn't seem that running individual traces from board #1 to each of the other boards was an architectural option for whatever reason, but if it is and you get a beefy enough set of drivers on the board then series terminate the clock. That will distribute the clock signal passively without accumulating any time/ voltage skew caused by the distribution itself (the driver and receivers will still have some) and will have good signal quality at each receiver. Kevin JenningsArticle: 129776
On 5 Mrz., 13:39, rickman <gnu...@gmail.com> wrote: > On Mar 5, 1:01 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > On 5 Mrz., 05:45, rickman <gnu...@gmail.com> wrote: > > > > On Mar 3, 4:42 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > On 3 Mrz., 22:16, DJ Delorie <d...@delorie.com> wrote: > > > > > > Antti <Antti.Luk...@googlemail.com> writes: > > > > > > 2) devices packages like Spartan-3E (including QN132 !) or better > > > > > > (microBGA 6x6 mm?) > > > > > > I keep wondering if there's a market for a few "unbalanced" devices, > > > > > like something with a ton of gates but in a tqfp-64 package. Or BGA > > > > > packages that only use the two outer rows for signals, for simpler > > > > > board routing. > > > > > > Likewise, I'd like to see the occasional MCU with a ton of ram and a > > > > > little flash, rather than the other way as it usually is. Every once > > > > > in a while I need a smart buffer chip :-( > > > > > oh yes, TQFP48 0.5mm pitch FPGA running from single voltage! > > > > defenetly, but hey thats wish for new Lattice device ;) > > > > > BTW, Actel QFN132 3 row QFN 0.5mm pitch CAN be used on > > > > 2 layer PCB or even single layer. > > > > > Antti > > > > I have not looked very hard at the 132 pin QFN package. But at 0.5 mm > > > pin pitch, how exactly do you route signals from the middle row out? > > > I guess the pins are actually 1.5 mm pitch on each row for 0.5 mm > > > considering all three rows? One of the problems I have using 0.65 mm > > > pitch QFPs is that I can't route between the pins. That is a real > > > PITA. I sometimes think I would be better off with a wider pitch > > > part, but I'm not sure I can fit them on the board... :^( > > > its 0.5mm pitch. > > middle row pins can not be used on 2 layer PCB > > only outer and inner row. my application did not > > need much IO so that was sufficient > > I guess your first statement above that the part "CAN be used" on a 2 > layer board means, there is no power or essential control signals on > the middle row? So I guess it can be used if you don't mind losing a > huge percentage of the I/O? right there think is 1 JTAG pin in middle row, this can route out via I/O similarly all VCC/IO in middle row can be routed as needed. AnttiArticle: 129777
On Mar 4, 4:47 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > Antti <Antti.Luk...@googlemail.com> writes: > > 3) Lattice ECP2 have non-volatile AES key, making them best candidate > > if design security/theft is of concern, also the design migration from > > Xilinx to Lattice is much much more easier then Xilinx to Actel > > If it's non-volatile, is it not "relatively easy" to extract the key > from the chip by invasive methods? I say "relatively", compared to > the volatile keys in a virtex device - still not a trivial task :-) > > Cheers, > Martin > > -- > martin.j.thomp...@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html I don't think design security is the issue if the OP's original system had an external PROM, whether or not it was re-programmable. Preventing inadvertent re-programming can be accomplished at the board level as noted, but if the device is delivered as a chip it is not as simple. I've seen microcontrollers programmed and sold as application-specific parts. Often the data sheet for the programmed part does not make it clear where the part came from, and the chip is re-marked. In this sort of scheme, you could always call out the JTAG pins as grounds... What is the actual application? Regards, GaborArticle: 129778
On Tue, 04 Mar 2008 11:08:27 -0800, austin <austin@xilinx.com> wrote: >Frai, > >Other than the public announcement that the NSA has approved V4 for >single chip crypto systems, what else would you need? > >Seriously, no one has broken AES256, and no one has broken V4's >implementation of AES256 (using the battery backed key memory). > >A hacker would not attack directly, rather they would wait outside your >building, and offer cash to anyone willing to reveal the key to them. > >No other device exists that is 'generic' approved for all NSA single >chip crypto systems. No ASIC, ASSP, nor FPGA. It has been called >"completely disruptive technology" and many have told us "V4 will >revolutionize the single chip crypto market." > >http://www.xilinx.com/prs_rls/2007/end_markets/0713_v4nsa.htm > >I just love it when there is 0 competition! Hi Austin, Altera StratixII has bitstream encryption, with keys programmed (one time!) into poly fuses. Altera Stratix3 has bitstream encryption, with the option of keys programmed into poly fuses OR held in battery backed SRAM. Presumably you are aware of both of these products. Do you know of some fault in their implementation that would lead you to describe them as "0 competition"? Thanks, AllanArticle: 129779
On Mar 5, 4:46 am, nezhate <mazouz.nezh...@gmail.com> wrote: > Hi All, > I want to implement a BERT test on FPGA. Can anyone give or point me > to some good documentation for understanding how BERT test works? > Thanks. BERT is a technique rather than a functional unit like a UART. It just means you are measuring the error rate of a communication channel. This typically involves either the test equipment operating in a looped back circuit so that it sends a data pattern and compares the received data to that pattern counting the errors, or two units are at opposite ends of a channel with one sending a predetermined pattern and the other receiving and comparing to the expected pattern. This pattern is often a pseudo random sequence to assist in synchronizing to the pattern, but is ad hoc to the application. So you have to decide how to do BERT depending on your application. Is this a conventional app or a proprietary app? RickArticle: 129780
Allan, No Altera product with poly efuse is able to meet FIPS 41, none are approved by the NSA. In my book, that means we see no competition (all customers that require FIPS 41, or NSA approval come to Xilinx). Now, if you do not require FIPS 41, or you are not interested in NSA compliance, then the Altera solutions are perfectly good, and useful. In no way do I imply they are poor solutions, however, they are not in compliance with the highest level standards, and they are not approved for generic use in US government contracts. That means, they are not a solution for banking (which requires FIPS 41), and other commercial markets as well. What is left? From the "Virtex" point of view, nothing at all of import. Perhaps in the Cyclone/Spartan world, there are some good sockets they win (and we do too) for anti-cloning of consumer goods. I am sure they will have FIPS 41 compliant products at some point. I am also sure they will eventually get NSA approval (if they can meet their requirements, as the US government is not allowed to play favorites, and must treat all fairly). Until then, we enjoy the sockets we are getting, AustinArticle: 129781
Would this eeprom work as a configuration boot eeprom for Xilinx XC3S500E ..? http://ww1.microchip.com/downloads/en/DeviceDoc/22065A.pdfArticle: 129782
On Wed, 5 Mar 2008 01:46:45 -0800 (PST), nezhate
<mazouz.nezhate@gmail.com> wrote:
>Hi All,
>I want to implement a BERT test on FPGA. Can anyone give or point me
>to some good documentation for understanding how BERT test works?
>Thanks.
I've implemented BERTs in a few products at rates up to 10Gb/s in
FPGA.
I have not found good, free documentation describing how it's done
properly though.
So I will give you some pointers here.
Firstly, I assume that you mean a traditional serial BERT. These are
intended for testing serial bit streams. BTW, Don't use these if you
have a parallel bus; they don't produce enough transitions to stress
the DUT properly.
The serial BERT patterns are actually standardised. Standardisation
helps to ensure that a BERT receiver from one manufacturer will lock
to a BERT generator from another manufacturer.
Please refer to ITU-T O.150 through 153, especially O.151.
Free download from official site here:
http://www.itu.int/rec/T-REC-O/e
You choose the pattern (e.g. 2^23) based on the run length
requirement. Since (I assume) you are designing your system, you
should already know the expected run length on the serial line. Choose
a pattern to match that.
E.g. the 2^23 pattern from O.151 has a maximum run length of 23.
The hardware for the O.151 patterns are described in that document as
LFSRs, e.g. shift registers with linear (i.e. xor) feedback. This is
fine for bitrates up to some hundreds of MHz; the LFSR will produce
one bit of output per clock.
For bitrates higher than that, you will need to convert the LFSR to a
parallel form that produces several bits per clock. This allows you
to keep the clock rate to something managable in an FPGA (e.g. <
200-300MHz). E.g. The last one of these I did (SONET, 10Gb/s) had a
clock rate of 155.52MHz and a 64 bit bus.
I won't describe the process to convert the "serial prototype" to a
parallel form, but you shouldn't find it difficult to work out the
details yourself. (Or start another thread :)
First gotcha: The O.151 generators all have lockup states. For
example, the 2^23 pattern is locked up when it outputs more than 23
zeros in a row. It will continue to produce all zeros until you
detect the problem and kickstart it by injecting a one into it
somewhere.
The measurement process is best described with a diagram:
"Serial prototype" of Generator:
+------------------<----------------+
| +---------------<----------+ |
| | | |
| | tap1| |tap2
| | | |
+-----+ A +--------------------------+
| XOR |-+--->| >> Tx Shift register >> |
+-----+ | +--------------------------+
|
|
|
+ Output of generator
|
|
|
errors +-----+
------->| XOR | This models the channel,
+-----+ which adds some errors.
|
|
|
|
|
"Naive" serial model of receiver:
|
+--------+
| |
+-----+ | A' +-----+
| XOR |-|------| XOR |---> errors out
+-----+ | +-----+
| | | +--------------------------+
| | +--->| >> Rx Shift register >> |
| | +--------------------------+
| | tap1| |tap2
| | | |
| +---------------<----------+ |
+------------------<----------------+
If the channel doesn't inject any errors (i.e. the "errors" signal is
0), the same bits will pass through both Tx and Rx shift registers,
and the feedback point A' in the receiver will match the feedback
point A in the transmitter. In this case, the "errors out" signal
will be low.
Now consider injecting a single bit error, by making the "errors"
signal high for one clock. This will produce a mismatch between the
receiver input and point A', which will make "errors out" high (good).
However, the bit error will also pass through the Rx shift register.
As it passes tap1 and tap2, it will also make "errors out" high. This
effect is known as Bit Error Multiplication (when applied to
scramblers), and is a problem if we are trying to get an accurate BERT
measurement. This is why I described that receiver design as "naive".
Here's how we fix it:
"Improved" model of receiver:
|
+---+---------+
| |
+-----+ | A' +-----+
| XOR |-+---|-------| XOR |---> errors out
+-----+ | | +-----+
| | | +-----+ +--------------------------+
| | +-| MUX |-->| >> Rx Shift register >> |
| | +-----+ +--------------------------+
| | tap1| |tap2
| | | |
| +--------------------<----------+ |
+-----------------------<----------------+
Now we have a multiplexer that can select either the receiver input,
or the locally generated feedback signal as the input of the shift
register.
We have introduced the concept of a "mode". In Unlocked mode, we take
the input from the line, as before. When we don't see "errors out"
high for a while, we can switch to Locked mode, and connect the
locally generated feedback signal 'A' to the input of the shift
register. The Rx Shift register is now completely decoupled from the
Tx shift register. They will have the same value, however, and each
incoming bit error produces a single high signal on the "errors out"
line. These should be counted, etc.
If "errors out" shows an excessive number of errors (e.g. high for
more than about 25% of the time), we should switch back to Unlocked
mode. N.B. A completely bad input signal will produce a BER of about
50% (not 100%) which is why we should set the unlocked threshold at
less than 50%.
I hope this helps.
Regards,
Allan
Article: 129783On Wed, 05 Mar 2008 08:19:08 -0800, austin <austin@xilinx.com> wrote: >Allan, > >No Altera product with poly efuse is able to meet FIPS 41, none are >approved by the NSA. > >In my book, that means we see no competition (all customers that require >FIPS 41, or NSA approval come to Xilinx). > >Now, if you do not require FIPS 41, or you are not interested in NSA >compliance, then the Altera solutions are perfectly good, and useful. >In no way do I imply they are poor solutions, however, they are not in >compliance with the highest level standards, and they are not approved >for generic use in US government contracts. > >That means, they are not a solution for banking (which requires FIPS >41), and other commercial markets as well. > >What is left? From the "Virtex" point of view, nothing at all of import. > >Perhaps in the Cyclone/Spartan world, there are some good sockets they >win (and we do too) for anti-cloning of consumer goods. > >I am sure they will have FIPS 41 compliant products at some point. I am >also sure they will eventually get NSA approval (if they can meet their >requirements, as the US government is not allowed to play favorites, and >must treat all fairly). Until then, we enjoy the sockets we are getting, Thanks for the explanation. We make various data security products, some with FIPS 140 certification (or under evaluation). However, the entire product gets certified, not just some chip in the middle of the box. On that basis, I wouldn't have problems using Altera parts in a FIPS certified product. (Some applications put the "security boundary" at the chip, but that doesn't apply to us.) BTW, we had been ordering Xilinx V2P parts for an older product, with the special order code that means that the DES bitstream encryption gets tested. We were advised by our supplier that these will no longer be available. What's the story there? Will the same thing happen to our V4 designs? Regards, AllanArticle: 129784
rickman <gnuarm@gmail.com> wrote: >On Mar 3, 5:08 pm, n...@puntnl.niks (Nico Coesel) wrote: >> "M.Randelzhofer" <techsel...@gmx.de> wrote: >> >"Antti" <Antti.Luk...@googlemail.com> schrieb im Newsbeitrag >> >news:467475ec-6d16-4789-acec-07d3c1a4977e@s19g2000prg.googlegroups.com... >> >> here it is: >> >> >> 1) devices densities like in Spartan-3 (50..5000) >> >> 2) devices packages like Spartan-3E (including QN132 !) or better >> >> (microBGA 6x6 mm?) >> >> 3) all good features of S3A/AN !! >> >> 4) design security with OTP encryption key (like Lattice ECP2) >> >> 5) other features as already planned by Xilinx >> >> >> Antti >> >> has made his Christmas wish this year... or did I just describe >> >> Lattice XP3 or Cyclone IV? >> >> eh, I just wish Spartan-4 will have all the good things from Spartan-3 >> >> subfamilies+extra goodies. >> >> >Hi Antti, >> >> >I've the same wishes, some additional i/O & memory cores would be nice: >> >> >6) USB2 host/slave interface with integrated PHY >> >> >7) Ethernet MAC + PHY >> >> >8) DDR2/3 core >> >> >9) some analog stuff (ADC, temp sensor, system supervisor) >> >> >S4 would be a serious competitor to 32bit microcontrollers, if some of their >> >standard peripherals are included in low price FPGA's. >> >> You forget a standard ARM core, some internal flash (say 32KB to >> 256KB), some memory (8KB to 64KB) and some standard pheripherals like >> UART, SPI, I2C. Such a device would be a real killer. I would design >> it in straight away if it existed today for a Spartan price. > >I thought you could get all that in an MCU? At that point do you even >need the FPGA anymore??? Well, the FPGA usually handles the fast stuff. In most devices which use an FPGA you'll find an MCU as well. So why not embed the MCU + flash +sram inside the FPGA. Sure there is Microblaze and Nios but they cost a lot of logic real-estate and have no internal flash. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 129785
Allan,
The special order codes ('SCD') are best when folded into the normal
production, so no special anything is required. The special code goes
away, and the regular product supports the feature.
This is unique to only some parts/packages/test programs, and is never
intended to last forever (only to improve quality for specific customers
when the test program isn't complete). When we are made aware of a test
coverage gap, we improve the test program. Once the test program is
sufficiently integrated, we can retire the special flow.
Understand that a 1000 ppm "test escape" is considered a terrible thing
by Xilinx, as we strive to achieve "0 defects."
We have had cases where a particular customer brings to our awareness a
test escape issue, and often no other customer has noticed the issue
(many 10's of thousands of parts shipped, with no returns whatsoever).
Regardless, every test escape is taken very seriously, as it reflects
directly on the product quality, and our customer's trust in Xilinx (to
do the job right).
The (3DES/AES256 key) features are standard, and fully supported. If a
feature is to be removed, we must issue a 'PCN' (production change
notice, which allows 90 days before it is implemented, and also allows
for last time orders before we remove anything at all), and notify
everyone. That is a very rare event (as it has to be).
Austin
Article: 129786Does anyone have 20-100 pieces of a Xilinx Virtex 5 (XC5VLX85-2FFG676C ) they can spare? I can not wait the factory lead time. Thanks to all that take the time to look into. I also need 140 of the XC5VLX85-2FFG1153C Regards, Jon E. Hansen (949)864-7745 directArticle: 129787
Hi some things are cute to trash, so if anyone cares for an item that could have its honor place in "FPGA museum", here it is: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=190204160335 A Xilinx XC3030 based device manufactured by GRU (== russian CIA). I found it in the cellar. And no, I did not get it directly from the source ;) AnttiArticle: 129788
Frai,
There are many who claim "oh, this is easy..."
However, back in the Virtex II Pro days, we issued a challenge, and more
than 7 universities and research groups accepted the challenge.
We provided a 2vp7 pcb with usb port, and pins for access to power, that
had the key battery installed (300 mA lithiumm coin cell), and the part
was programmed with a 3DES encrypted bitstream.
All 7 challengers gave up. Their basic conclusion was all the things
they thought would work, differential power attack, spoofing by power
glitches, attack with freeze spray, etc. FAILED.
Now, can someone crack the scheme, and get the unencrypted bitstream?
Well, we are unable to get anyone interested to try it, as they tried
the obviously less secure 3DES, and didn't get anywhere.
Also, I presume the NSA tried, as they eventually approved V4. If I was
the NSA, I would have put a great deal of effort to try to break it if I
knew that the devices would go into all modern crypto-systems! However,
I know nothing of what they did (their report is classified).
Unfortunately, no one publishes a master's thesis or PhD thesis that
says "I failed to crack this encryption" so there are no records of
these attempts failing. But, no one has been able to get at the key, or
to find anything about the bitstream, ever since we first introduced the
features starting with Virtex II.
On the other hand, polarized light, and a high school microscope, can be
used to read the state of any efuses in a chip (which is why they are
excluded as a solution by the standards). The fact that some vendors
scramble their efuse contents just means that they do not really
understand what security is all about ("there is no security in
obscurity"). Once the "secret" is out (by reverse engineering the
hardware or software), then all of the products shipped become vulnerable.
Our approach has no secrets whatsoever: the algorithm is public, as is
the design of the encryptor and decryptor. That is why it complies with
the standards for constructing a secure system.
Austin
Article: 129789
"Allan Herriman" <allanherriman@hotmail.com> wrote in message
news:94fts3h0p9mp4b49r6ds9ksuln3ninphaj@4ax.com...
> "Improved" model of receiver:
> |
> +---+---------+
> | |
> +-----+ | A' +-----+
> | XOR |-+---|-------| XOR |---> errors out
> +-----+ | | +-----+
> | | | +-----+ +--------------------------+
> | | +-| MUX |-->| >> Rx Shift register >> |
> | | +-----+ +--------------------------+
> | | tap1| |tap2
> | | | |
> | +--------------------<----------+ |
> +-----------------------<----------------+
> If "errors out" shows an excessive number of errors (e.g. high for
> more than about 25% of the time), we should switch back to Unlocked
> mode. N.B. A completely bad input signal will produce a BER of about
> 50% (not 100%) which is why we should set the unlocked threshold at
> less than 50%.
>
> I hope this helps.
>
> Regards,
> Allan
Hi Allan,
There's a better way to detect whether to resync or not. There's no point in
resyncing unless the incoming stream has 'slipped' one or more bit positions
relative to where it should be. When this situation arises, the 'errors out'
output of the 'Improved' circuit you drew (see above) will have the same
PRBS on it but with a phase shift of some amount. This is because a PRBS
xored with a shifted version of itself is the same PRBS but shifted some
other amount. I'll leave the modulo arithmetic that proves this as an
exercise for the reader! So, the trick is to then feed this 'errors out'
signal into your first 'naive' circuit, this one,
'errors out'
V
> |
> +--------+
> | |
> +-----+ | A' +-----+
> | XOR |-|------| XOR |---> slip errors out
> +-----+ | +-----+
> | | | +--------------------------+
> | | +--->| >> Rx Shift register >> |
> | | +--------------------------+
> | | tap1| |tap2
> | | | |
> | +---------------<----------+ |
> +------------------<----------------+
>
and only resync if 'slip errors out' is very low. So, in summary, resync
when 'errors out' is often high, maybe above 25%, but 'slip errors out' is
often low, maybe a few percent. This improved method makes it easy to
measure bit errors in circumstances where there are burst of high bit error
rate. The circuit won't accidently resync because of the burst unless a
genuime slip occurs.
HTH., Syms.
p.s. I think this method was invented by a German guy named Gelbrich.
Article: 129790
On 5 Mrz., 20:31, austin <aus...@xilinx.com> wrote:
> Frai,
>
> There are many who claim "oh, this is easy..."
>
> However, back in the Virtex II Pro days, we issued a challenge, and more
> than 7 universities and research groups accepted the challenge.
>
> We provided a 2vp7 pcb with usb port, and pins for access to power, that
> had the key battery installed (300 mA lithiumm coin cell), and the part
> was programmed with a 3DES encrypted bitstream.
>
> All 7 challengers gave up. Their basic conclusion was all the things
> they thought would work, differential power attack, spoofing by power
> glitches, attack with freeze spray, etc. FAILED.
>
> Now, can someone crack the scheme, and get the unencrypted bitstream?
> Well, we are unable to get anyone interested to try it, as they tried
> the obviously less secure 3DES, and didn't get anywhere.
>
> Also, I presume the NSA tried, as they eventually approved V4. If I was
> the NSA, I would have put a great deal of effort to try to break it if I
> knew that the devices would go into all modern crypto-systems! However,
> I know nothing of what they did (their report is classified).
>
> Unfortunately, no one publishes a master's thesis or PhD thesis that
> says "I failed to crack this encryption" so there are no records of
> these attempts failing. But, no one has been able to get at the key, or
> to find anything about the bitstream, ever since we first introduced the
> features starting with Virtex II.
>
> On the other hand, polarized light, and a high school microscope, can be
> used to read the state of any efuses in a chip (which is why they are
> excluded as a solution by the standards). The fact that some vendors
> scramble their efuse contents just means that they do not really
> understand what security is all about ("there is no security in
> obscurity"). Once the "secret" is out (by reverse engineering the
> hardware or software), then all of the products shipped become vulnerable.
>
> Our approach has no secrets whatsoever: the algorithm is public, as is
> the design of the encryptor and decryptor. That is why it complies with
> the standards for constructing a secure system.
>
> Austin
the V2P crack challenge bounty was total 25KUSD?
or was it even less? well doesnt matter it was defenetly less
then needed for anyone to REALLY try crack the V2P key.
it doesnt mean it would be doable, only that the university
results are not "final judge".
And the whatever (if) NSA did is classified...
But, yes the BEST security is FPGA with NONVOLATILE key.
FIPS also requires KEY CLEAR, what is only supported by V-5 without
external circuitry.
Everything flash based or with something nonvolatile is instantly less
secure.
What I have heard the "thumb estimate" to read out ANY FLASH
based microcontrollers protected code is about 1000 USD.
Reading back a protected ATmega8 has been as cheap as 800RMB (112USD)
(no I have not done that, I just know the work being quoted at that
price)
Sure that was thumb estimate, the price for some flash MCU could be
higher.
I assume its only valid for normal Flash MCUs not for those designed
for increased security.
Reading e-fuses with microscope in the UNI, well it sure can be
possible, I have
myself placed a needle with bare hands onto 6 micron track on the die
of Motorola ROM
based smartcard chip. LOOOOONG time ago. that was not-secure
technology, and very old.
With little better tools the modern chips could possible be hacked as
well, but the easiness
of efuses reading, I think its not that trivial either. In the market
segment where product cloning
is major issue there is NO KNOWN case of Actel chip being cloned ever.
And the people who
would like to clone Actel based products are not some students, but
some smaller ASIC people.
But in MOST cases the security is downgraded by other means, not the
main key/algorithm.
As example the Nintendo WII is protected by AES key, stored in OTP
area on custom ASIC.
This key has _never_ been read out, but the protection has been broken
by side-channel attacks.
The first break in into system was by swapping address lines between
main CPU and ASIC,
later a stack-overflow exploit was found. By inserting "Twilight
Princess" DVD and using
modified saved game that causes stack fault the AES security is fully
bypassed without
opening the WII.
... So having the FPGA AES protected is nice.
But that says NOTHING about the overall system security and protection
at all.
Antti
Article: 129791On Wed, 5 Mar 2008 19:42:23 -0000, "Symon" <symon_brewer@hotmail.com> wrote: >"Allan Herriman" <allanherriman@hotmail.com> wrote in message >news:94fts3h0p9mp4b49r6ds9ksuln3ninphaj@4ax.com... > >> "Improved" model of receiver: >> | >> +---+---------+ >> | | >> +-----+ | A' +-----+ >> | XOR |-+---|-------| XOR |---> errors out >> +-----+ | | +-----+ >> | | | +-----+ +--------------------------+ >> | | +-| MUX |-->| >> Rx Shift register >> | >> | | +-----+ +--------------------------+ >> | | tap1| |tap2 >> | | | | >> | +--------------------<----------+ | >> +-----------------------<----------------+ > > >> If "errors out" shows an excessive number of errors (e.g. high for >> more than about 25% of the time), we should switch back to Unlocked >> mode. N.B. A completely bad input signal will produce a BER of about >> 50% (not 100%) which is why we should set the unlocked threshold at >> less than 50%. >> >> I hope this helps. >> >> Regards, >> Allan > >Hi Allan, >There's a better way to detect whether to resync or not. There's no point in >resyncing unless the incoming stream has 'slipped' one or more bit positions >relative to where it should be. When this situation arises, the 'errors out' >output of the 'Improved' circuit you drew (see above) will have the same >PRBS on it but with a phase shift of some amount. This is because a PRBS >xored with a shifted version of itself is the same PRBS but shifted some >other amount. I'll leave the modulo arithmetic that proves this as an >exercise for the reader! So, the trick is to then feed this 'errors out' >signal into your first 'naive' circuit, this one, > > 'errors out' > V >> | >> +--------+ >> | | >> +-----+ | A' +-----+ >> | XOR |-|------| XOR |---> slip errors out >> +-----+ | +-----+ >> | | | +--------------------------+ >> | | +--->| >> Rx Shift register >> | >> | | +--------------------------+ >> | | tap1| |tap2 >> | | | | >> | +---------------<----------+ | >> +------------------<----------------+ >> >and only resync if 'slip errors out' is very low. So, in summary, resync >when 'errors out' is often high, maybe above 25%, but 'slip errors out' is >often low, maybe a few percent. This improved method makes it easy to >measure bit errors in circumstances where there are burst of high bit error >rate. The circuit won't accidently resync because of the burst unless a >genuime slip occurs. > >HTH., Syms. > >p.s. I think this method was invented by a German guy named Gelbrich. Nice. I'll try that one the next time I have to implement a BERT. Regards, AllanArticle: 129792
On Wed, 05 Mar 2008 10:19:48 -0800, austin <austin@xilinx.com> wrote:
>Allan,
>
>The special order codes ('SCD') are best when folded into the normal
>production, so no special anything is required. The special code goes
>away, and the regular product supports the feature.
>
>This is unique to only some parts/packages/test programs, and is never
>intended to last forever (only to improve quality for specific customers
>when the test program isn't complete). When we are made aware of a test
>coverage gap, we improve the test program. Once the test program is
>sufficiently integrated, we can retire the special flow.
>
>Understand that a 1000 ppm "test escape" is considered a terrible thing
>by Xilinx, as we strive to achieve "0 defects."
>
>We have had cases where a particular customer brings to our awareness a
>test escape issue, and often no other customer has noticed the issue
>(many 10's of thousands of parts shipped, with no returns whatsoever).
>
>Regardless, every test escape is taken very seriously, as it reflects
>directly on the product quality, and our customer's trust in Xilinx (to
>do the job right).
>
>The (3DES/AES256 key) features are standard, and fully supported. If a
>feature is to be removed, we must issue a 'PCN' (production change
>notice, which allows 90 days before it is implemented, and also allows
>for last time orders before we remove anything at all), and notify
>everyone. That is a very rare event (as it has to be).
Thanks for the clarification. Our purchasing guy was worried about
this. But... no longer.
Regards,
Allan
Article: 129793Antti <Antti.Lukats@googlemail.com> wrote: >Hi >some things are cute to trash, so if anyone cares for an item that >could have its honor place in "FPGA museum", here it is: >http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=190204160335 >A Xilinx XC3030 based device manufactured by GRU (== russian CIA). >I found it in the cellar. >And no, I did not get it directly from the source ;) What did the chips & software cost at the time..?Article: 129794
On 5 Mrz., 22:15, sky46...@trline5.org wrote: > Antti <Antti.Luk...@googlemail.com> wrote: > >Hi > >some things are cute to trash, so if anyone cares for an item that > >could have its honor place in "FPGA museum", here it is: > >http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=190204160335 > >A Xilinx XC3030 based device manufactured by GRU (== russian CIA). > >I found it in the cellar. > >And no, I did not get it directly from the source ;) > > What did the chips & software cost at the time..? :) nothing / as not in shops... pretty much ALL electronic components sales at that time was black- market only. And almost all of them was stolen from the military fabs. There was very little in the official shops, the real component market was openly-hidden somewhere close by in big cities Moscow/St. Petersburg. In other places there was possible some "guy" coming each few weeks with "stuff" so you could "pre-order" things from him. Or you could go yourself to the cities where the fabs where and deal there yourself. Funny times. But when you ask the prices, actually I do recall the pricing, think not much different than now XC2064 around 15 USD I think. I recall it because in one design I used 13 GAL's what was not much more then price of cheapest Xilinx chip and the GAL's where around 1 USD AnttiArticle: 129795
On 5 Mrz., 17:30, sky46...@trline5.org wrote: > Would this eeprom work as a configuration boot eeprom for Xilinx XC3S500E ..? > http://ww1.microchip.com/downloads/en/DeviceDoc/22065A.pdf generic answer: RTFM 25xxx chips are what is normally described "standard SPI", and have 0x03 READ command, so i would say its ok. But to be sure please verify that it is OK, dont take my word (or anyone elses) AnttiArticle: 129796
Allen, If your purchasing guy has any problems, have him email me with the SCD number. AustinArticle: 129797
>Also, I presume the NSA tried, as they eventually approved V4. If I was >the NSA, I would have put a great deal of effort to try to break it if I >knew that the devices would go into all modern crypto-systems! However, >I know nothing of what they did (their report is classified). NSA may have their resons to not approve crypto systems that are "too good".Article: 129798
Antti, Good points. Even the best component security doesn't equate to a high level of system security. You are also correct to point out the Actel antifuse (basically a via that can be 'popped') where is 'impossible' to map all of them, and hence how the part is programmed. This is only because no one has automated this attack: if automated, it could be done (shave off 10 angstroms, take a picture, repeat, then rebuild the connections). Don't forget some attackers have infinite labor, and infinite patience. My favorite example is when the students took over the American Embassy in Iran, and then put back together all of the shredded secret documents ... a massive task, but just a big puzzle after all (and one that could be, and was, solved). AustinArticle: 129799
I knew someone would say this, Yes, there are those that think because the NSA approves a crypto standard, they either have a back door, or some other way around it. You give them far too much credit. They are not that smart. If there is a weakness, or a back door, then they have created a way for all systems they certify to be broken. They are also not that stupid. Austin
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