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
2017JanFebMarApr2017

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 22275

Article: 22275
Subject: Re: How to Prevent theft of FPGA design
From: Ray Andraka <randraka@ids.net>
Date: Thu, 04 May 2000 00:54:21 GMT
Links: << >>  << T >>  << A >>
Heavy Sigh!   This subject comes up about once every 6-9 months.  SRAM FPGAs
use cutting edge process (and in fact are ahead of what many of the asic
foundries are using).  THis is possible because the SRAM FPGAs are
fabricated using the same process as memory.  No extra steps for flash etc.
Putting flash on the chip adds process steps and prevents the use of the
latest process.  You take a subtantial hit in speed, as well as a yield
hit.  The majority of FPGA users are not willing to take hits in these
departments for bitstream security.  Besides which, it is often possible
with little in the way of special tooling to subvert the security bits to
recover the data anyway.

One technique which is very secure that is mentioned here is the battery
retained power.  While that is really secure, I wouldn't use it in a
commercial product because of the possibility of losing the configuration.
Instead, if you are that concerned about security, put an OTP device in the
design as sort of a hardware dongle, and link its design tightly to the FPGA
so that the FPGA design will not operate without the OTP device.  The FPGA
bitstream by itself is no good if you need something else without a visible
bitstream to make it work.

That said, My personal feeling is the FPGA bitstream is more secure than
your typical microprocessor, other than those with internal flash (even
those can sometimes be sucessfully attacked by manipulating the program
voltages carefully or by forcing codes onto the external bus to snoop the
internals).  At least in the case of an FPGA, the FPGA won't work with a
partial bitstream, so it is quite a bit harder to reverse engineer from the
machine code.

In any event, I'll take the power, speed density and cost over a small
improvement in bitstream security any day.  In the cases where I need more
security and the customer is willing to pony up for it, an OTP part tightly
coupled to the FPGA is probably a workable solution, or in those rare cases
where it makes sense (military combat hardware loaded with mission
parameters, for example) the battery backup.

Also, for volume customers, you can get the chips marked with a custom logo
or totally unmarked so it is not immediately obvious that there is "xilinx
inside".  In that case, do the programming from a microprocessor, if
possible using a parallel interface (select map for virtex or one of the
parallel modes for 4K, spartan you're stuck with serial)  so you don't have
the tell-tale serial ROM telling the whole world that the unmarked part is
an FPGA.

Bottom line, is if they want your IP bad enough they can get it.  Of course
it might cost less to walk into the company and just hijack the design.

csjacobs@my-deja.com wrote:

> Why couldn't the FPGA companies put some flash rom internal to the fpga
> that can be written but never read...then just burn it once at the
> factory and you are done...and since it's flash, you still have the
> reprogramability option.
>
> Craig Jacobs
>
> In article <8eno4j$88j$1@nnrp1.deja.com>,
>   Greg Neff <gregneff@my-deja.com> wrote:
> > In article <390F5925.CC48CA69@raytheon.com>,
> >   Robert Posey <muddy@raytheon.com> wrote:
> > >
> > > You also had better be really, really sure that external power
> > transients can't
> > > cause the FPGA to dump its memory, or trigger its reset circuit.  I
> > wouldn't
> > > feel very good about using external power at all, but you will still
> > face
> > > ground spike problems.
> >
> > Correct.  With our microprocessor circuit, the code SRAM was write
> > protected unless it was connected to the production test fixture.
> > Also, there is no reset and/or reconfiguration circuit to worry about
> > in an SRAM.
> >
> > > In addition, you face potential problems with having
> > > the FPGA outputs being powered, while the rest of the circuit is not
> > powered.
> > > This could damage the other circuits.
> >
> > Again correct.  You could use a "power no good" signal to tri-state
> all
> > the FPGA outputs.
> >
> > I can see applications where this technique would be useful, outside
> of
> > mainstream production.  For example, if a small company is
> > demonstrating new technology to a potential licensee (or anyone else
> > for that matter), then proof-of-concept hardware could be built like
> > this, to prevent IP rip-off.
> >
> > --
> > Greg Neff
> > VP Engineering
> > *Microsym* Computers Inc.
> > greg@guesswhichwordgoeshere.com
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
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: 22276
Subject: [Q] Virtex FPGA : compile time error message
From: "" <leehg@hmec.co.kr>
Date: Thu, 04 May 2000 01:27:34 GMT
Links: << >>  << T >>  << A >>
Hi
I'm working on Xilinx Virtex XCV1000-6 BG560.
any solution or check point about the error message below ?

Error: Buffer allocation detected possible drivers on the same net as clock
input '/ver7-optimized/clk'.  (FPGA-buffermap-25)

this error reported at compile-optimization step.

'clk' is the main clock of my design.

'ver7' : i tried 7 times to solve this error T.T

any comment would guide me.
please help

gula@hitel.net



Article: 22277
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 03 May 2000 21:34:04 -0400
Links: << >>  << T >>  << A >>
This has some potential. The random number could be generated by running
a counter (or a LFSR) for a period of time controlled by the internal
configuration clock oscillator. This oscillator is relatively free
running and has a period that varies within a known range. There may be
some linking to the other clock in the circuit, but it should not
dominate the oscillator enough to fix the frequency between units. 

Then the rest of it becomes a matter of using the CPLD as a "dongle" to
protect the FPGA from being run without the "dongle". Or a uComp can be
used rather than a CPLD. It may take a little more work to program it,
but they can come in very small 8 pin packages. I am still looking for a
two pin package that works like the Dallas One-wire parts, but even
Dallas does not use anything smaller than 6 pins except for a two pin
chip scale package which is likely very hard to use. I don't know of any
logic devices that are as small (or as cheap?) as the smallest uComps. 

This would be pretty secure as a way to protect the FPGA load. Anyone
care to try it? To test this you would only need to program up the two
counters and see if they really generate random numbers. 

I expect to be working on the FPGAs for my board later this week. If I
don't hear from anyone else, I will see if I have time to give it a try. 



Rick Filipkiewicz wrote:
> 
> How about this as a mechanism:
> 
> o The FPGA is paired up with a small Flash CPLD.
> 
> o Both the FPGA & the CPLD implement the same algorithm that performs some
> mangling/encryption on a shortish bits stream 50-100 bits.
> 
> o The algorithm is configurable so that it is unique for each FPGA/CPLD pair.
> 
> o Once the FPGA has loaded up it generates a random number which it both sends
> to the CPLD & encrypts itself.
> 
> o The CPLD encrypts the same random number and sends the result back to the
> FPGA.
> 
> o Unless the internal & external encrypted values are the same the FPGA
> remains in reset.
> 
> This then reduces the problem to 3 things:
> 
> (1) Generating a random number in a way that is completely unrelated to the
> FPGA configuration.
> 
> (2) Finding an algorithm that can be configured for the FPGA by changing the
> definitions of some ROMs so that different bit streams can be generated by
> changing some ``init'' statements & not by rebuilding the whole device.
> 
> Of course the positions of these bits could be detected by comparing a few bit
> streams so some configuration ``noise'' would have to be introduced.
> 
> (3) Protecting the CPLD from attack.
> 
> I think that (1) is the most difficult. Maybe this is the thing that the FPGA
> vendors could add to their parts.


-- 

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: 22278
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 4 May 2000 01:52:21 GMT
Links: << >>  << T >>  << A >>

	The problem is creating a random number in an FPGA.  A
potentially better solution is as follows:

	The FPGA sends number N to CPLD

	CPLD responds with E(N,K).  FPGA also computes E(N,K)
internally (the key is secret, contained in the FPGA bitfile).

	Then the FPGA increments N, and repeats the procedure
indefinatly.



	To break it, one could do one of the following:

	Attack E to find K, reimplement CPLD.

	Extract K from the CPLD.

	Clone CPLD.

	Disassemble/reserse engineer the FPGA design enough to
determine the key.

	Disassemble/reverse engineer the FPGA design enough to remove
the encryption procedure.

	Record a sequence of challange/responses and just replay that,
which only works if the device is run for a limited period of time.

	All these attacks work (except for the replay attack) for the
other protocol (generate random N).



	It does not seem to raise the bar all that much over simple
copying.  I think, unless there is a built in mechanism for encrypted
bitfiles (see my posts on how it would work and what added silicon
would be required), the effective solutions are legal, not technical.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 22279
Subject: Re: How to Prevent theft of FPGA design
From: Ray Andraka <ray@fpga-guru.com>
Date: Thu, 04 May 2000 03:44:48 GMT
Links: << >>  << T >>  << A >>
You'll want to vigorously protect your random number generator algorithm.  Once the
algorithm is discovered it is a fairly simple matter to predict the stream and
duplicate the circuit.

Rickman wrote:

> This has some potential. The random number could be generated by running
> a counter (or a LFSR) for a period of time controlled by the internal
> configuration clock oscillator. This oscillator is relatively free
> running and has a period that varies within a known range. There may be
> some linking to the other clock in the circuit, but it should not
> dominate the oscillator enough to fix the frequency between units.
>
> Then the rest of it becomes a matter of using the CPLD as a "dongle" to
> protect the FPGA from being run without the "dongle". Or a uComp can be
> used rather than a CPLD. It may take a little more work to program it,
> but they can come in very small 8 pin packages. I am still looking for a
> two pin package that works like the Dallas One-wire parts, but even
> Dallas does not use anything smaller than 6 pins except for a two pin
> chip scale package which is likely very hard to use. I don't know of any
> logic devices that are as small (or as cheap?) as the smallest uComps.
>
> This would be pretty secure as a way to protect the FPGA load. Anyone
> care to try it? To test this you would only need to program up the two
> counters and see if they really generate random numbers.
>
> I expect to be working on the FPGAs for my board later this week. If I
> don't hear from anyone else, I will see if I have time to give it a try.
>
> Rick Filipkiewicz wrote:
> >
> > How about this as a mechanism:
> >
> > o The FPGA is paired up with a small Flash CPLD.
> >
> > o Both the FPGA & the CPLD implement the same algorithm that performs some
> > mangling/encryption on a shortish bits stream 50-100 bits.
> >
> > o The algorithm is configurable so that it is unique for each FPGA/CPLD pair.
> >
> > o Once the FPGA has loaded up it generates a random number which it both sends
> > to the CPLD & encrypts itself.
> >
> > o The CPLD encrypts the same random number and sends the result back to the
> > FPGA.
> >
> > o Unless the internal & external encrypted values are the same the FPGA
> > remains in reset.
> >
> > This then reduces the problem to 3 things:
> >
> > (1) Generating a random number in a way that is completely unrelated to the
> > FPGA configuration.
> >
> > (2) Finding an algorithm that can be configured for the FPGA by changing the
> > definitions of some ROMs so that different bit streams can be generated by
> > changing some ``init'' statements & not by rebuilding the whole device.
> >
> > Of course the positions of these bits could be detected by comparing a few bit
> > streams so some configuration ``noise'' would have to be introduced.
> >
> > (3) Protecting the CPLD from attack.
> >
> > I think that (1) is the most difficult. Maybe this is the thing that the FPGA
> > vendors could add to their parts.
>
> --
>
> 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

--
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: 22280
Subject: Re: How to Prevent theft of FPGA design
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 04 May 2000 16:46:49 +1200
Links: << >>  << T >>  << A >>
Nicholas C. Weaver wrote:
> 
>         The problem is creating a random number in an FPGA.  A
> potentially better solution is as follows:
> 
>         The FPGA sends number N to CPLD
> 
>         CPLD responds with E(N,K).  FPGA also computes E(N,K)
> internally (the key is secret, contained in the FPGA bitfile).
> 
>         Then the FPGA increments N, and repeats the procedure
> indefinatly.

 This is the scheme I called 'rolling code', where the 
stimulus changes.
 The NEXT N does not have to be N+1, and might be better chosen from
a ROM table.
 The key is that the function E() is as complex as practical, and
dummy signal pins could confuse this.

 Another level would be to ALSO bury a response in the CPLD, that
is never called, so is non traceable, via FPGA.
( or via FPGA sources, extracted by $$$$ :-)

 Presented in court, genuine devices would report 'Yes Genuine' 
tag, whilst the cloned one would be very silent...

 A device like the SOL24 ATF750, where ANY FF can be clocked from 
ANY other, with choice of Rise.Fall edges, and that has Async RST, 
Sync Preset has to be just about impossible to 'solve'.

> 
>         To break it, one could do one of the following:
> 
>         Attack E to find K, reimplement CPLD.
> 
>         Extract K from the CPLD.
> 
>         Clone CPLD.
> 
>         Disassemble/reserse engineer the FPGA design enough to
> determine the key.
> 
>         Disassemble/reverse engineer the FPGA design enough to remove
> the encryption procedure.

 This is why the CPLD should also pass/scramble the bitstream 
- just makes this path harder, by making getting a
known clean bitstream much more than turning on a programmer.

 - jg

Article: 22281
Subject: Re: Why are there no "cheap" FPGAs?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 04 May 2000 16:49:35 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Well, this newsgroup is supposed to be technical, not commercial.
> But (the other) Peter asked the question, and here is the answer:
> 
> As of May 2000 you can buy an XC2S15 in quantity 1 through 24 for $ 7.10
> :
> 
> You get 96 CLBs, i.e 384 LUT / flip-flop combinations ( Logic Cells )
> plus four dual-ported BlockRAMs, each 4096 bits
> plus four DLLs
> plus 60 I/Os with lots of options.

 What package ?
-jg

Article: 22282
Subject: Re: How to Prevent theft of FPGA design
From: murray@pa.dec.com (Hal Murray)
Date: 4 May 2000 05:11:39 GMT
Links: << >>  << T >>  << A >>

How much would people be willing to pay for a secure way to load
an FPGA?  What sort of volumes are interesting in this market area?
I'd guess it can't be too big or the infringing products would be
easy to find on the open market where legal action would work yet
still big enough to be worth the effort to steal the design.

One approach is to make an ASIC.  That has the obvious hard
to reprogram problems.

Does Xilinx offer the hardwire mode for the modern chips?

How many vendors make ASICs from a Xilinx bit stream or perhaps
the unrouted design.  Tayloring the front end of an ASIC process
to this type of input seems like a good business opportunity if
the risk of theft is important.



How complicated or rather expensive is laser programming or
fusable links?  Is reading them off a packaged chip expensive
enough to prevent reverse-engineering in this market area?

I'm thinking of some extra logic in the corner where a per-vendor
crypto key could be blasted in.  This assumes that the FTGA vendor
would only sell more of the chip woth that key to the legitimate owner.

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

Article: 22283
Subject: Init/ line - CRC error ???
From: "Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr>
Date: Thu, 04 May 2000 07:52:43 +0200
Links: << >>  << T >>  << A >>
Hello,

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. All bits are correctly sended and
the most strange thing is that the CRC error occurs after N bits, with
N no constant ! (for example 90, 427, 123, 1515...)

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.

But if the FPGA is not correctly powered, why it accepts bit during
configuration process and put DOUT correctly ?? %-(

Stange case.... if anyone has an idea ?


Thanks,

Sebastien,

Article: 22284
Subject: Re: Init/ line - CRC error ???
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Thu, 04 May 2000 09:23:31 +0200
Links: << >>  << T >>  << A >>
> Stange case.... if anyone has an idea ?
Mhm, an idea: 
check if you are sending the bits in the right sequence
with respect to the bytes they are from. 
Generate an raw bits file (bitgen option -b) and 
check. 
Just an idea - as you were asking. 
Andreas

-----------------------------------------------------------------
                        Andreas C. Doering
                        Medizinische Universitaet zu Luebeck
                        Institut fuer Technische Informatik
		        Email: doering@iti.mu-luebeck.de
                        Home: http://www.iti.mu-luebeck.de/~doering 
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 22285
Subject: Re: Init/ line - CRC error ???
From: Nicolas Matringe <nicolas@dotcom.fr>
Date: Thu, 04 May 2000 09:56:40 +0200
Links: << >>  << T >>  << A >>
"Sebastien Favard (Gordh)" a crit :

> 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.
> 
> But if the FPGA is not correctly powered, why it accepts bit during
> configuration process and put DOUT correctly ?? %-(
> 
> Stange case.... if anyone has an idea ?

Hi
You could encounter some clock problems. I had something rather similar
when trying to program a Virtex through the JTAG interface.
When implementing the design in Foundation, you must say that the
start-up clock is "User Clock", not "CCLK" (in the
"Synthesis/Implementation settings" box, click on the "Options" button.
In the box that appears, click on the Configuration "Edit Options..."
button. Choose the "Startup" window and select the startup clock)


Nicolas MATRINGE           DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
Fax 00 33 1 46 67 51 01    FRANCE
Article: 22286
Subject: Re: Init/ line - CRC error ???
From: "Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr>
Date: Thu, 04 May 2000 10:15:21 +0200
Links: << >>  << T >>  << A >>
>
> You could encounter some clock problems. I had something rather similar
> when trying to program a Virtex through the JTAG interface.
> When implementing the design in Foundation, you must say that the
> start-up clock is "User Clock", not "CCLK" (in the
> "Synthesis/Implementation settings" box, click on the "Options" button.
> In the box that appears, click on the Configuration "Edit Options..."
> button. Choose the "Startup" window and select the startup clock)
>

I'll try this solution. But I think that's really suspicious because the
mode by hardware default is the slave serial mode and the default
constraint in the bitstream generator is the master: CCLK and not
UserCCLK ! Very strange but I could try your idea, it's a very good idea :)

Thanks,


Article: 22287
Subject: Re: Init/ line - CRC error ???
From: "Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr>
Date: Thu, 04 May 2000 10:17:52 +0200
Links: << >>  << T >>  << A >>
> Mhm, an idea:
> check if you are sending the bits in the right sequence
> with respect to the bytes they are from.
> Generate an raw bits file (bitgen option -b) and
> check.
> Just an idea - as you were asking.
> Andreas

I have already check all the bitstream file with a home program. I check
the header, all start bytes, preambule code, fill bits and so one... In
fact all but not the CRC bits !
So I think  really that my bitstream is correctly.

Thanks for your attention,


Article: 22288
Subject: Re: [Q] Virtex FPGA : compile time error message
From: "JWKIM" <edward8@hanmail.net>
Date: Thu, 4 May 2000 17:56:27 +0900
Links: << >>  << T >>  << A >>
Hello,

I'm JW, Kim , Xilinx Disti FAE

Please, give me a mail for this  message.

Thanks,

JW

jwkim@seodu.co.kr

 <leehg@hmec.co.kr>() Ʒ ޽
news:am4Q4.561$Qf.10918@news2.bora.net ԽϿϴ.
> Hi
> I'm working on Xilinx Virtex XCV1000-6 BG560.
> any solution or check point about the error message below ?
>
> Error: Buffer allocation detected possible drivers on the same net as
clock
> input '/ver7-optimized/clk'.  (FPGA-buffermap-25)
>
> this error reported at compile-optimization step.
>
> 'clk' is the main clock of my design.
>
> 'ver7' : i tried 7 times to solve this error T.T
>
> any comment would guide me.
> please help
>
> gula@hitel.net
>
>
>


Article: 22289
Subject: Re: Init/ line - CRC error ???
From: "Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr>
Date: Thu, 04 May 2000 11:50:57 +0200
Links: << >>  << T >>  << A >>
> You could encounter some clock problems. I had something rather similar
> when trying to program a Virtex through the JTAG interface.
> When implementing the design in Foundation, you must say that the
> start-up clock is "User Clock", not "CCLK" (in the
> "Synthesis/Implementation settings" box, click on the "Options" button.
> In the box that appears, click on the Configuration "Edit Options..."
> button. Choose the "Startup" window and select the startup clock)
>

Yes I have try this but the synthesis tools don't  want generate the
bitstream file because my design don't support a external Oscilator wire at
the FPGA pin... :(

I have certainly not understand the difference between UserClk and Clk.

If I use a slave serial mode, I drive the CCLK pin by a controler logic for
example. So, the start-up clock is my external clock, no ? If I must use a
"User Clock", how must I modify my design to support it and enable
synthesis tool bitstream generation ?
My bitgen help  is :

"OscClk:  Determines whether in XC5200 oscillator is driven by the internal
16MHz clock (CCLK) or by a user clock (User Clk). If you specify UserClk,
the clock must be connected to the OSC.CK pin of the device's OSC
component."

If I use bitgen :

>> bitgen -w -g OscCLK:UserCLK -a fpga.ncd
>>
>>ERROR:x52bs:26 - There must be a OSC component with a signal on the C pin
when
>>   OscClk is UserClk.

??? I don't undertand this message because I DRIVE the CCLK pin of FPGA, so
how it ca say that ?


Thanksssssssssssssss


Sebastien,


Article: 22290
Subject: Re: Init/ line - CRC error ???
From: Nicolas Matringe <nicolas@dotcom.fr>
Date: Thu, 04 May 2000 13:33:15 +0200
Links: << >>  << T >>  << A >>
"Sebastien Favard (Gordh)" a crit :

> "OscClk:  Determines whether in XC5200 oscillator is driven by the
> internal 16MHz clock (CCLK) or by a user clock (User Clk). If you
> specify UserClk, the clock must be connected to the OSC.CK pin of the
> device's OSC component."
> 
> If I use bitgen :
> 
> >> bitgen -w -g OscCLK:UserCLK -a fpga.ncd
> >>
> >>ERROR:x52bs:26 - There must be a OSC component with a signal on the
> >>C pin when OscClk is UserClk.
> 
> ??? I don't undertand this message because I DRIVE the CCLK pin of
> FPGA, so how it ca say that ?

I've never used an XC5200 part (the parts files are not installed on my
computer) so I can't say much about that. For XC4000 or Spartan, what I
said seems consistent.

Nicolas MATRINGE           DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
Fax 00 33 1 46 67 51 01    FRANCE
Article: 22291
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 04 May 2000 07:42:02 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> How much would people be willing to pay for a secure way to load
> an FPGA?  What sort of volumes are interesting in this market area?
> I'd guess it can't be too big or the infringing products would be
> easy to find on the open market where legal action would work yet
> still big enough to be worth the effort to steal the design.
> 
> One approach is to make an ASIC.  That has the obvious hard
> to reprogram problems.
> 
> Does Xilinx offer the hardwire mode for the modern chips?
> 
> How many vendors make ASICs from a Xilinx bit stream or perhaps
> the unrouted design.  Tayloring the front end of an ASIC process
> to this type of input seems like a good business opportunity if
> the risk of theft is important.
> 
> How complicated or rather expensive is laser programming or
> fusable links?  Is reading them off a packaged chip expensive
> enough to prevent reverse-engineering in this market area?
> 
> I'm thinking of some extra logic in the corner where a per-vendor
> crypto key could be blasted in.  This assumes that the FTGA vendor
> would only sell more of the chip woth that key to the legitimate owner.
> 
> --
> These are my opinions, not necessarily my employers.

I looked into the Xilinx Hardwire devices once. I believe I asked about
several different sizes of smaller 4000 series parts. The prices and
minimum quantities varied, but the one constant was a minimum order (for
the first year) of $100K. So if you have a volume that is not going to
be overly small a Hardwire approach would be viable.


-- 

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: 22292
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 04 May 2000 08:00:06 -0400
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> Nicholas C. Weaver wrote:
> >
> >         The problem is creating a random number in an FPGA.  A
> > potentially better solution is as follows:
> >
> >         The FPGA sends number N to CPLD
> >
> >         CPLD responds with E(N,K).  FPGA also computes E(N,K)
> > internally (the key is secret, contained in the FPGA bitfile).
> >
> >         Then the FPGA increments N, and repeats the procedure
> > indefinatly.
> 
>  This is the scheme I called 'rolling code', where the
> stimulus changes.
>  The NEXT N does not have to be N+1, and might be better chosen from
> a ROM table.
>  The key is that the function E() is as complex as practical, and
> dummy signal pins could confuse this.
> 
>  Another level would be to ALSO bury a response in the CPLD, that
> is never called, so is non traceable, via FPGA.
> ( or via FPGA sources, extracted by $$$$ :-)
> 
>  Presented in court, genuine devices would report 'Yes Genuine'
> tag, whilst the cloned one would be very silent...
> 
>  A device like the SOL24 ATF750, where ANY FF can be clocked from
> ANY other, with choice of Rise.Fall edges, and that has Async RST,
> Sync Preset has to be just about impossible to 'solve'.
> 
> >
> >         To break it, one could do one of the following:
> >
> >         Attack E to find K, reimplement CPLD.
> >
> >         Extract K from the CPLD.
> >
> >         Clone CPLD.
> >
> >         Disassemble/reserse engineer the FPGA design enough to
> > determine the key.
> >
> >         Disassemble/reverse engineer the FPGA design enough to remove
> > the encryption procedure.
> 
>  This is why the CPLD should also pass/scramble the bitstream
> - just makes this path harder, by making getting a
> known clean bitstream much more than turning on a programmer.
> 
>  - jg

First I don't see any advantage to encrypting the bitstream unless you
use a random key which has to be burned into the FPGA. We have already
explained why the FPGA vendors don't want to/won't build this into the
chips. The cost is high in several ways. 

You guys are thinking way too hard about the encryption. If you use a 48
bit key "K", a 48 bit number "N" and a 48 bit response "E" and use an 8
bit microP (smaller than a CPLD) to implement the algorithm (keeping in
mind that you have to duplicate it in the FPGA) you should be able to
make this hard enough to break that your design is protected from most
anyone other than NSA. 

We are not trying to protect state secrets. We are just trying to fool a
PC board house that wants to clone our design. Not many outfits would
have the expertise to break an encryption related design. And remember,
it is not at all trivial to disassemble the bitstream of an FPGA.
Another FPGA vendor may have done this, but not many board houses would
have the technology. This is exactly like the technology they use in the
more recent dongles for software protection. How many of those have been
cracked other than attacking the software in the PC (FPGA design in this
case which is harder). 

The more I think about this, the more I like it. If it weren't for the
logistical problems of maintaining a list of unique serial numbers for
production, I would think very hard about implementing this. 

So my next DSP boards may have this feature built in. But this will be
for my customer's use only. I give away my source code and FPGA designs
so that anyone can do anything with them while using my boards. They are
only protected by the honesty of my customers.  :-)


-- 

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: 22293
Subject: Vital glitch
From: Jamil Khatib <jamilkhatib75@yahoo.com>
Date: Thu, 04 May 2000 14:07:16 +0200
Links: << >>  << T >>  << A >>
Hi,
I got a warining during simultion about vital glitch on an internal
signal of the low level structure. but I do not get any glitch on my
output signals, Is it an important warining that I should take care of,
or is it going to vanish on the real hardware (CPLD)

Anyhow what is the meaning if the vital glitch?


Thanks
Jamil Khatib

Article: 22294
Subject: Re: Init/ line - CRC error ???
From: fliptron@netcom.com (Philip Freidin)
Date: 4 May 2000 12:36:23 GMT
Links: << >>  << T >>  << A >>
In article <3911102B.47E7C045@utc.fr>,
Sebastien Favard (Gordh) <Sebastien.Favard@utc.fr> wrote:
>Hello,
>
>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.


Here are my guesses:
	Is the config clock running before the configuration starts,
	and loads junk before the header?

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

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

Philip Freidin



> All bits are correctly sended and
>the most strange thing is that the CRC error occurs after N bits, with
>N no constant ! (for example 90, 427, 123, 1515...)
>
>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?


>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?


>
>Stange case.... if anyone has an idea ?
>
>
>Thanks,
>
>Sebastien,
>


Article: 22295
Subject: [BitGen] - pb option UserClk
From: "Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr>
Date: Thu, 04 May 2000 15:20:27 +0200
Links: << >>  << T >>  << A >>
Hi,

When I use the BitGen program with argument StartupClk (on
XC4000/Spartan)  or the similar OscClk (on XC5200) an error appeared:

"ERROR:x4kbs:35 - There must be a STARTUP component with a signal on the
CLK pin
   when StartupClk is UserClk."

Why I have this error when I must create a bitstream for a slave serial
mode ?

Sebastien,



Article: 22296
Subject: [Ann] Lowest Cost FPGA Proto Kits SALE
From: "Tony Burch" <tony@BurchED.com.au>
Date: Thu, 4 May 2000 23:41:17 +1000
Links: << >>  << T >>  << A >>

Announcing new, lowest cost, no fuss
FPGA prototyping kits for FPGA designers,
students and enthusiasts.

These are the lowest cost, easiest to use
FPGA prototyping kits on the market!

Your favourite FPGA vendor is supported -
Xilinx, Altera, Atmel, Lucent and Actel.


Strength in simplicity:
- FPGA (5K to 10K gates) on a board
- Easy connection - FPGA pin numbers
   labelled on both sides of the board
- Prototyping area - add what you want
- Canned crystal oscillator module plus
   other components included
- Configuration download pod board included
- PC parallel port interface capability
- Low cost
- Easy!

########################################
OPENING SALE - 20% off the normal price!
########################################

...An excellent time to grab a bunch of
these for your lab, or maybe one for your
student project.
Sale on for only a short time.

Pictures, specs, resources and online shop at
Burch Electronic Designs:
www.BurchED.com.au




P.S.

Lots and lots of uses. Here's some:
- Prototype a module of your design for
   demonstration purposes, or to increase
   confidence in the module for a final
   target design.
- Build them into one-off systems or special
   purpose test equipment.
- Have a couple on hand for when you need to try
   out that circuit quickly (generally happens
   at midnight :) ).
- Student projects (digital logic design, computer
   architecture, DSP, telecomms etc. etc.).



Article: 22297
Subject: How to connect JTAG to XCS10pc84 FPGA device
From: e97bjli@thn.htu.se
Date: Thu, 04 May 2000 14:24:04 GMT
Links: << >>  << T >>  << A >>
Hi.

I have a problem with my FPGA device (Spartan XCS10 PC84)

When I download my program to the device via JTAG (Parallel cable III),
The programming tool write "programming successfully".

But when I connect my oscilloscop to the pins of the device, all pins
except ground are high ( '1' ).

I dont know what to do.

ALL Vcc are connected to ground via 0.1 uF capacitor.

INIT is connected to Vcc via 4700 ohm resistor.

Mode is unconnected. (because we use an external oscillator)

TCK,TDI,TMS,TDO,Vcc,GND, and the external clock are connected from the
JTAG according to the following:
TCK to pin 16
TDI to pin 15
TMS to pin 17
TDO to pin 75
Vcc to pin 2, 11, 22, 33, 42, 54, 63, 74
GND to pin 1, 12, 21, 31, 43, 52, 64, 76
external clock to pin 35.

My code at the bottum of the mail:

Thankful for help


Bjrn Lindegren


library IEEE;
use IEEE.std_logic_1164.all;

entity sampel is
    port (
        	clk,reset: in STD_LOGIC;
        	input: in STD_LOGIC_VECTOR (7 downto 0);
        	output: out STD_LOGIC_VECTOR (7 downto 0);
        	Q2                             :  out   STD_ULOGIC;
      	Q3                             :  out   STD_ULOGIC;
      	Q1Q4                           :  out   STD_ULOGIC;
      	DONEIN                         :  out   STD_ULOGIC;
      	--GSR                            :  in    STD_ULOGIC;
      	GTS_IN                            :  in    STD_ULOGIC;
        	cs: out STD_LOGIC
        	--int: inout STD_LOGIC
    		);
end sampel;

architecture sampel_arch of sampel is

 signal sampelcounter: integer range 0 to 15;

 component STARTUP
   port(
      Q2                             :  out   STD_ULOGIC := 'H';
      Q3                             :  out   STD_ULOGIC := 'H';
      Q1Q4                           :  out   STD_ULOGIC := 'H';
      DONEIN                         :  out   STD_ULOGIC := 'H';
      GSR                            :  in    STD_ULOGIC;
      GTS                            :  in    STD_ULOGIC;
      CLK                            :  in    STD_ULOGIC);
end component;

begin

  U1: STARTUP PORT MAP( GSR=>reset,clk=>CLK,Q2=>Q2, Q3=>Q3, Q1Q4=>Q1Q4,
DONEIN=>DONEIN,GTS=>GTS_IN);

  sampelprocess: process(reset,clk)

  begin

	if reset ='1' then

		output<=(others=>'0');

		cs<='1';

  	elsif clk='1' and clk'event then

  		if sampelcounter=0 or sampelcounter=5 then

  			cs<='0';

  		elsif sampelcounter=10 then

			cs<='1';
  			output<=input;


  		end if;

  	end if;
  end process sampelprocess;

sampelcount: process(reset,clk)

  begin

	if reset ='1' then

		sampelcounter<=0;

  	elsif clk='1' and clk'event then

  		sampelcounter<=sampelcounter+1;

 		if sampelcounter=11 then

  			sampelcounter<=0;

  		end if;
  	end if;

  end process sampelcount;

end sampel_arch;






Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22298
Subject: Re: How to Prevent theft of FPGA design
From: David Kessner <davidk@free-ip.com>
Date: Thu, 04 May 2000 08:55:51 -0600
Links: << >>  << T >>  << A >>
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

Article: 22299
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 4 May 2000 15:35:58 GMT
Links: << >>  << T >>  << A >>
In article <391100B9.1DF1@designtools.co.nz>,
Jim Granville  <jim.granville@designtools.co.nz> wrote:
>Nicholas C. Weaver wrote:

> This is the scheme I called 'rolling code', where the 
>stimulus changes.
> The NEXT N does not have to be N+1, and might be better chosen from
>a ROM table.
> The key is that the function E() is as complex as practical, and
>dummy signal pins could confuse this.

	I'm assuming that E() is some government strength encryption.
Thus N = N + 1 is fine, no easier or harder than anything else.  E can
be completely unbreakable, and as I mentioned, still has this being
not very effective.

> Presented in court, genuine devices would report 'Yes Genuine' 
>tag, whilst the cloned one would be very silent...

	If you jsut want a record in court, use some information
hiding techniques to hide a serial number deep in the configuration,
using, say, Jbits.  This would allow you to specify the specific
device that was cloned.

> This is why the CPLD should also pass/scramble the bitstream 
>- just makes this path harder, by making getting a
>known clean bitstream much more than turning on a programmer.

	Not really that much harder, either.  Just put a capture on
the output of the configuration pin, gives you a nice clean bitstream.

	To my mind, the solution is as follows, either A), convince
the vendors to include bitstream encryption with an on-deviced stored
key/serial #.  B)  Always on, no bitstream source or C), don't try.
Instead, just embed tracking material in the bitfiles and let your
lawyer take care of it.

	These other techniques aren't that much harder over just
copying the bitfile.  They can't offer that big a hurdle, because the
bitstream going into the FPGA at the FPGA's pin is, and has to be, in
the clear, and there has to be a secret in the FPGA for such protocols
to work.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



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
2017JanFebMarApr2017

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