Virtex 4 released today

OOPS!

http://www.xilinx.com/products/virtex4/capabilities/designsec.htm

We have AES 256 bit key in THIS generation! (---twice the key length of 
our nearest competitor with similar features)

Oh, and to be compliant with the federal standard for encryption, you 
are not allowed to use non-volatile key storage (must allow 
'zeroization').  Non volatile key storage is trivial to reverse 
engineer.  I asked our F/A lab how long it would take to read the value 
of EM polyfuses (invented by IBM), and they repplied "less than a hour."

Now, if you had poly fuses AND volatile battery backed RAM, that would 
be the best possible implementation.  Those that have secrets worth less 
than $10,000 would use the poly fuses (how much it costs to decap the 
device, and read the fuses), and those with secrets worth more than 
$10,000 would use the $1 lithium coin cell BBRAM solution.

To remember all of the new neat features is tough.

http://www.xilinx.com/products/virtex4/capabilities.htm
(but here is a 'cheat' sheet with links)

Austin

Austin Lesea wrote:
> IgI,
> 
> See below,
> 
> Austin
> 
> IgI wrote:
> 
>>>> Yup. Not his time. Aside, do we have enough BRAM?
>>
>>
>>
>> I always make use of all BRAMs available in a device, but because 
>> there is a
>> new primitive IDELAY available in V4 the need for synchronization 
>> FIFOs will
>> be reduced. This new feature will be very useful. I do have several
>> questions regarding the usage of ILOGIC primitive. What is the tab
>> resolution delay? I remember a number of 80ps from the presentation, 
>> but I'm
>> not sure I heard correctly?
> 
> 
> Yes, you did.  78 ps.
> 
>  I believe this delay depends on the speed-grade
> 
>> of the device, right?
> 
> 
> Nope.  It is derived from a feedback loop from the reference clock, so 
> it never changes.
> 
>>
>> In order to use variable IDELAY, IDELAYCTRL has to be instantiated. 
>> Lets say
>> I would like to use IDELAY for two groups of data signals, one running at
>> 166MHz and the other at 200MHz. Do I have to instantiate two IDELAYCTRL
>> primitives and connect REFCLK of each IDELAYCTRL to the same reference 
>> clock
>> or do I have to connect 166MHz clock to one IDELAYCTRL and 200MHz 
>> clock to
>> other IDELAYCTRL.
> 
> 
> The reference clock is always 200 MHz for the delay elements, and has 
> nothing at all to do with the speed the interface needs to run at.  One 
> ref clock for the delay is all it takes for the whole part.
> 
>  Is there any correlation between the REFCLK and clocks of
> 
>> the incoming data signals at all, or is REFCLK completely unrelated to 
>> any
>> other clock?
> 
> 
> Completely unrelated, unless by chance you need a 200 MHz clock to do 
> something else.
> 
>>
>> I saw there is a "Fourth-Generation Design Security" build into V4. Is
>> external battery still needed, or have you implemented some sort of
>> non-volatile memory (EEPROM) inside V4 for the keys?
> 
> 
> Triple 56 bit key DES, battery bcked key RAM, just like V2 and V2P.  It 
> is the fourth generation/technology part to have this core.  Even though 
> single and double key DES is no longer considered secure (by the federal 
> gov't), triple DES with three differing keys is still considered safe 
> for the time being.  Next generation will require AES (in two years).
> 
>>
>> What's the size of bitstream file compared to the previous generation of
>> devices?
> 
> 
> Uh, depends on the device.  Generally speaking, an LX25 is ~ 2500 system 
> gates (whatever that means) and is 7,819,520 bits long.  A 2VP20 (~2000 
> system gates) is 8,214,560.  V4 has fewer BRAM bits than Virtex II Pro 
> in ratio to CLBs, and the LX family has no PPC or MGTs.
> 
> Or, to put it another way, we haven't done anything radical to save 
> config bits in V4.
> 
>>
>> Regards,
>> Igor Bizjak
>>
>>

In article <cid123$821@cliff.xsj.xilinx.com>,
Austin Lesea  <austin@xilinx.com> wrote:
>OOPS!
>
>http://www.xilinx.com/products/virtex4/capabilities/designsec.htm
>
>We have AES 256 bit key in THIS generation! (---twice the key length of 
>our nearest competitor with similar features)

>Oh, and to be compliant with the federal standard for encryption, you 
>are not allowed to use non-volatile key storage (must allow 
>'zeroization').  Non volatile key storage is trivial to reverse 
>engineer.  I asked our F/A lab how long it would take to read the value 
>of EM polyfuses (invented by IBM), and they repplied "less than a hour."

Also, if you DO want a lot of non-volatile memory which is protected,
you can bootstrap....

Have the configuration contain compiled-in random key (store_key).
The configuration is also encrypted, with a different random key
(config_key).

Upon loading, the bitfile decryptor has config_key stored in the
battery backed SRAM cells.  It decrypts the bitfile and loads the
configuration.

Now the configuration can use store_key to decrypt data in the large
flash chip which is used for the non-volatile store.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

On Thu, 16 Sep 2004 14:37:07 -0700, Austin Lesea <austin@xilinx.com>
wrote:

>OOPS!
>
>http://www.xilinx.com/products/virtex4/capabilities/designsec.htm
>
>We have AES 256 bit key in THIS generation! (---twice the key length of 
>our nearest competitor with similar features)
>
>Oh, and to be compliant with the federal standard for encryption, you 
>are not allowed to use non-volatile key storage (must allow 
>'zeroization').  Non volatile key storage is trivial to reverse 
>engineer.  I asked our F/A lab how long it would take to read the value 
>of EM polyfuses (invented by IBM), and they repplied "less than a hour."

Note that FIPS compliant 'zeroization' requires actively setting all
the bits in the key to zero.  
Turning the power off and hoping that the bits change isn't the same
as zeroization.

This implies the following:

1. Either Xilinx isn't performing zeroization (and I haven't found
anything in the data sheet that indicates that they do perform FIPS
compliant zeroization).  Hmmm.

2. Or, Xilinx have added a low voltage detector and a have developed a
ram with a 'clear' input, or have developed a ram cell that always
goes to a known state as the supply drops.

3. Or, zeroization is possible, but can only happen when the user
overwrites the key with zeros, which is only possible when the power
is on (and wouldn't be too hard to circumvent in a real product).


Please note: I'm commenting on Austin's use of the (well defined) term
'zeroization'.  I don't mean to imply that I think that there is
anything wrong with the security of the Xilinx parts.

Regards,
Allan

Allan,

Well, you don't expect us to tell all of our secrets, do you?

Seriously, there is no security in obscurity (I am quoting someone here, 
but I do not know who, so I apologize).

I will find out what mechanism we use to clear the bits for you.  We do 
comply with FIPS on zeroisation (at least from my tests in the lab).

One common trick we used ages ago was to make the memory bits highly 
asymmetric (2K, 3K, 4K series).  This way upon power loss, they have no 
choice but to return to a known state when power is restored.  That 
would make all of those assumptions about freezing cells, and repowering 
  pretty useless (or detecting gate charge, etc.).  The re-powering of 
the cell has no choice but to return to the known state because it was 
designed that way on purpose (and we had 14 years of experience doing 
that, so we got pretty good at it, too).  This asymmetric cell power on 
is what we used to prevent power on current surges.  Unfortunately with 
ultra-deep sub-micron and 20 million or more config bits, we could no 
longer count on 100% of the cells to power on to a 0 under all possible 
power supply ramp rates, process corners, voltages, and temperatures on 
all parts.  So we abandoned that method for config.

We are preparing a USB card to demonstrate security concepts.  One 
possible challenge we may issue is to ask people to hack it and tell us: 
  what is the unencrypted bitstream? what is the key? how can you make 
the application do what you want it to (the app is a true random number 
generator -- make it do something non-random)?  I would love to have 
determined hackers attack our device, and let us know just how secure it 
really is.  That way, any weakness can be corrected in the next generation.

Email me directly if you are interested.  It will probably be sometime 
in early 2005 that we will go out with this on a large scale (if there 
is sufficient interest).  But in the meantime, we will trial it with a 
few serious and determined engineers.

It is one thing to talk about it, it is another altogether to actually 
try to crack it.

We will provide a full set of schematics and a description of what it 
does, and how it is intended to be used.  No obscurity, just security.

Austin

Allan Herriman wrote:

> On Thu, 16 Sep 2004 14:37:07 -0700, Austin Lesea <austin@xilinx.com>
> wrote:
> 
> 
>>OOPS!
>>
>>http://www.xilinx.com/products/virtex4/capabilities/designsec.htm
>>
>>We have AES 256 bit key in THIS generation! (---twice the key length of 
>>our nearest competitor with similar features)
>>
>>Oh, and to be compliant with the federal standard for encryption, you 
>>are not allowed to use non-volatile key storage (must allow 
>>'zeroization').  Non volatile key storage is trivial to reverse 
>>engineer.  I asked our F/A lab how long it would take to read the value 
>>of EM polyfuses (invented by IBM), and they repplied "less than a hour."
> 
> 
> Note that FIPS compliant 'zeroization' requires actively setting all
> the bits in the key to zero.  
> Turning the power off and hoping that the bits change isn't the same
> as zeroization.
> 
> This implies the following:
> 
> 1. Either Xilinx isn't performing zeroization (and I haven't found
> anything in the data sheet that indicates that they do perform FIPS
> compliant zeroization).  Hmmm.
> 
> 2. Or, Xilinx have added a low voltage detector and a have developed a
> ram with a 'clear' input, or have developed a ram cell that always
> goes to a known state as the supply drops.
> 
> 3. Or, zeroization is possible, but can only happen when the user
> overwrites the key with zeros, which is only possible when the power
> is on (and wouldn't be too hard to circumvent in a real product).
> 
> 
> Please note: I'm commenting on Austin's use of the (well defined) term
> 'zeroization'.  I don't mean to imply that I think that there is
> anything wrong with the security of the Xilinx parts.
> 
> Regards,
> Allan

"IgI" <igorsath@hotmail.com> wrote in message
news:31J1d.2798$F6.632356@news.siol.net...
> Hi!
>
> A Xilinx representative came today to the company where I work and he had
a
> short but very informative Virtex4 presentation. What I find very useful
is
> that Xilinx finally put a FIFO control logic on BRAMs and significantly
> increase their performance. Feature to cascade FIFOs will also be very
> useful for me. I was also hoping to see a 256 deep and 64bit wide BRAMs,
but
> I guess we'll have to wait for that feature for a while?

[snip]

I was just contemplating adding a wide/shallow memory to my design and
realized I *could* implement a 256 deep, 64bit wide memory in the BlockRAM.
The only trouble is it's single-port.

Hello,

I wrote, in regards to PCI Express implementations
not using the distributed reference clock:

> You can also use a local 125 MHz oscillator that is +/- 100 ppm.

This is false.  You cannot do this.  Such a design
would result in clocks off by up to 400 ppm.  The
Virtex-II Pro transceivers are not guaranteed to
lock over that range.  In a PCI Express system,
you will need to do a 1.25 multply and clean up
the reference clock with a PLL.

I apologize for providing incorrect information.
Eric

"John_H" <johnhandwork@mail.com> wrote in message
news:xQJ2d.26$l1.2903@news-west.eli.net...
> "IgI" <igorsath@hotmail.com> wrote in message
> news:31J1d.2798$F6.632356@news.siol.net...
> > Hi!
> >
> > A Xilinx representative came today to the company where I work and he
had
> a
> > short but very informative Virtex4 presentation. What I find very useful
> is
> > that Xilinx finally put a FIFO control logic on BRAMs and significantly
> > increase their performance. Feature to cascade FIFOs will also be very
> > useful for me. I was also hoping to see a 256 deep and 64bit wide BRAMs,
> but
> > I guess we'll have to wait for that feature for a while?
>
> [snip]
>
> I was just contemplating adding a wide/shallow memory to my design and
> realized I *could* implement a 256 deep, 64bit wide memory in the
BlockRAM.
> The only trouble is it's single-port.
>

Correct!  You can do this now in Virtex-II, Virtex-II Pro/X, and Spartan-3.
In fact, you can even build a 256x72 (x64 with parity).  Figure 22 on page
27 of the following link shows how.
http://www.xilinx.com/bvdocs/appnotes/xapp463.pdf

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC

This is a multi-part message in MIME format.
--------------7629624E3B58F7747131F99C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jim/All,
           So after discussing it with Austin and Peter, we believe that
it might indeed be possible to generate 32 different phases of clock
in V4. You will need to use 8 DCM's 4 in the top half of the chip and
4 in the bottom half of the chip. Each DCM can generate 4 phases
0,90,180,360 and can be offset by a delay of 1/32 of the clock
from the other DCM's. Routing the same input clock to all 8 DCM's
may require using two different IO pins one for each half of the
chip. The use of two IOB pins may create some systemic skew
between 16 phases and the other 16 phases - but the IOB Idelay
should help minimize that.

I am not an expert on a lot of this (IOB/DCM) but I think it is
feasible. Jim, perhaps you could try implementing it in V4 - and
if you run into any problems - I am sure Austin/Peter could
help you. At the very least generating 16 phases should be a cinch.

            - Vic


Jim Granville wrote:

>
>
>   So, supposing someone wants to create a 'phased array' of clocks,
> to push their time-resolution well below the 1/clock, ( as in other
> threads ) what is the practical limit in Virtex-4, for the number of DCM
> controled phases that can be generated, AND dispersed thru the chip ?
> ( IIRC earlier DCM's had just 4 phases ).
>   Can each of the 32 global clock buffers be driven to +1/32 phase
> advance, for example ?
>
> -jg

--------------7629624E3B58F7747131F99C
Content-Type: text/x-vcard; charset=us-ascii;
 name="vic.vadi.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vic Vadi
Content-Disposition: attachment;
 filename="vic.vadi.vcf"

begin:vcard 
n:Vadi;Vic
tel;fax:408-626-6499
tel;work:x6303 (408-626-6303)
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:vicv@xilinx.com
fn:Vic Vadi
end:vcard

--------------7629624E3B58F7747131F99C--

General,

There are also I/O clocks in V4 I don't believe anyone has mentioned, which
are specifically for source synchronous transfer, and come in on one of the
I/O pins for that bank.  IIRC, there are 8 I/Os plus clock per bank and the
I/O clock can source CLBs in the adjacent banks or up to 24 I/O.  That should
provided plenty of clock resources for any combination of inputs with separate
clocks.  The I/O logic also has dynamically programmable delay with 64 ps
granularity, so you can adjust the delays on each pin either statically or
dynamically (with a state machine in your logic).

General Schvantzkoph wrote:

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

I thought V4 is AES?

Austin Lesea wrote:

> Triple 56 bit key DES, battery bcked key RAM, just like V2 and V2P.  It
> is the fourth generation/technology part to have this core.  Even though
> single and double key DES is no longer considered secure (by the federal
> gov't), triple DES with three differing keys is still considered safe
> for the time being.  Next generation will require AES (in two years).
> >
> > Regards,
> > Igor Bizjak
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759