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 22325

Article: 22325
Subject: Re: How to Prevent theft of FPGA design
From: David Bishop <dbishop@vhdl.org>
Date: Fri, 05 May 2000 01:19:25 GMT
Links: << >>  << T >>  << A >>

I've gotten lots of private e-mails on this one since it started last
week. So far, the PDL approach (not on the bit stream, but sitting
beside the FPGA) with some sort of LFSR looks best.  It's crackable,
but it would take some work to do it.

All in all, I'll stand on what I said before.  FPGAs are not secure,
if you have algorithms you don't want copies, don't put them in FPGAs.
This is why there are some "cheap" places you can go to get ASICs done.
Chip Express, or some sort of "hot wire" FPGA comes to mind.

What the industry needs for FPGAs to take off is some sort of DES like
encription which can be OPTIONALLY used on the bit stream.  You'll need
to make the part 1 time programmable with a key, and you will also need
to put that key in the software so that it can encode the stream.  This
can still be brute force cracked, but it would take awhile.

-- 
NAME:     David W. Bishop           INTERNET: dbishop@vhdl.org  (  \  )
US MAIL:  Hilton NY 14468-9101      A Long time ago,             \__\/
PHYSICAL: 43:17:17N 77:47:37W 281'  In a Galaxy far, far away...  | |
For Supernova info:  http://www.ggw.org/asras/snimages            | |
For VHDL/Synthesis info:  http://www.vhdl.org/siwg              _/___\_
All standard disclaimers apply.                                [_______]

Article: 22326
Subject: Re: Q: simplest FPGA structure for novel technology demonstration
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Thu, 04 May 2000 18:26:45 -0700
Links: << >>  << T >>  << A >>
On 04 May 2000 18:54:46 -0400, Paul Bunyk
<paul@pbunyk.physics.sunysb.edu> wrote:

|
|Hello, everyone!
|
|I'm developing a new (at least pretty much unheard of) supercondicting
|logic family (RSFQ) and I'd like to make a demo chip implementing some
|kind of regular programmable logic function similar to FPGAs/CPLDs. 
|
|I wonder if someone can point me to the information about the earliest
|and simplest FPGA structures which I can try to implement. At this
|point gate density is really low, I can fit something like couple K
|gates on a chip, but speed is tremendous (several tens of GHz) with
|negligible power consumption (and yes, it requires liquid He
|refrigeration! :) ).
|
|Why am I doing it? We need to demonstrate a working chip fast, all
|design is pretty much hand-built now (thus I want to make this demo as
|regular as possible) and, since there is no way to talk to room
|temperature electronics at 20 GHz speed, I want to make this
|demonstration by (slowly) programming the chip from room temperature,
|then running it for something like 1 microsecond and slowly
|reading-out the results (showing that it actually had performed like
|20000 steps in that one usec :) ). Thus I can not make just a simple
|PLA, it has to keep enough state on-chip to be busy for couple
|thousands cycles crunching on it.
|
|Another limitation is that the structure should have relatively short
|connections on the chip, preferably arranged in systolic array-like
|pattern (it takes time comparable to the 50 ps clock cycle to pass a
|signal across the chip just due to the finite speed of light in
|on-chip microstrips).
|
|And, of course, we should be able to claim that it is an
|"interesting" digital system, showing some "useful" algorithms
|implemented in that.
|
|Any suggestions? 
|
|Sincerely,
|
|Paul Bunyk
|
|P.S. A cc: of your replys to my mailbox would be very much
|appreciated!  :)

Wouldn't some simpler logic circuits prove the technology?

And, uh, when you show this to potential investors, you might consider
spelling 'superconducting' properly.

John

Article: 22327
Subject: Re: How to Prevent theft of FPGA design
From: Ray Andraka <ray@fpga-guru.com>
Date: Fri, 05 May 2000 01:34:11 GMT
Links: << >>  << T >>  << A >>


David Kessner wrote:

> "Nicholas C. Weaver" wrote:
> >         (Note, this is equivelent to the other solution except that
> > since N always increments, you don't need to send N from the FPGA to
> > CPLD).  The actual PRNG or encryption can be whatever is desired).
>
> Yes, there were several solutions mentioned that were "similar but not
> identical".  It's not rocket science, so just about everyone would
> arrive at the same solution especially if people are actually talking
> about it and working it though.  I'm actually wondering why it took
> so long to come to this solution, since we had all the pieces many
> years ago.
>
> >         The problem is the attacks outside the protocol, extracting
> > the key from the FPGA bitfile, etc, etc, etc.  I don't think this
> > would stop a not very determined copier, since he is already going
> > through considerable effort.  Attacking the bitfile with jbits and
> > working backwards would undoubtedly occur, to get the key, and this
> > would not be a significant hurdle for the attacker.
>
> Remember that Jbits only works with the Virtex.  There are other
> SRAM based FPGA's out there that are not at as easily reverse
> engineered.  Xilinx Spartan's, Altera Apex, and Cypress Delta39K
> just to name a few.

There is Jbits for 4K/spartan  too.

>
>
> One of the primary goals that I had was to use off the shelf
> technology.  A consequence of this is that it does leave the door
> wide open to reverse engineering the FPGA bitstream.  Reverse
> engineering a bitstream is a non-trivial task, about as easy as
> breaking the LFSR itself (assuming the LFSR is <40 bits).

LFSRs are really pretty easy to break.  If all you have is the output
stream, it only takes N^2 consecutive samples to determine the taps and the
initial state for an N bit LFSR.  You'll probably want a more robust
encryption.

>
>
> Until FPGA's have crypto hardware built in then this type of
> attack will always exist for all copy protection schemes.

The FPGA would also have to have a unique key in it, and herein lies the
problem.  Even if you did put flash in it with a security bit, it might be
possible to read the key back out by playing with program voltages etc or by
de-lidding and inspection.

>
>
> >         I think the only effective solution apart from
> > battery-backup/always on, or convincing the vendors to build in a
> > cryptographic module onto the silicon, is to write good contracts and
> > just make little tweaks which make the lawyers lives easier.
> >
> >         Embedding a small amount of hidden information in the
> > configuration of each serial EPROM burned gives a tracking number
> > which, unless the attacker knows about it and can scrub it out, can be
> > used to state that "I sold you device #xxxyy.  Device #xxxyy was
> > copied.  You violated my copyright, and you violated our contract.
> > You will be hearing from the firm of Dewey, Cheatam, and Howe.  Have a
> > nice day".
>
> Copy protection schemes that rely on contracts and legal hooks will
> not succeed.  Well, it might succeed if you are selling only a few
> units to well a couple of well defined customers.  But it doesn't
> work if you're selling thousands of units into the mass market where
> you have almost no control over who gets your products.
>
> The truth is that many pirates work in countries where people like
> you and I have almost no legal rights.  I once had a board of mine
> copied.  The pirate was operating out of Taiwan.  We knew who he was,
> his name, and even the street address of his store front.  We had
> lots of evidence that he was selling an illegal copy.  After many long
> discussions with the various lawyers, it was determined that we could
> spend millions of dollars in court and probably still loose.  It's
> not right, fair, or ethical, but that's the way Taiwan is.  Americans
> rarely win a lawsuit in Taiwan, period.
>
> So good contracts, embedded serial numbers, patents, etc. will not
> protect our design from foreign pirates.
>
> The LFSR scheme isn't perfect, but it is the most effective I've
> seen to date given the cost, size, and manufacturability limitations.
> And I believe that it is an effective barrier (but not impenetrable
> barrier) against most pirates.
>
> David Kessner
> davidk@free-ip.com

--
P.S.  Please note the new email address and website url

-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  or http://www.fpga-guru.com


Article: 22328
Subject: Code request
From: #YEO WEE KWONG# <P7102672H@ntu.edu.sg>
Date: Fri, 5 May 2000 10:10:30 +0800
Links: << >>  << T >>  << A >>
Hi Evan,

Thanks for your help. Below is my code for your examination. You are
right to say that it is slightly diff. at the initial state. Thereafter,
it should be the same after the 1st clock. I tested the code with
Synopsys DC and FPGA express. Both give me the same warning for code
(1). Are you suggesting that I should revert to code (2) style to pass
the synthesis test. If that is the case, why there is a couple of
textbook still used code (1) as a synthesizable reference code which is
quite misleading!
I am one of the victim which I hope not.

Look forward to your reply.

architecture arcCounter of ntyCounter is
  type typCounterState is (s0, s1, s2, s3);
  signal sNextState : typCounterState;
  signal sCurrState : typCounterState;

begin  -- arcCounter

  
  lblUpdState: process(pClk)       --> code (2) style
--   lblUpdState: process             --> code (1) style
  begin
    
--    wait until rising_edge(pClk); --> code (1) style
    if rising_edge(pClk) then        	--> code (2) style
      if pRst_b = '0' then
        sCurrState <= s0;
      else
        sCurrState <= sNextState;
      end if;
    end if;                                      --> code (2) style
    
  end process lblUpdState;

end arcCounter;
Yeo Wee Kwong, Sky (Mr)
Research Scholar
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
School of Applied Science
Center For High Performance Embedded Systems (ChiPES)
Nanyang Technological University
Blk N4-B3-06b Nanyang Avenue
Singapore 639798
* (65) 790-6967  *Fax  (65) 792-6559	* yeosky@singnet.com.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Words Of Wisdom:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 "Let it be the way you want to be!. Amen! 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


		-----Original Message-----
		From:	eml@riverside-machines.com.NOSPAM
[mailto:eml@riverside-machines.com.NOSPAM]
		Posted At:	Friday, May 05, 2000 4:03 AM
		Posted To:	comp.arch.fpga
		Conversation:	Wait until statement problem in
synthesis
		Subject:	Re: Wait until statement problem in
synthesis

		On Wed, 3 May 2000 18:34:59 +0800 , #YEO WEE KWONG#
		<P7102672H@ntu.edu.sg> wrote:

		>Hi,
		>
		>I wonder why wait until statement when used in a
process can generate a
		>warning of :
		>
		>Warning: Clock signal is not in the sensitivity list.
"pClk" 
		>	in routine ntyCounter line 18 in file
	
>'/home/yeowk/vhdl.dir/MyProj.dir/Vhdl.dir/arcCounter.vhd' (HDL-400)

		you can't have a wait and a sensitivity list in the same
process. can
		you post your code?

		>I thought that code (1) is the same as code (2)
functionally:
		>
		>process  -- Code(1)
		>begin 
		>  wait until rising_edge(clk);
		>   	:
		>	:
		>	:
		>end process;
		>
		>process(Clk) - Code(2)
		>begin 
		>  if rising_edge(Clk) then
		>	:
		>	:
		>	:
		>  end if;
		>end process 

		the two aren't quite equivalent. the sensitivity list
version is
		equivalent to a process with a wait as the *last*
statement, not the
		first statement. they'll behave differently at
initialisation.

		>I check the Solvit in Synopsys but cannot find any
workaround. Can
		>someone enlightened why the above statement is not
accepted in synthesis
		>engine(particular Synopsys).

		you'll have to ask synopsys. i do remember that some
cheaper synthesis
		tools would only allow wait statements as the last
statement in a
		process - you could try this as a workaround.

		>By the way, code(2) pass the synthesis without warning!
Can you explain?

		this is a standard mechanism for specifying a clocked
process to a
		synthesiser - it'll work with any synthesiser (even FPGA
express).

		evan

Article: 22329
Subject: Re: How to Prevent theft of FPGA design
From: Catalin Baetoniu <a@z.com>
Date: Fri, 05 May 2000 02:30:26 GMT
Links: << >>  << T >>  << A >>
I said you need 2*N not 2^N output bits. If N is 36, the first 72 bits output
by the CPLD are all that is required to completely reverse engineer it (both
tap positions and reset state). An LFSR is really a very bad choice in this
case, no matter what the size and clock rate are.

Now let us say you use an XC9572 (not much more expensive than the XC9536) and
you build a number of LFSRs (with different cycle lengths, mutually prime if
possible)  and output the exclusive-or of their outputs. The period is now
really big, even if you overclock the CPLD. This might be a little harder to
break but I am not sure it is much harder.

Catalin

Rickman wrote:

> a@z.com wrote:
> >
> > Hi David,
> >
> > I do not think your idea will work because reverse engineering the CPLD
> > is realy easy. All you need to do is capture a sequence of 2*n bits,
> > where n is the size of your LFSR. The first n bits will be shifted into
> > your LFSR and the next n will give you the LFSR response starting from
> > this known state. From this the position of your taps and the initial
> > key can be easily  extracted. It's like solving a system of n equations
> > with n unknowns (the taps) in a finite binary field. Even if n is not
> > known there is only a limited number of lentghs you have to try (not
> > more than the number of macrocells in your EPLD). This scheme can be
> > broken in less than one hour using just a memory oscilloscope or a logic
> > analyzer.
> >
> > Catalin
> >
> > David Kessner wrote:
> >
> > > Ray Andraka wrote:
> > > > Heavy Sigh!   This subject comes up about once every 6-9 months.
> > >
> > > Exactly, and so why have we not come up with a reasonable
> > > solution before?  I don't know...
> > >
> > > I have written an app note on this subject, and propose a simple
> > > solution using off the shelf technology.  It can be read at The
> > > Free-IP Project web site:  http://www.free-ip.com
> > >
> > > I welcome any comments on it, but my news server is flaky to say
> > > the least.  So please follow up via email.
> > >
> > > David Kessner
> > > davidk@free-ip.com
>
> If the CPLD is designed to not let you "overclock it" it takes longer
> than that to get the 2^N bits out of it at the sizes of N we are talking
> about. At 1 MHz you would half to clock it for a day to get 2^36 bits
> out. Then how exactly would you process that much data, 8 GB?
>
> However, one of the other posts indicates that you only need 36^2 bits
> to find both the taps and the initial state of a 36 bit LFSR. So this is
> not a workable solution after all.
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> remove the XY to email me.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

Article: 22330
Subject: MaxPlus9.5/6 License problems
From: "M R Wheeler" <intell-a-sys@iquest.net>
Date: Fri, 05 May 2000 03:03:23 GMT
Links: << >>  << T >>  << A >>
It appears that 9.6 has the same dongle bug.  I did not try 9.4, but know
that 9.3 does not have this problem.  There is no printers or for that
matter any other devices plugged into the printer ports, just the dongle. 
Printing is done via TCP-IP.  I have check this on three different PCs from
my dual PIII 500 to a single Pentium 200, all with the same results.  Small
projects seem to build fine, but larger ones that take hours to build will
fail the dongle checks at random.  Some times when the timing extractor
runs, other times when the fitter is running.  All PCs are running Windows
NT 4.0 SP5 or 6.  Altera now tells me that it is a known problem, but they
do not have a fix in place.  I asked them why they continue to master new
updates when the basic dongle interface has bugs.  No responce.  They were
supposed to send a temp license today, but I never recieved it.  The temp
license would have a time out anyway so I could not use the version to do
real work because I need to be able to reproduce the results from the tools
I use for some time.  So it's back to 9.32.  

On the flip side the 9.6 version seems to have fixed my fitter problems
when using the Quartus features.  
   




Subject:
       Re: MaxPlus9.5 License and Fitter problems
 Date:
       04/21/2000
 Author:
       Jim Hamblen <hamblen@ece.gatech.edu>
         
 I also have some designs that crash with internal errors unless I turn off
the Quartus fitter. They run OK when I
 turn it off.
  
 As for the dongle problem, in the past I have seen them conflict with
other dongles or a printer (if you have
 any of those connected). I had one system with three dongles and it only
worked when they were stacked in
 one order - that I found by trial and error.
  
 Tim wrote:
  
 > On Thu, 30 Mar 2000 02:14:26 GMT, "M R Wheeler"
 > <intell-a-sys@iquest.net> wrote:
 >
 > >I am evaluating MaxPlus 9.5 and am finding that often the software can
not
 > >seem to locate the dongle during the build process on larger designs. 
The
 > >software give me a license error message.  Also, when selecting the
Quartus
 > >fitter, I am getting internal errors (contact Altera, who never has a
 > >clue).  Both problems occur on two different computers.  Just wonder if
 > >anyone else is using this version yet.
 > >
 >
 > I haven't had any problems using our floating network license.  I also
 > haven't had any crashes yet.  Still, each new version fixes a thousand
 > bugs and adds a thousand more so we'll see.
 >
 > Oh, I did have to turn off the Quartus fitter to make the timing
 > requirement in a design that easily makes the timing requirements in
 > 9.3.
 >
 > Up to 25xs faster compile....the gods of marketing are feeling playful
 > today.
 >
 >                            Tim.


Article: 22331
Subject: Re: How to Prevent theft of FPGA design
From: Catalin Baetoniu <a@z.com>
Date: Fri, 05 May 2000 03:05:24 GMT
Links: << >>  << T >>  << A >>
Hi Jim,

Jim Granville wrote:

> a@z.com wrote:
> >
> > Hi David,
> >
> > I do not think your idea will work because reverse engineering the CPLD
> > is realy easy. All you need to do is capture a sequence of 2*n bits,
> > where n is the size of your LFSR.
>
>  True, but who says you have to code a LFSR in the CPLD, and use
> obvious LD.CLK.DATA pins.

Well, David Kessner does. He proposed at
http://www.free-ip.com/copyprotection.html a CPLD key based on a 36-bit LFSR
and asked for comments.

>  That's why I mentioned the ATF750, ( 24 pin CPLD ) with either
> edge clock, on any cell, you can create something that defies
> modeling - mixing PROM and Sequential state logic also makes
> stream analysis very hard.
>  Then add cross coupled clock enables, and async clocks...

David also makes the point - and I think he is right - that the protection
should be strong enough by design so that its internal structure can be made
public without compromising the key. A secret design is a weak design is a
basic cryptography concept which applies in this case too.

Nothing that is made with digital logic defies modeling - no matter how
clever your design is (clock enables, async clocks, etc.) it is still a
finite state machine and can be modeled as such. What matters is observabilty
of the hidden state and controllability (if you have inputs). Adding inputs
(clocks, enables, data in) might be a bad idea because you make the system
more controllable - using these inputs I can bring your system to a large
number of known states and explore the state space from each point. What you
think is your strong point might turn out to be your Achilles' heel. From a
controllability point of view, the ideal system would have no inputs at all,
as David proposed, an uncontrollable system. The problem with his idea is
that his state machine (a 36-bit LFSR) is completely and easily observable -
all you need is 72 consecutive output bits to find out the complete state
space map (the LFSR taps) and the initial state. With 72 macrocells there
must be a lot of finite state machines with no inputs that produce an output
sequence such that you need to acquire too many bits to completely observe
the system state, even if you know the structure of the state machine and the
only unknown is the initial state. No need for fancy hidden tricks, just use
the right design and make it big enough. Then make it _public_ and challenge
everyone to break it. If a lot of people try and nobody succeeds then _maybe_
you have a winner.

Catalin

>  Connect spare pins to the FPGA, and the combinations explode.
>
> -jg
> --
> ======= 80x51 Tools & IP Specialists  =========
> = Want to work smarter than C ?
> = http://www.DesignTools.co.nz/modbench.htm
> = http://www.DesignTools.co.nz

Article: 22332
Subject: Re: How to Prevent theft of FPGA design
From: Catalin Baetoniu <a@z.com>
Date: Fri, 05 May 2000 03:17:06 GMT
Links: << >>  << T >>  << A >>
Hi all,

A "true" random number generator is easy to do in an FPGA. Just use your
system clock and either the FPGA internal oscillator or a ring oscillator that
you create by programming a LUT as an inverter and connecting its input to its
output. Then connect these two independent clocks to the D and CLK pins of a
flip-flop and metastability will work for you this time. Pass the Q of the
flip-flop trough an LFSR and you have a true random number generator.

Another problem mentioned here is reseting the system to keep the CPLD
sequence to be emulated short. This too can be solved in the FPGA: since CLB
RAM is not reset by the GSR it can be used to implement a watchdog counter and
detect this kind of attack.

Catalin

"Nicholas C. Weaver" wrote:

> In article <3911B800.B34AE07B@yahoo.com>,
> Rickman  <spamgoeshere4@yahoo.com> wrote:
>
> >to do that. Am I correct in assuming that the bitstream from the
> >security device will run continuously? This would mean that it will
> >consume power indefinately. I guess this would not be a problem as long
> >as the power level is kept very low. You might want to add low power to
> >your list of requirements in addition to low cost.
>
>         Yes, it would and it has to, unless you can get a good real
> random number generator in the FPGA.
>
> >If a shorter reset period could be used, say 1 minute, then the memory
> >required is only 60 Mb which can be put on one chip. Using a slower
> >bitstream clock to save power would also increase the feasibility of
> >attack by frequent reset.
>
>         Yeup, that is one of the potential attacks.  The only way to
> counter it is a true random number generator in the FPGA to initialize
> the state.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 22333
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 5 May 2000 03:38:12 GMT
Links: << >>  << T >>  << A >>
In article <39122443.DD973388@fpga-guru.com>,
Ray Andraka  <ray@fpga-guru.com> wrote:

>> Until FPGA's have crypto hardware built in then this type of
>> attack will always exist for all copy protection schemes.
>
>The FPGA would also have to have a unique key in it, and herein lies the
>problem.  Even if you did put flash in it with a security bit, it might be
>possible to read the key back out by playing with program voltages etc or by
>de-lidding and inspection.

	However, the barrier for extracting the key from the internal
rom is considerably higher, close to what reverse engineering an ASIC
or antifuse or similar part but a little less than continual battery
backuped SRAM device.

	The other schemes mentioned here are really not very high
barriers, not all that much more then just reverse engineering a board
which was dipped in concrete.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 22334
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 04 May 2000 23:51:57 -0400
Links: << >>  << T >>  << A >>
Catalin Baetoniu wrote:
> 
> Hi all,
> 
> A "true" random number generator is easy to do in an FPGA. Just use your
> system clock and either the FPGA internal oscillator or a ring oscillator that
> you create by programming a LUT as an inverter and connecting its input to its
> output. Then connect these two independent clocks to the D and CLK pins of a
> flip-flop and metastability will work for you this time. Pass the Q of the
> flip-flop trough an LFSR and you have a true random number generator.
 
The metastability RNG might work ok. This is a good idea. Interestingly
enough, a PRNG or a RNG is really not what is needed in this case. Most
of the properites of these devices are not required. For example, you
don't need for the output to be evenly distributed or unbiased. You only
need for it to be run through the full range in a sequence that is not
100% predictable. Personally, I think a free running oscillator RNG is
the solution with the most potential. 


> Another problem mentioned here is reseting the system to keep the CPLD
> sequence to be emulated short. This too can be solved in the FPGA: since CLB
> RAM is not reset by the GSR it can be used to implement a watchdog counter and
> detect this kind of attack.
> 
> Catalin

The issue with CLB RAM is not whether it is cleared on reset. The issue
is whether it is cleared on configuration. It only takes a millisecond
or so to reload most FPGAs. Many systems would not notice this small
amount of time that the FPGA was down. In fact, some systems use a full
reset and reconfiguration to keep things working correctly. Just ask rk.
He is testing this concept to use on a space mission to make Xilinx
parts fully resistant to radiation! 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 22335
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 05 May 2000 00:01:03 -0400
Links: << >>  << T >>  << A >>
Catalin Baetoniu wrote:
> 
> I said you need 2*N not 2^N output bits. If N is 36, the first 72 bits output
> by the CPLD are all that is required to completely reverse engineer it (both
> tap positions and reset state). An LFSR is really a very bad choice in this
> case, no matter what the size and clock rate are.
> 
> Now let us say you use an XC9572 (not much more expensive than the XC9536) and
> you build a number of LFSRs (with different cycle lengths, mutually prime if
> possible)  and output the exclusive-or of their outputs. The period is now
> really big, even if you overclock the CPLD. This might be a little harder to
> break but I am not sure it is much harder.
> 
> Catalin

Sorry, one of the other posts indicated that N^2 was needed for the case
of not knowing the taps. I misread your post. 

What is the process for reverse engineering a LFSR from the N*2 samples?
Surely it would not be a matter of trial and error. Is there some way to
calculate the taps and starting number? I agree that with an N bit LFSR,
two different machines must give different results within 2*N bits. If
they don't they MUST be the same machine. But that is not the same as
saying you can deduce the starting number and taps without trying all
possible machines and starting positions. That would be like saying DES
is breakable by trying all possible keys. 

I think it is interesting that no one has posted an algorithm other than
a full blown DES that will meet our needs. Is it possible that there are
no solutions that even come close to what we need without the full
robustness of DES? 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 22336
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 05 May 2000 00:09:31 -0400
Links: << >>  << T >>  << A >>
Catalin Baetoniu wrote:
> David also makes the point - and I think he is right - that the protection
> should be strong enough by design so that its internal structure can be made
> public without compromising the key. A secret design is a weak design is a
> basic cryptography concept which applies in this case too.
> 
> Nothing that is made with digital logic defies modeling - no matter how
> clever your design is (clock enables, async clocks, etc.) it is still a
> finite state machine and can be modeled as such. What matters is observabilty
> of the hidden state and controllability (if you have inputs). Adding inputs
> (clocks, enables, data in) might be a bad idea because you make the system
> more controllable - using these inputs I can bring your system to a large
> number of known states and explore the state space from each point. What you
> think is your strong point might turn out to be your Achilles' heel. From a
> controllability point of view, the ideal system would have no inputs at all,
> as David proposed, an uncontrollable system. The problem with his idea is
> that his state machine (a 36-bit LFSR) is completely and easily observable -
> all you need is 72 consecutive output bits to find out the complete state
> space map (the LFSR taps) and the initial state. With 72 macrocells there
> must be a lot of finite state machines with no inputs that produce an output
> sequence such that you need to acquire too many bits to completely observe
> the system state, even if you know the structure of the state machine and the
> only unknown is the initial state. No need for fancy hidden tricks, just use
> the right design and make it big enough. Then make it _public_ and challenge
> everyone to break it. If a lot of people try and nobody succeeds then _maybe_
> you have a winner.
> 
> Catalin


Yes, this is exactly what we are looking for. An algorithm that will not
be analyzable from examining the outputs. But stating the problem in
only half the solution and the easy half at that. I am wondering if
there is a solution that is trivial to implement in a CPLD or even a
very small micro. Something as complex as DES would be too expensive to
build into the FPGA. 

Or maybe the cryptographers already know the solution, but they aren't
telling!!!???


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 22337
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 5 May 2000 04:16:36 GMT
Links: << >>  << T >>  << A >>
In article <3912497B.7F608289@yahoo.com>,
Rickman  <spamgoeshere4@yahoo.com> wrote:
>Or maybe the cryptographers already know the solution, but they aren't
>telling!!!???

	They do, it's a pretty easy application of a good cypher.
Just  E(N,K) for a good E and a random K, gives a pseudo random
number, just increment N.

	However, the algorithms you would want to use will NOT fit
comfortably in a $1 cpld.  DES, which is pretty small, is still larger
then you want.  I HAVE seen a couple of really small & cute
algorithms, but they are still signifcantly larger than you want.

	And, as discussed, the problem quickly becomes one of
attacking the system.  An LFSR is too weak, but much more quickly
becomes overkill when compared with jbitsing the bitfile.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 22338
Subject: Re: How to Prevent theft of FPGA design
From: david_kessner@my-deja.com
Date: Fri, 05 May 2000 05:20:25 GMT
Links: << >>  << T >>  << A >>
Ok...  Here's my summary, to date, of this LFSR method:

Using a cryptographically strong LFSR, there is no reasonable way to break
the LFSR by analyzing the random bit stream.  This might take more than 64
macrocells and more than 20 slices/CLB's.  Some might debate this, but it's a
moot point because...

  Ray Andraka <ray@fpga-guru.com> wrote:
> There is Jbits for 4K/spartan  too.

Damn!  So we can basically write off this method, and just about any other
method, that uses current Xilinx chips.  (Hey, you killed Kenny!  You
bastard!)

While this method is still applicable to Altera and other FPGA's, there are
other problems...

Ray also said (paraphrased):
> With Flash EEPROM or a Flash based CPLD, it might be
> possible to read the key back out by playing with program voltages etc or by
> de-lidding and inspection.

I think that this would be ad-hoc at best, and trial and error at worst.  But
none the less, I conceed that this is a potential way to attack and it
might even be successful.


Here's what I currently think the LFSR method is good for:

A simple encryption quality LFSR when implemented in a CPLD
and Non-Xilinx SRAM based FPGA is sufficent to deter most
casual pirates.  But any professional pirate willing to devote some
time and money at it will probably be able to break this method in
a reasonable time frame using one of the previously mentioned
approaches.  In short, I conceed defeat on this one.

Unfortunately, what this shows is that more sophisticated
encryption would not increase the security given the existance
of JBits for all Xilinx parts of interest and given the vulnerability
of Flash based CPLD's (and probably uC's as well).

Oh well.  It was a nice try...  :(


And another thing...  Someone mentioned using a free-running
oscilator (made from an inverter fed back into itself) as a source
for random numbers.  Unfortunately this doesn't work.  It works
in the simulators, but not in real devices.  If you put two of these
oscilators on the same FPGA (and nothing else) they tend to
lock to eachother and will eventually will be in sync and remain
in sync.  With just one of these oscilators on a full FPGA, the
osc will tend to lock to some other source of noise in the system
which will make the random numbers highly correlated to what's
going on in the FPGA-- not random at all.

Using the on board temperature sensor doesn't work either--
at least not for security uses.  That's because the temp
sensor requires that the signals be ran outside the chip.
If they are outside the chip then they are vulerable to attack.
For instance, someone could just ground those signals and
force the random number generator to always output zero
(or one, or whatever).

David Kessner
davidk@free-ip.com


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 22339
Subject: Re: Init/ line - CRC error ???
From: "Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr>
Date: Fri, 05 May 2000 08:15:50 +0200
Links: << >>  << T >>  << A >>
Philip Freidin wrote:

> >I have do a small design with a Xilinx FPGA (XC5200 but it's normaly the
> >same thing on Spartan and 4000) on Slave Serial mode. When I program it,
> >after N bits sended, it pull down the init/ line. I don't understand why
> >I have a CRC error because each bit sended (on the pin DIN) is at each
> >time compared with the DOUT pin after.
>
> If you really have ALL the input bits appearing onthe DOUT, this is
> definitely not good. The data on the DOUT pin will be a delayed by 1
> cycle version of the data on the DIN pin, but ONLY for the duration of
> the header (40 bits). After the header, the DOUT pin should be high for
> the duration of the bitstream, and then reverts to echoing the DIN data
> to load down stream parts. In a single chip situation, there is no
> downstream devices, so the device will complete and then go DONE.
>

Yes I have read all data after the write cycle... But the DOUT pin hold the
bit ! In fact if you see the databook XC5200 p7-114 you could see the
chronogram with all data bit reported after the write cycle on the DOUT pin
%-(
I have never read that is only for the header sequence...

But if you're sure, perhaps the header is not correctly read byt the FPGA and
all bits are reported on the DOUT pin :(

>         Is the config clock running before the configuration starts,
>         and loads junk before the header?
>

No, I'm sure that the CCLK pin is correctly drive because when I use the ISA
bus to drive a control logic that generate the CCLK signal for the FPGA.

>         Is the config clock clean, both rising and falling edges, check
>         with at least a 300MHz scope.

hum.... I must check it with a oscilloscope but this signal has already test
my board with others latchs (just for tests) so...


>         Are you changing DIN data when the CCLK clock edge rises, You
>         shouldn't
>

Year... DIN is at least 60ns set before the CCLK rising edge  (20ns is the
minimal setup time)


> >Have you already find the same problem ? I think perhaps it's due at a
> >power problem, because the ouputs pin HDC and LDC/ are at 5V and 1.1
> >V (and no near 0V) respectivly.
> >
>
> An unloaded HDC could be at 5V, but LDC should be near ground. What do you
> have connected to it?
>

Just a volt-tester :( It's really strange to see 1.1V on the LDC/ line !


> >But if the FPGA is not correctly powered, why it accepts bit during
> >configuration process and put DOUT correctly ?? %-(
>
> As I said above, this is not correct. DOUT only follows DIN during the
> header, and after the device is configured, not while configuring. Are
> the two pins shorted?
>

No of course, the two pins aren't shorted. How it's possible to read all bit
sended on the DIN pin, on the DOUT pin ?


Thanks for your help,



Article: 22340
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 05 May 2000 02:34:34 -0400
Links: << >>  << T >>  << A >>
I am spending way too much time reading these messages, but I find this
very interesting. So let me play devil's advocate on this.


david_kessner@my-deja.com wrote:
> 
> Ok...  Here's my summary, to date, of this LFSR method:
> 
> Using a cryptographically strong LFSR, there is no reasonable way to break
> the LFSR by analyzing the random bit stream.  This might take more than 64
> macrocells and more than 20 slices/CLB's.  Some might debate this, but it's a
> moot point because...

Can you define, or better yet give an example of a "cryptographically
strong LFSR"? I do believe it when people have stated that if you know
the structure of a LFSR of length N, it will only take N samples to
determin the initial state. I will also submit to the statement that if
the structure is not known, then it may be possible to determin the
initial state as well as the taps with 2N samples, although I am not
certain you can do this without trying all possiblities which would be
way too expensive for any but the most well funded efforts. But it
certainly makes sense that a LFSR is not truly robust against an
analysis. 

So how do you design a LFSR that can not be easily analyzed?

 
>   Ray Andraka <ray@fpga-guru.com> wrote:
> > There is Jbits for 4K/spartan  too.
> 
> Damn!  So we can basically write off this method, and just about any other
> method, that uses current Xilinx chips.  (Hey, you killed Kenny!  You
> bastard!)
> 
> While this method is still applicable to Altera and other FPGA's, there are
> other problems...

This is a case of ignorance being bliss. I am not aware that Jbits
allows you to reverse engineer a Xilinx bitstream. Is this true or is it
just that Jbits makes it easier to reverse engineer the Xilinx parts in
general and you would still have a major effort in doing so? If you have
to use Jbits to twiddle a bit then you load it into an FPGA and see what
you just changed, then I don't consider this to be an easy way to
reverse engineer a Xilinx configuration bitstream. 
 

> Ray also said (paraphrased):
> > With Flash EEPROM or a Flash based CPLD, it might be
> > possible to read the key back out by playing with program voltages etc or by
> > de-lidding and inspection.
> 
> I think that this would be ad-hoc at best, and trial and error at worst.  But
> none the less, I conceed that this is a potential way to attack and it
> might even be successful.

Certainly you could conceivably delid a device and examine it with an
electron microscope to analyze it while it is on. I have seen electron
micrographs of circuits in real time. But again I don't consider this to
be in the realm of "easy". I doubt that I would spend as much time and
money on designing the circuit as they would reverse engineering it this
way.

 
> Here's what I currently think the LFSR method is good for:
> 
> A simple encryption quality LFSR when implemented in a CPLD
> and Non-Xilinx SRAM based FPGA is sufficent to deter most
> casual pirates.  But any professional pirate willing to devote some
> time and money at it will probably be able to break this method in
> a reasonable time frame using one of the previously mentioned
> approaches.  In short, I conceed defeat on this one.
> 
> Unfortunately, what this shows is that more sophisticated
> encryption would not increase the security given the existance
> of JBits for all Xilinx parts of interest and given the vulnerability
> of Flash based CPLD's (and probably uC's as well).
> 
> Oh well.  It was a nice try...  :(

Others have indicated that the LFSR is less robust and I feel that the
Xilinx design and the CPLD (or micro in my case) are more robust than my
requirements. So depending on just how hard it is to attack the LFSR
initial state, we may need a more robust algorithm. 
 

> And another thing...  Someone mentioned using a free-running
> oscilator (made from an inverter fed back into itself) as a source
> for random numbers.  Unfortunately this doesn't work.  It works
> in the simulators, but not in real devices.  If you put two of these
> oscilators on the same FPGA (and nothing else) they tend to
> lock to eachother and will eventually will be in sync and remain
> in sync.  With just one of these oscilators on a full FPGA, the
> osc will tend to lock to some other source of noise in the system
> which will make the random numbers highly correlated to what's
> going on in the FPGA-- not random at all.

I am not convinced that this is really a problem. If the two oscillators
lock to some ratio on a given board, that will not say that they will
allways lock at that ratio on every board. The random numbers only have
to produce a pattern of numbers that is not repeatable on powerup. Even
if the two oscillators are locked, that will not guarantee that they
will produce the same result every time like a computer program would.
Remember that the non-crystal oscillator will be voltage, temperature
and process dependant as well. 

 
> Using the on board temperature sensor doesn't work either--
> at least not for security uses.  That's because the temp
> sensor requires that the signals be ran outside the chip.
> If they are outside the chip then they are vulerable to attack.
> For instance, someone could just ground those signals and
> force the random number generator to always output zero
> (or one, or whatever).
> 
> David Kessner
> davidk@free-ip.com
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

I would be willing to bet that a form of stimulus, response approach
would be the most resistant to attack. The FPGA uses the non-repeated
(as opposed to PRNG) generator from the free running oscillator to
stimulate the Key Chip (since it may be a micro rather than a CPLD). The
Key Chip then returns a result based on some processing with the LFSR.
This can be duplicated in the FPGA with different initial conditions for
different designs/customers as you choose. The FPGA would only stimulate
the Key Chip say a hundred times a second. If the Key Chip is stimulated
more often, it shuts down until power is removed. 

This would be resistant to copying the key bitstream since the stimulus
will be different for different boards. Analysis would not work since
the data can only be dragged out of the Key Chip at a very low data
rate. Since the direct output of the LFSR is not observed, the LFSR
initial state can not be analyzed. 

Does this cover all the bases?


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 22341
Subject: Re: [BitGen] - pb option UserClk
From: "Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr>
Date: Fri, 05 May 2000 09:20:10 +0200
Links: << >>  << T >>  << A >>
> You should post your bitgen.ut file, then it would be easier for us to
> help you. Even if you use the GUI, there is a bitget.ut file created.
>

I don't known the ucf format :( I use Leonardo Spectrum on Unix to create a
edif or xnf... netlist. After I use Alliance on UNIX to translate the netlist
in ncf format and eventually generate a bitstream.
How format can I post ? Or perhaps the VHDL design ? It's just a VERY small
design to test the configuration process on the FPGA so...

> The point is, if you use the user clock as your startup clock, ...
> -g StartUpClk:USERCLK
> -g DoneActive:U2
> -g OutputsActive:U3
> -g GSRInactive:U4
>
> .. then you must instantiate a STARTUP component and connect its CLK
> input to some external clock source.

Incredible> Why I must instantiate a StartUp component on my design VHDL ? I
think really that you have right but it's not really logical. In fact, the
design FPGA represents only (for me !) the description of comportment
AFTER the configuration process. So why I must specify the configuration
process "component" in the design ?

Very strange technique, no ? So, here my VHDL "design"... Perhaps I have not
understand the objectif of the StartUp Component...


LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
LIBRARY exemplar;
USE exemplar.exemplar_1164.ALL;


ENTITY FPGA IS
  PORT (
    Clock_i       : IN STD_LOGIC;
     Reset_ib        : IN STD_LOGIC;
       CCLK_i    : IN STD_LOGIC;

       CS_ib         : IN STD_LOGIC;
       RdWr_i            : IN STD_LOGIC;
       Data_io          : INOUT STD_LOGIC_VECTOR(7 downto 0)

       );


-- Pin Location --
------------------

ATTRIBUTE PIN_NUMBER : STRING;
ATTRIBUTE PIN_NUMBER OF Clock_i     : SIGNAL IS "P35";
ATTRIBUTE PIN_NUMBER OF CCLK_i      : SIGNAL IS "P73";

ATTRIBUTE PIN_NUMBER OF Reset_ib    : SIGNAL IS "P84";

ATTRIBUTE PIN_NUMBER OF CS_ib       : SIGNAL IS "P13";
ATTRIBUTE PIN_NUMBER OF RdWr_i      : SIGNAL IS "P47";
ATTRIBUTE ARRAY_PIN_NUMBER OF Data_io : SIGNAL IS
("P56","P58","P59","P61","P65","P67","P69","P71");


-- Global CLK --
----------------

ATTRIBUTE  BUFFER_SIG OF Clock_i     : SIGNAL IS "BUFG";
ATTRIBUTE  BUFFER_SIG OF CS_ib     : SIGNAL IS "BUFG";


-- CLOCK definition --
----------------------
ATTRIBUTE CLOCK_CYCLE OF Clock_i    : SIGNAL IS 83ns;  -- 12 MHz (8 MHz =>
125ns)
--ATTRIBUTE CLOCK_OFFSET OF Clock_i : SIGNAL IS ns;
--ATTRIBUTE PULSE_WIDTH OF Clock_i  : SIGNAL IS ns;
--ATTRIBUTE ARRIVAL_TIME OF Clock_i : SIGNAL IS ns;


END FPGA;

ARCHITECTURE XC5200 OF FPGA IS
  SIGNAL Dummy1,Dummy2,Dummy3,Dummy4 : STD_LOGIC;

  SIGNAL Reset : STD_LOGIC;

  SIGNAL RegTmp: STD_LOGIC;

  COMPONENT STARTBUF
   PORT (GSRin, GTSin, CLKin : IN STD_LOGIC;
      GSRout, GTSout, DONEinout, Q1Q4out, Q2out, Q3out : OUT STD_LOGIC);
  END COMPONENT;

BEGIN

  StartComponent:STARTBUF port map (GSRin     => Reset_ib,
              GTSin     => '0',
              CLKin     => CCLK_i,
              GSRout    => Reset,
              DONEinout => Dummy4,
              Q1Q4out   => Dummy1,
              Q2out     => Dummy2,
              Q3out     => Dummy3);

 PROCESS (Clock_i)
 BEGIN
  IF Rising_Edge(Clock_i) THEN
  IF (CS_ib = '0') THEN
   IF (Reset = '0') THEN
    RegTmp <= '0';
   ELSE
    IF (RdWr_i = '1') THEN
     Data_io <= "0101010" & RegTmp;
    ELSE
    Data_io <= (others => 'Z');
    END IF;
   END IF;
   END IF;
  END IF;
 END PROCESS;


END XC5200;





Thanks,


Sebastien


Article: 22342
Subject: Re: How to Prevent theft of FPGA design
From: murray@pa.dec.com (Hal Murray)
Date: 5 May 2000 07:46:04 GMT
Links: << >>  << T >>  << A >>

> What the industry needs for FPGAs to take off is some sort of DES like
> encription which can be OPTIONALLY used on the bit stream.

Do you have any data to verify that "take off" claim?  Do you really
think the volume of parts shipped would double if they had a solid
anti-theft story?

I'll toss in my two cents worth.  All of the FPGAs I've worked on
didn't have any security issues.  They were used in complicated
systems that were low volume.  (If you could make them significiantly
cheaper we would buy them from you rather than build them ourselves.)

-- 
These are my opinions, not necessarily my employers.

Article: 22343
Subject: Re: edif
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Fri, 05 May 2000 14:44:40 +0300
Links: << >>  << T >>  << A >>
Christian Mautner wrote:

> just installed FPGA express 3.4 today, and had to accept that now the
> step from XNF to EDIF has been taken. So I guess I'll have to dump my
> xnf-parsing perl scripts.
>
> I tried to port the scripts to parse edif, but this is not very easy,
> since the lispy file format is not very Perl-friendly, since Perl is
> line-by-line and regexp based. I tried the perl-lisp package, but this
> is not practical with several-MB-edif-files.
>
> So, did anyone succeed in writing edif parsing scripts? At the moment
> I am looking into gcl (GNU common lisp) and clicc (common lisp to C
> compiler), but it seems to be a rather long way to go.
>
> Is there any edif-netlist-reading-frontend for anything (like Perl,
> python, tcl, or C) out there?  (free and open source, of course)
>
> chm.
>
> --
> cmautner@  -  Christian Mautner
> utanet.at  -  Vienna/Austria/Europe

EDIF and Tcl are stack-oriented programming languages, so
I think a LISP interface might help you. A text processing LISP
script must be very much compact code than conventional
procedural languages. I think you can catch Tcl code around
which would be in my opinion the best. AFAIK EDIF and Tcl
are LISP variants.

Utku

--
I feel better than James Brown.



Article: 22344
Subject: Your opinion Arexsys design tools and SDL description methodology
From: boniolopez@my-deja.com
Date: Fri, 05 May 2000 11:49:46 GMT
Links: << >>  << T >>  << A >>


Hi frioend,
has anybody worked with Arexsys tools?
What do you think about SDL as system level description language?
You experiences with Arexsys tools and about quality of partitioning,
generated HDL and C
And other your thinks about this point are greatly appreciated!

Regards,
Bonio
My email is: Bonio.lopez@gmx.ch_Remove_this


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22345
Subject: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Michael Barr <mbarr@netrino.com>
Date: Fri, 05 May 2000 08:52:26 -0400
Links: << >>  << T >>  << A >>
This is a periodic posting to let readers of these newsgroups know
about several online resources that may be relevant:

[1]  Embedded Systems Glossary

        http://www.netrino.com/Publications/Glossary/

[2]  Embedded Systems Bibliography

        http://www.netrino.com/Publications/Bibliography/

These are online versions of the Glossary and Bibliography from my
book, "Programming Embedded Systems in C and C++" (O'Reilly and
Associates, ISBN 1-56592-354-5).

It is my intention to make occasional changes and updates to these
online versions.  I would very much like to hear your constructive
feedback.  Please send your suggestions to <webmaster@netrino.com>.

I have put a lot of work into writing the book and creating and
maintaining these online resources.  I hope that they will be a
valuable contribution to the community of embedded systems hard-
ware and software designers.

Sincerely,
           Michael Barr
Article: 22346
Subject: Re: [BitGen] - pb option UserClk
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 05 May 2000 08:55:29 -0400
Links: << >>  << T >>  << A >>
I think what is being said is that you must have mistakenly selected the
USERCLK for the Startupclk in the GUI. There in normally not a strong
reason for changing the default from CCLK to USERCLK. If you do have a
reason for this change, then you need to provide a USERCLK to the
StartUp component in your design. Otherwise just change it back to CCLK!


"Sebastien Favard (Gordh)" wrote:
> 
> > You should post your bitgen.ut file, then it would be easier for us to
> > help you. Even if you use the GUI, there is a bitget.ut file created.
> >
> 
> I don't known the ucf format :( I use Leonardo Spectrum on Unix to create a
> edif or xnf... netlist. After I use Alliance on UNIX to translate the netlist
> in ncf format and eventually generate a bitstream.
> How format can I post ? Or perhaps the VHDL design ? It's just a VERY small
> design to test the configuration process on the FPGA so...
> 
> > The point is, if you use the user clock as your startup clock, ...
> > -g StartUpClk:USERCLK
> > -g DoneActive:U2
> > -g OutputsActive:U3
> > -g GSRInactive:U4
> >
> > .. then you must instantiate a STARTUP component and connect its CLK
> > input to some external clock source.
> 
> Incredible> Why I must instantiate a StartUp component on my design VHDL ? I
> think really that you have right but it's not really logical. In fact, the
> design FPGA represents only (for me !) the description of comportment
> AFTER the configuration process. So why I must specify the configuration
> process "component" in the design ?
> 
> Very strange technique, no ? So, here my VHDL "design"... Perhaps I have not
> understand the objectif of the StartUp Component...
> 
> LIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
> LIBRARY exemplar;
> USE exemplar.exemplar_1164.ALL;
> 
> ENTITY FPGA IS
>   PORT (
>     Clock_i       : IN STD_LOGIC;
>      Reset_ib        : IN STD_LOGIC;
>        CCLK_i    : IN STD_LOGIC;
> 
>        CS_ib         : IN STD_LOGIC;
>        RdWr_i            : IN STD_LOGIC;
>        Data_io          : INOUT STD_LOGIC_VECTOR(7 downto 0)
> 
>        );
> 
> -- Pin Location --
> ------------------
> 
> ATTRIBUTE PIN_NUMBER : STRING;
> ATTRIBUTE PIN_NUMBER OF Clock_i     : SIGNAL IS "P35";
> ATTRIBUTE PIN_NUMBER OF CCLK_i      : SIGNAL IS "P73";
> 
> ATTRIBUTE PIN_NUMBER OF Reset_ib    : SIGNAL IS "P84";
> 
> ATTRIBUTE PIN_NUMBER OF CS_ib       : SIGNAL IS "P13";
> ATTRIBUTE PIN_NUMBER OF RdWr_i      : SIGNAL IS "P47";
> ATTRIBUTE ARRAY_PIN_NUMBER OF Data_io : SIGNAL IS
> ("P56","P58","P59","P61","P65","P67","P69","P71");
> 
> -- Global CLK --
> ----------------
> 
> ATTRIBUTE  BUFFER_SIG OF Clock_i     : SIGNAL IS "BUFG";
> ATTRIBUTE  BUFFER_SIG OF CS_ib     : SIGNAL IS "BUFG";
> 
> -- CLOCK definition --
> ----------------------
> ATTRIBUTE CLOCK_CYCLE OF Clock_i    : SIGNAL IS 83ns;  -- 12 MHz (8 MHz =>
> 125ns)
> --ATTRIBUTE CLOCK_OFFSET OF Clock_i : SIGNAL IS ns;
> --ATTRIBUTE PULSE_WIDTH OF Clock_i  : SIGNAL IS ns;
> --ATTRIBUTE ARRIVAL_TIME OF Clock_i : SIGNAL IS ns;
> 
> END FPGA;
> 
> ARCHITECTURE XC5200 OF FPGA IS
>   SIGNAL Dummy1,Dummy2,Dummy3,Dummy4 : STD_LOGIC;
> 
>   SIGNAL Reset : STD_LOGIC;
> 
>   SIGNAL RegTmp: STD_LOGIC;
> 
>   COMPONENT STARTBUF
>    PORT (GSRin, GTSin, CLKin : IN STD_LOGIC;
>       GSRout, GTSout, DONEinout, Q1Q4out, Q2out, Q3out : OUT STD_LOGIC);
>   END COMPONENT;
> 
> BEGIN
> 
>   StartComponent:STARTBUF port map (GSRin     => Reset_ib,
>               GTSin     => '0',
>               CLKin     => CCLK_i,
>               GSRout    => Reset,
>               DONEinout => Dummy4,
>               Q1Q4out   => Dummy1,
>               Q2out     => Dummy2,
>               Q3out     => Dummy3);
> 
>  PROCESS (Clock_i)
>  BEGIN
>   IF Rising_Edge(Clock_i) THEN
>   IF (CS_ib = '0') THEN
>    IF (Reset = '0') THEN
>     RegTmp <= '0';
>    ELSE
>     IF (RdWr_i = '1') THEN
>      Data_io <= "0101010" & RegTmp;
>     ELSE
>     Data_io <= (others => 'Z');
>     END IF;
>    END IF;
>    END IF;
>   END IF;
>  END PROCESS;
> 
> END XC5200;
> 
> Thanks,
> 
> Sebastien


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 22347
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: OneStone <onestone@chariot.net.au>
Date: Fri, 05 May 2000 23:56:41 +0930
Links: << >>  << T >>  << A >>
Michael, I have had a look at the Glossary and have the following
comments:-

1. You list Binary Semaphore and the even less known term mutex yet omit
the simplest term which is a flag or flag bit.

2. Emulator may not necessarily refer to an In Circuit Emulator, as
stated. There are other types of emulator used in this field. Emulators
are not necessarily processor substitutes either. Remember, not all
embedded systems necessarily use a microprocessor. ASIC's, FPGA's, etc
all come under the embedded umbrella.

3. Although apparently out of vogue, though used more than ever, Fuzzy
logic, and fifo seem to be a major omissions.

4. Interrupt priority is a common subject on the NG.

5. Pipeline is a common feature

Just my opinion.

Al



Michael Barr wrote:
> 
> This is a periodic posting to let readers of these newsgroups know
> about several online resources that may be relevant:
> 
> [1]  Embedded Systems Glossary
> 
>         http://www.netrino.com/Publications/Glossary/
> 
> [2]  Embedded Systems Bibliography
> 
>         http://www.netrino.com/Publications/Bibliography/
> 
> These are online versions of the Glossary and Bibliography from my
> book, "Programming Embedded Systems in C and C++" (O'Reilly and
> Associates, ISBN 1-56592-354-5).
> 
> It is my intention to make occasional changes and updates to these
> online versions.  I would very much like to hear your constructive
> feedback.  Please send your suggestions to <webmaster@netrino.com>.
> 
> I have put a lot of work into writing the book and creating and
> maintaining these online resources.  I hope that they will be a
> valuable contribution to the community of embedded systems hard-
> ware and software designers.
> 
> Sincerely,
>            Michael Barr
Article: 22348
Subject: Re: How to Prevent theft of FPGA design
From: David Kessner <davidk@free-ip.com>
Date: Fri, 05 May 2000 09:01:36 -0600
Links: << >>  << T >>  << A >>
Rickman wrote:
> davidk@free-ip.com wrote:
> > Using a cryptographically strong LFSR, there is no reasonable way to break
> > the LFSR by analyzing the random bit stream.  This might take more than 64
> > macrocells and more than 20 slices/CLB's.  Some might debate this, but it's a
> > moot point because...
> 
> Can you define, or better yet give an example of a "cryptographically
> strong LFSR"? I do believe it when people have stated that if you know
> the structure of a LFSR of length N, it will only take N samples to
> determin the initial state. I will also submit to the statement that if
> the structure is not known, then it may be possible to determin the
> initial state as well as the taps with 2N samples, although I am not
> certain you can do this without trying all possiblities which would be
> way too expensive for any but the most well funded efforts. But it
> certainly makes sense that a LFSR is not truly robust against an
> analysis.
> 
> So how do you design a LFSR that can not be easily analyzed?

I posted a message describing some better LFSRs, but in my news server
mess (I switched ISP's, and had to use Deja between) I think it got
lost...

The book "Applied Crypto, 2nd edition" by Bruce Schneier shows several
PRBS generators based on LFSR's that are much better.  The book also
nicely describes several that are not at all secure.

One type that is reasonably secure is called a "Bilateral Stop-and-Go
Generator".  This generator uses two LFSRs of the same length.  The
output is the XOR of each LFSR outputs.  If the output of LFSR #1 
at T-1 is 0 and the output at time T-2 is 1 then LFSR #2 does not 
clock at time T.  Conversely, if the output of LFSR #2 at time T-1
is 0 and 1 at T-2 then LFSR #1 doesn't clock at time T.

This is just one example, the book describes several that would
be suitable.




> >   Ray Andraka <ray@fpga-guru.com> wrote:
> > > There is Jbits for 4K/spartan  too.
> >
> > Damn!  So we can basically write off this method, and just about any other
> > method, that uses current Xilinx chips.  (Hey, you killed Kenny!  You
> > bastard!)
> >
> > While this method is still applicable to Altera and other FPGA's, there are
> > other problems...
> 
> This is a case of ignorance being bliss. I am not aware that Jbits
> allows you to reverse engineer a Xilinx bitstream. Is this true or is it
> just that Jbits makes it easier to reverse engineer the Xilinx parts in
> general and you would still have a major effort in doing so? 

Check out the Xilinx web site and search for JBits.  While I wouldn't
call it easy to use, it does allow someone to analyze and FPGA and
essentially extract a netlist that LUT contents.  After that, the rest
is just an excersize for the reader...  :(


> If you have
> to use Jbits to twiddle a bit then you load it into an FPGA and see what
> you just changed, then I don't consider this to be an easy way to
> reverse engineer a Xilinx configuration bitstream.

With Jbits you can do rather high level things in a very predictable
way.  It isn't just flipping bits and seeing what happens.  You can
reroute traces, change LUT's, etc. without having to resort to trial 
and error.


> > Here's what I currently think the LFSR method is good for:
> >
> > A simple encryption quality LFSR when implemented in a CPLD
> > and Non-Xilinx SRAM based FPGA is sufficent to deter most
> > casual pirates.  But any professional pirate willing to devote some
> > time and money at it will probably be able to break this method in
> > a reasonable time frame using one of the previously mentioned
> > approaches.  In short, I conceed defeat on this one.
> >
> > Unfortunately, what this shows is that more sophisticated
> > encryption would not increase the security given the existance
> > of JBits for all Xilinx parts of interest and given the vulnerability
> > of Flash based CPLD's (and probably uC's as well).
> >
> > Oh well.  It was a nice try...  :(
> 
> Others have indicated that the LFSR is less robust and I feel that the
> Xilinx design and the CPLD (or micro in my case) are more robust than my
> requirements. So depending on just how hard it is to attack the LFSR
> initial state, we may need a more robust algorithm.

But a more robust algorithm isn't going to help as long as we can
reverse engineer CPLD's and Jbits exists.



> > And another thing...  Someone mentioned using a free-running
> > oscilator (made from an inverter fed back into itself) as a source
> > for random numbers.  Unfortunately this doesn't work.  It works
> > in the simulators, but not in real devices.  If you put two of these
> > oscilators on the same FPGA (and nothing else) they tend to
> > lock to eachother and will eventually will be in sync and remain
> > in sync.  With just one of these oscilators on a full FPGA, the
> > osc will tend to lock to some other source of noise in the system
> > which will make the random numbers highly correlated to what's
> > going on in the FPGA-- not random at all.
> 
> I am not convinced that this is really a problem. If the two oscillators
> lock to some ratio on a given board, that will not say that they will
> allways lock at that ratio on every board. The random numbers only have
> to produce a pattern of numbers that is not repeatable on powerup. Even
> if the two oscillators are locked, that will not guarantee that they
> will produce the same result every time like a computer program would.
> Remember that the non-crystal oscillator will be voltage, temperature
> and process dependant as well.

The point is that the oscillators will tend to lock to other things
happening in the FPGA.  The original posted suggested that a single
inverting feedback oscillator be used in conjunction with a more stable
crystal oscillator.  The crystal clock is ran to the clock input on a
flip flop and the D input is fed from this inverting feedback clock.
In the most simplistic sense, this oscillator will tend to lock to 
a harmonic of the crystal clock-- causing the flip flop to capture
more 0's (or 1's) than the other.  This is hardly random and would
reduce the effective "key size" (since we would know that 80% of the
key bits are 0).  

How reproducible the results are is really something that only 
experimentation can provide.  It wouldn't surprise me at all if it
was very repeatable given the same temp and voltage.  I'm fairly
sure that if you let the board warm up then reset it 10 times in
a row you would probably get at least 2 or 3 "random number matches".


> I would be willing to bet that a form of stimulus, response approach
> would be the most resistant to attack. 

Not as long as Jbits is around.  That alone would kill it.  This type
of attack is independent of the algorithm used.  Just find the signal
that disables some important internal state machine and force that
signal inactive.  Since you can read the netlist from the FPGA this is
a relatively simple thing to do.

Then there is the question of being able to "disable" the security
bit in Flash CPLD's and uC's.  I think that this is difficult, but
possible.

Given the above two attacks, a reasonably design LFSR is just as secure
as a stimulus/response type of algorithm and a lot easier and smaller
to implement.  I'm not saying that an LFSR approach is totally secure,
just that it is no less secure than a stimulus/response method given
these likely methods of attack.


David Kessner
davidk@free-ip.com

Article: 22349
Subject: Porting design from xc40150xv to xcv300
From: "Kang Liat Chuan" <kanglc@cyberway.com.sg>
Date: Fri, 5 May 2000 23:37:20 +0800
Links: << >>  << T >>  << A >>
Hi all,

I have been using a board with Xilinx xc40150xv devices, and would like to
evaluate the possibility of porting my design to a virtex board with xcv300
device. The problem is my design needs to use some logiblox and coregen
symbols such as multiplier, square root, and accumulator etc. Is this
possible?

Regards,
LC




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