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 104275

Article: 104275
Subject: Re: xc3sprog -- any updates?
From: "Sandro" <sdroamt@netscape.net>
Date: 22 Jun 2006 07:51:32 -0700
Links: << >>  << T >>  << A >>
Eric wrote:
>
> They created it this afternoon; it should be up! I'm going to import
> the original code into svn right now...
>      ...Eric

Eric,
The version you uploaded is the latest ?!?

I got it from :
   http://www.rogerstech.force9.co.uk/
   http://www.rogerstech.force9.co.uk/xc3sprog/index.html
(seems to be the webpage of the author...)

Sandro


Article: 104276
Subject: Re: Locks for the peasants :-)
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 22 Jun 2006 08:00:01 -0700
Links: << >>  << T >>  << A >>
backhus,

No reward but the satisfaction that you were able to outsmart a room
full of very smart people.  Such an accomplishment would definitely
qualify the person for a job offer here at Xilinx.

The part was the 2VP4.

Austin

backhus wrote:
> Hi Austin,
> that sounds reasonable. Security proofs are expensive.
> 
> For the V2 boards you gave away ... what reward did you offer in case of
> success? I suspect there are people out there who would pay good for
> that knowledge as long as you don't have it, so why should they tell
> you? ;-)
> 
> Best regards
>   Eilert
> 
> Austin Lesea schrieb:
>> backhus,
>>
>> That is something that we thought about.  But, really what we talking
>> about is providing access to the crypto-engine through the general
>> interconnect, and control of that engine.
>>
>> It was considered that anything we do in this regard would have to be
>> completely and thoroughly tested so as not to be a back door, and
>> compromise security.
>>
>> It wasn't worth the work to have to prove we did not break something.

Article: 104277
Subject: Re: keys to the Kingdom
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 22 Jun 2006 08:08:24 -0700
Links: << >>  << T >>  << A >>
Thomas,

Yes, it is that cheap (and easy) to find and read efuses.  If they had
used Actel's via fuse technology, it would be much, much harder, but
still do-able for a small number of vias.  Of course, you would have to
know where to look.  The poly efuse is huge, and is almost big enough to
see with the eye.  An array of 128, or 256 has a big sign on it:  "efuse
array right here!"

If you use the battery backed ram to store the key, the bitstream is
protected, not the device.  Any regular unencrypted bitstream can be
loaded (or else how could you test your boards?).

The use of efuses to make it such that only a particular device is able
to load a particular bitsream is a requirement typical of the gaming
industry (slot machines).  This is a feature that we are looking at
introducing in the future (if it does not compromise the higher level of
security).

As I said, I love efuses.  They can be used for:  serial numbers, lot
and process information, feature selection and control, device
identification, etc.  You can even put a key in it, but make sure that
the key in a non-volatile memory is clearly stated as not being NIST
FIPS 140-2 compliant.  There are customers for whom a low level of
security is just fine.

But for an IP company, placing my IP in such a low security device
invites every crypto student looking for a job, or a degree, to hack it.

Austin


Thomas Stanka wrote:
> Hi,
> 
> Austin Lesea schrieb:
> 
>> Just don't go advertising them to be more than they really are:  a
>> convenient way to make it cost at least $5,000 to find the key.
> 
> Is it that cheap today to open the die and observe the fuses?
> I have no idea, if (and how) Altera protected the key fuses against
> optical inspection of die  cuts. But If your right, it would be very
> cheap to reengineer most Asics.
> 
> BTW Am I right, that if I use a Xilinx with security inside a
> equipment, the chip could be highjacked (Chipmodded) by just removing
> the power supply of the keys and applieing a new bitstream?
> Which means the bitstream itself may be protected, but not the chip?
> Why did nobody combine software and fuse based technologies? It would
> be sufficient to have 128 bit (with secure algorithms) in SW and 128 in
> fuses. 
> 
> bye Thomas
> 

Article: 104278
Subject: Re: keys to the Kingdom
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 22 Jun 2006 11:17:03 -0500
Links: << >>  << T >>  << A >>
>Yes, it is that cheap (and easy) to find and read efuses.  If they had
>used Actel's via fuse technology, it would be much, much harder, but
>still do-able for a small number of vias.  Of course, you would have to
>know where to look.  The poly efuse is huge, and is almost big enough to
>see with the eye.  An array of 128, or 256 has a big sign on it:  "efuse
>array right here!"

Whenever I get involved with a discussion like this, I point people
at these papers:
  http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
  http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf

That's from 1999.  Still a great read.

The details have changed, but I doubt if the general idea is out of
date.  People who build chips have to debug them.  They will keep the
technology up to date.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 104279
Subject: Re: Newbie in Chipscope-changes need to route bidirectional data port
From: "Symon" <symon_brewer@hotmail.com>
Date: 22 Jun 2006 18:30:13 +0200
Links: << >>  << T >>  << A >>
"subint" <subin.82@gmail.com> wrote in message 
news:1150971643.167338.124530@r2g2000cwb.googlegroups.com...
> Hi,
> I am using the chipshop first time.

Hi Subin,
I recommend the battered cod. :-)

> I am using this one to debug my ddr
> controller in the v4 board. When i tried to route the data bus of ddr
> through the chipscope it generated ILA and inserted into my design but
> when i try to implement(map and par) xilinx ise showing error that the
> bidirectional port is being driven by some buffer by the chipscope
> module.the ddr bus are  bidirectional so what changes needed in the
> chipscope setting to route my bidirectional port.
> regard
> subin
>
I think your problem could be that you're trying to probe the pads of the 
IOBs. There's no way for ChipScope to connect to this without going through 
an input buffer. Try probing the signal that comes off the input 
buffer(IOB.I) of the IOB. If that's not it, perhaps you could post the error 
message you're getting?
HTH, Syms. 



Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

Article: 104280
Subject: Re: keys to the Kingdom
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 22 Jun 2006 10:05:41 -0700
Links: << >>  << T >>  << A >>
Hal,

Those slides show a efuse that is really blown.  The new technology does
not vaporize the poly, it EM moves the ions all to one end, changing the
poly's behavior under polarized light.  But, the method still applies:
you can visually read the values.

Thanks for the posting.

Austin

Hal Murray wrote:
>> Yes, it is that cheap (and easy) to find and read efuses.  If they had
>> used Actel's via fuse technology, it would be much, much harder, but
>> still do-able for a small number of vias.  Of course, you would have to
>> know where to look.  The poly efuse is huge, and is almost big enough to
>> see with the eye.  An array of 128, or 256 has a big sign on it:  "efuse
>> array right here!"
> 
> Whenever I get involved with a discussion like this, I point people
> at these papers:
>   http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
>   http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf
> 
> That's from 1999.  Still a great read.
> 
> The details have changed, but I doubt if the general idea is out of
> date.  People who build chips have to debug them.  They will keep the
> technology up to date.
> 

Article: 104281
Subject: Re: Xilinx ISE S/W Install kernel version "mismatch"
From: Rich Grise <richgrise@example.net>
Date: Thu, 22 Jun 2006 17:25:27 GMT
Links: << >>  << T >>  << A >>
On Wed, 21 Jun 2006 23:17:30 +0000, Duane Clark wrote:
> Rich Grise wrote:
>> On Tue, 20 Jun 2006 06:14:25 +0000, Adam Goldman wrote:
>> 
>>> In article <pan.2006.06.11.03.15.36.415791@example.net>, Rich Grise wrote:
>>>> OK, I decided to take a chance and download that 839MB shell script that's
>>>> written for RedHat Enterprise, and was doing OK, (I had to shell out as
>>>> root a couple of times to give the install script permission to write to a
>>>> new directory, but that felt kind of kewl. :-) ), and now I'm at kind of a
>>>> stopper. The graphic install has the progress bar at 99%, and there's a
>>>> /lib/modules/misc/windrvr6.o: kernel-module version mismatch
>>>>        /lib/modules/misc/windrvr6.o was compiled for kernel version
>>>>        2.4.18-14 while this kernel is version 2.4.31.
>>> Not specifically for your distribution but here's something on recompiling
>>> xpc4drvr and windrvr6 for a different kernel:
>>>
>>> http://gentoo-wiki.com/HOWTO_Xilinx
>>>
>>> It looks to me as if unless you're using their programmer hardware you
>>> don't need to bother. Synthesis and schematic capture ought to work without
>>> this driver.
>>>
>>> Coincidentally, Xilinx mailed out my copy of ISE today, so I'll know
>>> soon enough ;-)
>> 
>> Thanks, but that link only talks about kernel 2.6, but Slackware ships
>> with 2.4, and 2.6 is an option, that I've been afraid to try. ("Compile
>> a new kernel????? Are you nuts?"
> 
> Do you want to use the Xilinx programming tools (impact)? If not, you 
> don't need those two drivers, as Adam said.
> 
> If you do want to use those tools, then Xilinx requires that you 
> recompile the drivers against your kernel, if you are using a kernel 
> different from the one the compiled against. Kind of annoying, and 
> hopefully one of these days Xilinx will do it right.
> 
> If you have not recompiled your own kernel, then you probably just need 
> to install the kernel sources corresponding to the kernel you have, and 
> compile the drivers. I don't use Slackware, so I don't know how it is 
> done there. I see that this is crossposted to alt.os.linux.slackware, so 
> someone there could probably help with that.

I have no problem with compiling from source, on my current kernel, but
does Xilinx let us D/L source?

Thanks,
Rich



Article: 104282
Subject: Re: xst can, but vcomp can't
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Thu, 22 Jun 2006 20:19:07 +0200
Links: << >>  << T >>  << A >>
Morten Leikvoll wrote:


> Looks like an idea.. Can I call a procedure from another procedure? In that 
> case I can try write a new procedure to extract the bit and pass it (as 
> inout?) to a clock detecting procedure using a clean bit. Hmm.. not sure if 
> that will work tho.. Gotta try it.

Sounds like something that is worth to try. I can't tell you if it will 
be accepted.


> I am not really trying to use dual edge here. I only want to program my 
> cpu_register to be able to detect a rising of falling edge from my system 
> depending on a constant input parameter (here, the input variable 'neg').

But what you have written is a something like dual-edge flipflop. If you 
want to detect edges of a signal, use 2 flipflops in a chain. The first 
samples the input data, the 2nd samples the output of the first. Now you 
can compare the output values of both flipflops. If the 1st has '0' as 
output and the 2nd '1' you got a falling_edge and the same holds for the 
rising_edge. The disadvantage: You have a delay depending on your 
sampling frequency.


Ralf

Article: 104283
Subject: RS232 to access TX registers of Aurora
From: "Vivek Menon" <vivek.menon79@gmail.com>
Date: 22 Jun 2006 11:37:55 -0700
Links: << >>  << T >>  << A >>
Hi,
I have implemented the Aurora protocol on the V2PRO FF672 FPGA. As part
of testing, I need  to access the TX data on the aurora links through
RS232 interface as well.
Now the problem I have is that the avbl project in XPS has a rx and tx
port (std_logic) and the data I need to send is atleast 16 bits. How do
I access or interface the register outputs from Aurora to RS232??
Thanks,
Vivek


Article: 104284
Subject: Re: newbie:my ISE doesn't include old xcs30 spartan how........
From: ghelbig@lycos.com
Date: 22 Jun 2006 12:54:20 -0700
Links: << >>  << T >>  << A >>
It's worse than Aurelian says.

The newest version that supports these parts is 4.2i, but you must use
schematic entry.  Xilinx is no longer allowed to provide a synthesys
license for these parts, and XST has never supported them.

Have a nice day.


blisca wrote:
> how can i do to make it work with this old devices?experimenting with an old
> board i need to add xcs30 and i need a tool(older impact versions) for
> programming it,i guess that treatin it as an xc2s30 is not the right way to
> proceed
> Thanks to everyone
> Diego


Article: 104285
Subject: Re: RS232 to access TX registers of Aurora
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 22 Jun 2006 14:59:57 -0500
Links: << >>  << T >>  << A >>

>Now the problem I have is that the avbl project in XPS has a rx and tx
>port (std_logic) and the data I need to send is atleast 16 bits. How do
>I access or interface the register outputs from Aurora to RS232??

It's fairly easy to make a hack RS-232 transmitter.  It's just
a shift register preloaded with the data and start/stop bits.
For 16 bits of data, I'd use a 20 bit shift register - 2 8-bit
bytes with start and stop bits on each.

You can probably sort out all the LSB/MSB first and inversions
by reading the specs carefully enough.  It's probably simpler to
put a scope on the cable to your PC and make it send a known pattern.

You (probably) don't need fancy RS-232 level shifters.  Most RS-232
receivers will do the right thing if you feed them a 3V CMOS signal.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 104286
Subject: Spartan 3E Starter Kit - diff b/t rev. C and D?
From: Christopher Cole <cole@scoob.coledd.com>
Date: Thu, 22 Jun 2006 20:15:02 GMT
Links: << >>  << T >>  << A >>
Can anyone tell me what Xilinx changed between rev C and rev D of the 
Spartan 3E Starter kit board?

By the way, why the secret on page 3 on the rev D schematic?
http://www.xilinx.com/bvdocs/ipcenter/block_diagram/S3E_Starter_D_External_sch.pdf

Thanks,
-Chris

-- 
 /> Christopher Cole                         <\                           <\
<<  Cole Design and Development               \\  email: cole@coledd.com   \\
 \\ Computer Networking & Embedded Electronics \\ web: http://coledd.com    >>
  \>                                            \>                         </

Article: 104287
Subject: Re: Spartan 3E Starter Kit - diff b/t rev. C and D?
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Thu, 22 Jun 2006 20:18:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
Christopher Cole <cole@scoob.coledd.com> wrote:
> Can anyone tell me what Xilinx changed between rev C and rev D of the 
> Spartan 3E Starter kit board?

> By the way, why the secret on page 3 on the rev D schematic?
> http://www.xilinx.com/bvdocs/ipcenter/block_diagram/\
> S3E_Starter_D_External_sch.pdf

It is probably the USB programming, using the Cypress FX2. Some 
reverse engineering has already been done. Look at old news.
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 104288
Subject: Aurora 4 byte interface
From: "bajaj" <bkapil82@gmail.com>
Date: 22 Jun 2006 13:30:39 -0700
Links: << >>  << T >>  << A >>
Hi to all
I am new to group. i am working on aurora protocol. i am stuck as want
to use aurora protocol fo r 4 byte interface. Although i can generate
core for the same using core generator but the reaing interface signals
have to generated. How do i do that. If any body has already done
thatpls reply soon.


Article: 104289
Subject: Xilinx RocketIO receiver reset problem
From: "johnp" <johnp3+nospam@probo.com>
Date: 22 Jun 2006 13:47:25 -0700
Links: << >>  << T >>  << A >>
I'm connecting a V2Pro Rocket IO to a Agilent optical interface and
am having problems getting the RocketIO receiver to reset properly
and generate the correct data.  The design originally used a Vitesse
serial<->parallel interface chip and that worked fine.  Since we have
a spare RocketIO, we'd like to use it instead of the Vitesse chip.

I'm running the link at 1062.5 Gbit/sec, so the reference clock for
the RocketIO is 53.125MHz.  Because of the optical protocol I'm
talking to, I can't use clock correction, so I'm using the RXRECCLK
to clock data+K_codes out of the RocketIO.

Since RXRECCLK runs at the bit_rate/20, I'm using a 2 byte wide
receiver interface.

The problem I'm seeing is the receiver does not appear to reset
and lock to the data source properly.  My reset state machine looks
for bad K codes and some other problems, and if needed, it generates
a long reset signal to the ROcketIO receiver, then waits a while for
it to come back to life.

Unfortunately, the RocketIO does not appear to reset correctly.  I'll
see bad K codes and other garbage.  If I disconnect the optical link,
then reconnect it, I'll sometimes be able to get reasonable info out
of the RocketIO.

To generate the 53.125MHz reference clock, I'm dividing a high quality
106.25MHz reference clock in the FPGA to drive the RocketIO.

Anyone have any hints?

Thanks!

John Providenza


Article: 104290
Subject: Re: Xilinx RocketIO receiver reset problem
From: "johnp" <johnp3+nospam@probo.com>
Date: 22 Jun 2006 14:05:20 -0700
Links: << >>  << T >>  << A >>
Of course, 5 minutes after I posted the message I found the answer.

I was never asserting the ENPCOMMAALIGN signal to the RocketIO,
so it never really appeared to sync to the incoming data stream.

It now looks OK.

John P


johnp wrote:
> I'm connecting a V2Pro Rocket IO to a Agilent optical interface and
> am having problems getting the RocketIO receiver to reset properly
> and generate the correct data.  The design originally used a Vitesse
> serial<->parallel interface chip and that worked fine.  Since we have
> a spare RocketIO, we'd like to use it instead of the Vitesse chip.
>
> I'm running the link at 1062.5 Gbit/sec, so the reference clock for
> the RocketIO is 53.125MHz.  Because of the optical protocol I'm
> talking to, I can't use clock correction, so I'm using the RXRECCLK
> to clock data+K_codes out of the RocketIO.
>
> Since RXRECCLK runs at the bit_rate/20, I'm using a 2 byte wide
> receiver interface.
>
> The problem I'm seeing is the receiver does not appear to reset
> and lock to the data source properly.  My reset state machine looks
> for bad K codes and some other problems, and if needed, it generates
> a long reset signal to the ROcketIO receiver, then waits a while for
> it to come back to life.
>
> Unfortunately, the RocketIO does not appear to reset correctly.  I'll
> see bad K codes and other garbage.  If I disconnect the optical link,
> then reconnect it, I'll sometimes be able to get reasonable info out
> of the RocketIO.
>
> To generate the 53.125MHz reference clock, I'm dividing a high quality
> 106.25MHz reference clock in the FPGA to drive the RocketIO.
> 
> Anyone have any hints?
> 
> Thanks!
> 
> John Providenza


Article: 104291
Subject: Re: Linking/mapping code sections with Xilinx EDK
From: sgfallows@gmail.com
Date: 22 Jun 2006 14:24:50 -0700
Links: << >>  << T >>  << A >>
Joseph wrote:
> Steve,
>
> That .s/.S proprocessor thing is a feature (.S signals gcc to use the
> preprocessor, .s tells it not to use the CPP).
Yes, I know it's a feature, I just think it's bizarre to key on such a
small difference, especially when Windows doesn't *really* support case
in filenames. Anyway...

> I'd wonder how you are actually compiling and linking.  How are you
> calling the tools?  Do you have a makefile?
I'm using the XPS tools from the GUI. Whatever canned/internal
makefiles it uses. There are no makefiles in my project directory

> Maybe the .S isn't getting
> into the action with your makefile?
No, I did see the different behavior with .s/.S -- it just didn't
affect whether the code in the vectors section was output into the .elf
file.

Anyway, thanks for the comments...
Steve


Article: 104292
Subject: Re: keys to the Kingdom
From: "Dave Greenfield" <davidg@altera.com>
Date: 22 Jun 2006 14:24:50 -0700
Links: << >>  << T >>  << A >>
Could be there is a place for both volatile and non-volatile security.
Majority of customers we (Altera) have spoken to prefer the
non-volatile key and are extremely satisfied with the security. This
includes multiple military customers.

Non-volatile security provides significantly more flexibility on the
manufacturing process and enables some new royalty-based business
models that cannot be facilitated with battery back-up security.

If you are interested in further detials, here's a link to an upcoming
net seminar.
http://www.altera.com/education/net_seminars/all/ns-st2-design-security.html

Dave Greenfield
Altera Product Marketing


Article: 104293
Subject: Re: keys to the Kingdom
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 23 Jun 2006 09:47:10 +1200
Links: << >>  << T >>  << A >>
Dave Greenfield wrote:
> Could be there is a place for both volatile and non-volatile security.

Of course, yes.

To quote Austin :

"The use of efuses to make it such that only a particular device is able
to load a particular bitsream is a requirement typical of the gaming
industry (slot machines).  This is a feature that we are looking at
introducing in the future (if it does not compromise the higher level of
security)."

So, seems Xilinx will also be doing this, sometime...

In Security, the more hurdles, the better.

It is, of course, only as strong as the weakest link.

-jg


Article: 104294
Subject: Re: keys to the Kingdom
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 22 Jun 2006 15:05:46 -0700
Links: << >>  << T >>  << A >>
Dave,

Of course there is room for non-volatile keys!

I am happy that you did your research and discovered what you think your
customers want, but I question the results:  was the question "do you
want an easy to use and effective* security system that doesn't need a
battery?"

If so, then the answer is always "yes.  I do!"

But, if you had said: "Non-volatile keys are not NIST approved for use
in any federal system, and not generally used in any private security
application.  Knowing this, would you choose to use a non-volatile key
to protect your assets? or would you use a battery backed key"

If so, then I suspect the answer would be "no.....you should have told
me this."

To have a press release that touts a "superior security solution" is the
worst of the worst marketing.  To claim to be able to protect IP from
ASSP vendors is quite honestly, false and misleading.  If I can get the
IP that is a secret for less than $5,000, then I can clone the devices
without paying anything at all.

To imply that you have military customers satisfied with this level of
security is amazing.  Perhaps they have a thermite charge to destroy the
device if it is tampered with.  That does work, and makes getting parts
back for RMA a non-problem, but is not a preferred solution!  Or perhaps
these devices are used for smart bombs and smart bullets.  Hard to read
it out when they are blowing up all around you.

If what you are protecting is less than $5,00 in value, then it is
great, and works just fine.

By the way, when will you publish how the keys are programmed into the
device?  Seems there is an NDA in place, and you are keeping a secret.

What are you hiding?

Austin

What is missing from all those press releases:

*Disclaimer:  non-volatile poly-efuse EM technology can be read out by a
microscope using polarized light for a total investment of less than $5,000




Dave Greenfield wrote:
> Could be there is a place for both volatile and non-volatile security.
> Majority of customers we (Altera) have spoken to prefer the
> non-volatile key and are extremely satisfied with the security. This
> includes multiple military customers.
> 
> Non-volatile security provides significantly more flexibility on the
> manufacturing process and enables some new royalty-based business
> models that cannot be facilitated with battery back-up security.
> 
> If you are interested in further detials, here's a link to an upcoming
> net seminar.
> http://www.altera.com/education/net_seminars/all/ns-st2-design-security.html
> 
> Dave Greenfield
> Altera Product Marketing
> 

Article: 104295
Subject: Re: keys to the Kingdom
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 23 Jun 2006 11:17:37 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> What is missing from all those press releases:
> 
> *Disclaimer:  non-volatile poly-efuse EM technology can be read out by a
> microscope using polarized light for a total investment of less than $5,000

.. and that may not quite be the open door you paint.

Have _you_actually_cloned_ a/any device for $5000, or is this more
generic "Austin Arm waving" ? :)

[Until Xilinx have non volatile fuses, then the spin will change ? ]

  Being able to read the physical fuses is some way from being able to 
duplicate them, or reverse the key those fuses create.
It is not likely that Altera simply mapped Fuse1 = Encryption bit1, etc.

  So, to descramble that, will need a LOT of devices, and much more time....

  With fully volatile security, yes, the code within is secure,
but the system is _very_ open to spoofing type attacks, so again 
security can be a mirage....

  -jg


Article: 104296
Subject: stimulus for FPGA
From: "anand" <writeanand@gmail.com>
Date: 22 Jun 2006 16:30:05 -0700
Links: << >>  << T >>  << A >>
I am planning on buying either a Xilinx Spartan or Altera Development
Kit to test out some designs on FPGA. (I am New to FPGAs).

Question:

Once the design has been downloaded into the FPGA, how do I apply
stimulus and test the design? I believe several methods are possible,
but I would like one where both the stimulus (is applied in) and the
response (is checked) using a high level language like C or C++.
Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"?
That way I can write C or C++ code to run a real "app".


Article: 104297
Subject: Re: stimulus for FPGA
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 22 Jun 2006 17:10:21 -0700
Links: << >>  << T >>  << A >>
anand wrote:

> Once the design has been downloaded into the FPGA, how do I apply
> stimulus and test the design?

It's best to test the code before you synthesize it.
You don't even need a development board for this.
Just a text editor and a simulator.

> I believe several methods are possible,
> but I would like one where both the stimulus (is applied in) and the
> response (is checked) using a high level language like C or C++.
> Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"?

A simulation testbench that you write
in vhdl or verilog will wiggle and watch the pins
logically, not physically.

> That way I can write C or C++ code to run a real "app".

No. The C API is for simulation too,
but you won't need it to start out.

           -- Mike Treseler

Article: 104298
Subject: Re: stimulus for FPGA
From: Mark McDougall <markm@vl.com.au>
Date: Fri, 23 Jun 2006 10:16:29 +1000
Links: << >>  << T >>  << A >>
anand wrote:

> Once the design has been downloaded into the FPGA, how do I apply
> stimulus and test the design? I believe several methods are possible,
> but I would like one where both the stimulus (is applied in) and the
> response (is checked) using a high level language like C or C++.
> Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"?
> That way I can write C or C++ code to run a real "app".

An FPGA is no different in this respect to any other piece of hardware 
you may design. So there is no software "API" to interface to an FPGA 
any more than there are APIs to interface to a 74LS02 or a LED.

You may be getting confused with *simulation*, which does not involve 
programming a physical FPGA but instead simulating the behaviour of your 
FPGA code in software. Stimulus can be provided in several manners and 
with many different languages, including C/C++.

Alternatively, you need to interface your FPGA to a PC via whatever 
means is suitable to the task, from a PCIe/PCI connector down to a 
serial port. Exactly how you interface in software is very dependent on 
the hardware interface method you choose.

Another alternative I've just thought of involves using a soft-core 
processor inside the FPGA to interface with the core logic, enabling you 
to write stimulus in C. That brings a whole number of new issues, not 
the least of which is the requirement for a much larger FPGA and perhaps 
more RAM than would otherwise be required.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 104299
Subject: Re: Stratix column and row pins
From: rreuter@gmx.net
Date: 23 Jun 2006 00:17:22 -0700
Links: << >>  << T >>  << A >>
So it's quite easy! Banks 1, 2, 5, 6 are all row pins, the other banks
are column pins.

Roland.

Subroto Datta schrieb:

> One way of obtaining this information in Quartus II 6.0 is to create a
> project, assign the device that you want to use (Assignments->Device), open
> the Pin Planner (Assignments->Pin Planner) and in the All Pins View (this is
> the table in the lower half of the screen) customize the columns using the
> following steps:
>
> 1. Right click in the All Pins View->Customize Columns..., and add the
> General Function Column. The Genaral Function column will show if it is Row
> I/O or Column I/O.
> 2. Right click in the All Pins View and click on the Show Assignable Pins.
> This will show all pins on the package.
>
> You can order the columns displayed in step 1. You can then copy and paste
> this information into Excel or your favorite document format.
>
> Hope this helps,
> - Subroto Datta
> Altera Corp.
>
> <rreuter@gmx.net> wrote in message
> news:1150877340.814578.94120@g10g2000cwb.googlegroups.com...
> > An Altera application note (AN-349) recommends placing certain outputs
> > on column pins and others on row pins. My question is: which pins of
> > the Stratix device are column and which are row pins? Is there a
> > document that includes this info? I assume that the assignment is fixed
> > and given by architecture, not dynamically?
> >
> > Thanks for advices, Roland.
> >




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