Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 129775

Article: 129775
Subject: Re: clock distribution accross boards
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 5 Mar 2008 05:03:37 -0800 (PST)
Links: << >>  << T >>  << A >>
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 Jennings

Article: 129776
Subject: Re: my Spartan-4 wishlist
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 5 Mar 2008 05:25:16 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Antti




Article: 129777
Subject: Re: Is there any way to disable JTAG for Sptantan3AN
From: Gabor <gabor@alacron.com>
Date: Wed, 5 Mar 2008 05:51:51 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Gabor

Article: 129778
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: Allan Herriman <allanherriman@hotmail.com>
Date: Thu, 06 Mar 2008 02:29:25 +1100
Links: << >>  << T >>  << A >>
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,
Allan

Article: 129779
Subject: Re: Bit Error Rate Test
From: rickman <gnuarm@gmail.com>
Date: Wed, 5 Mar 2008 07:57:16 -0800 (PST)
Links: << >>  << T >>  << A >>
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?

Rick

Article: 129780
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: austin <austin@xilinx.com>
Date: Wed, 05 Mar 2008 08:19:08 -0800
Links: << >>  << T >>  << A >>
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,

Austin

Article: 129781
Subject: Spartan-3E + SPI EEPROM
From: sky465nm@trline5.org
Date: Wed, 5 Mar 2008 17:30:20 +0100 (CET)
Links: << >>  << T >>  << A >>
Would this eeprom work as a configuration boot eeprom for Xilinx XC3S500E ..?
  http://ww1.microchip.com/downloads/en/DeviceDoc/22065A.pdf


Article: 129782
Subject: Re: Bit Error Rate Test
From: Allan Herriman <allanherriman@hotmail.com>
Date: Thu, 06 Mar 2008 03:38:33 +1100
Links: << >>  << T >>  << A >>
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: 129783
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: Allan Herriman <allanherriman@hotmail.com>
Date: Thu, 06 Mar 2008 04:26:34 +1100
Links: << >>  << T >>  << A >>
On 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,
Allan

Article: 129784
Subject: Re: my Spartan-4 wishlist
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 05 Mar 2008 17:27:01 GMT
Links: << >>  << T >>  << A >>
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
Subject: Removal of a feature, moving SCD to production
From: austin <austin@xilinx.com>
Date: Wed, 05 Mar 2008 10:19:48 -0800
Links: << >>  << T >>  << A >>
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: 129786
Subject: Virtex 5
From: jon <jon@pyramidemail.com>
Date: Wed, 5 Mar 2008 11:01:11 -0800 (PST)
Links: << >>  << T >>  << A >>
Does 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 direct

Article: 129787
Subject: Anyone to open "FPGA museum" ? Here is first item :)
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 5 Mar 2008 11:25:26 -0800 (PST)
Links: << >>  << T >>  << A >>
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 ;)

Antti

Article: 129788
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: austin <austin@xilinx.com>
Date: Wed, 05 Mar 2008 11:31:58 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Bit Error Rate Test
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 5 Mar 2008 19:42:23 -0000
Links: << >>  << T >>  << A >>
"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
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 5 Mar 2008 12:21:09 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 129791
Subject: Re: Bit Error Rate Test
From: Allan Herriman <allanherriman@hotmail.com>
Date: Thu, 06 Mar 2008 07:28:19 +1100
Links: << >>  << T >>  << A >>
On 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,
Allan

Article: 129792
Subject: Re: Removal of a feature, moving SCD to production
From: Allan Herriman <allanherriman@hotmail.com>
Date: Thu, 06 Mar 2008 07:30:46 +1100
Links: << >>  << T >>  << A >>
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: 129793
Subject: Re: Anyone to open "FPGA museum" ? Here is first item :)
From: sky465nm@trline5.org
Date: Wed, 5 Mar 2008 22:15:59 +0100 (CET)
Links: << >>  << T >>  << A >>
Antti <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
Subject: Re: Anyone to open "FPGA museum" ? Here is first item :)
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 5 Mar 2008 13:31:14 -0800 (PST)
Links: << >>  << T >>  << A >>
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

Antti



Article: 129795
Subject: Re: Spartan-3E + SPI EEPROM
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 5 Mar 2008 13:33:27 -0800 (PST)
Links: << >>  << T >>  << A >>
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)

Antti

Article: 129796
Subject: Re: Removal of a feature, moving SCD to production
From: austin <austin@xilinx.com>
Date: Wed, 05 Mar 2008 13:47:00 -0800
Links: << >>  << T >>  << A >>
Allen,

If your purchasing guy has any problems, have him email me with the SCD
number.

Austin

Article: 129797
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: sky465nm@trline5.org
Date: Wed, 5 Mar 2008 22:47:31 +0100 (CET)
Links: << >>  << T >>  << A >>
>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
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: austin <austin@xilinx.com>
Date: Wed, 05 Mar 2008 13:54:16 -0800
Links: << >>  << T >>  << A >>
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).

Austin

Article: 129799
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: austin <austin@xilinx.com>
Date: Wed, 05 Mar 2008 13:57:34 -0800
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search