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 45825

Article: 45825
Subject: Re: parameterized / variable ucf
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 06 Aug 2002 23:48:21 +0100
Links: << >>  << T >>  << A >>


Nahum Barnea wrote:

> Hi.
> Is there a way to define a variable / parameter in the xilinx ucf file ?
>
> I want to P&R to several design parameters.
> My clock frequency determine also my I/O setup requirement etc..
>
> Thus I am looking for a way to easily switch from one ucf to another
> by changing 1 parameter at most.
>
> Is it possible ?
>
> ThankX,
> NAHUM.

Unfortunately I think you're out of luck since Xilinx, alone of all the EDA
vendors, has never implemented Tcl scripting for things like UCF. Maybe now
they have bitten the bullet and decided that Linux is for real and not just
a geek's toybox Tcl might happen ... meanwhile what I've done is to use a
simple Perl script to generate parametrisable UCFs and embed this as part of
a makefile.


Article: 45826
Subject: Programming bits reverse engineering
From: prashantj@usa.net (Prashant)
Date: 6 Aug 2002 16:04:05 -0700
Links: << >>  << T >>  << A >>
Hi,

I would like to give someone the programming bits for an FPGA for my
design. Is there anyway the programming bits could be used to reverse
engineer to my design ? What is the safest way to let someone use your
design without them being able to figure out your FPGA design ?

Thanks,
Prashant

Article: 45827
Subject: Re: Qn: Low Level Design
From: Neil Franklin <neil@franklin.ch.remove>
Date: 07 Aug 2002 01:29:37 +0200
Links: << >>  << T >>  << A >>
szamani@ce.aku.ac.ir (Morteza) writes:

> It may be useful to design at the very low level: Setting programmable
> switches, MUXes select lines, etc, individually. (useful for designing
> compact and fast library components, for example).
>
> Is there any straightforward way (e.g. schematic/text editors) to do
> that?

If you are targeting Virtex (or an Spartan-II with has an equal-size
Virtex) then the JBits tool from Xilinx gives you such low level
access from an Java text file.

You can get it free by mailing jbits@xilinx.com


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer
- Make your code truely free: put it into the public domain

Article: 45828
Subject: Re: Programming bits reverse engineering
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 06 Aug 2002 16:32:25 -0700
Links: << >>  << T >>  << A >>
Prashant,

Use Triple DES config feature with three keys in Virtex II or Virtex II
Pro.  Then the bits don't help you at all.

They can't even copy the bitstream and stamp out copies because the keys
are hidden in the part, and can not be read out.

Alternately, fill up an entire 2V6000 with your design.  It would takes
more than ten years of engineering to understand it.  By then, you would
be selling your new improved version.

They would never be able to recover the original verilog or VHDL.

If I gave you Microsoft Windows bits, could you figure out what Microsoft
is doing?

Given that you can place a Micro-Blaze uP in your design, you could have
the part call home, and get its authorization to perform its function if
and only if the customer was a valid one.

Get creative.

Austin

Prashant wrote:

> Hi,
>
> I would like to give someone the programming bits for an FPGA for my
> design. Is there anyway the programming bits could be used to reverse
> engineer to my design ? What is the safest way to let someone use your
> design without them being able to figure out your FPGA design ?
>
> Thanks,
> Prashant


Article: 45829
Subject: Xilinx TIG
From: chen.songwei@mail.zte.com.cn (Apollo)
Date: 6 Aug 2002 18:13:01 -0700
Links: << >>  << T >>  << A >>
I think the TIG of xilinx constrain  is a little simlar
"Set_False_Path" of Design Compiler .For example,i have 3
clock(clk1/clk2/clk3) in my project.
Do i need add the following constrain  so that both P&R and Timing
analyzer of xilinx ISE don't care them like Synopsys DC?
***********************************
TIMESPEC "TS_clk1" = FROM "clk1" TO "clk2"  TIG;
TIMESPEC "TS_Clk2" = FROM "clk2" TO "clk3"  TIG;
TIMESPEC "TS_clk1" = FROM "clk1" TO "clk3"  TIG;
TIMESPEC "clk3" = FROM "clk1" TO "MDC_c_c"  TIG;
TIMESPEC "clk3" = FROM "clk2" TO "MDC_c_c"  TIG;

Article: 45830
Subject: Lattice GAL22V10 and everything it entails . . . !
From: leotran@att.net (Loi Tran)
Date: Wed, 07 Aug 2002 01:21:19 GMT
Links: << >>  << T >>  << A >>
I've been trying to get a simple GAL22v10 programmed so that I can get my 
little personal project going.  I grabbed the old PALASM software off the net 
get a JEDEC file from it just fine.  I buy some 22v10 except they're not GALs. 
They're PALs.  I have an EMP10 (needham's) programmer, but it won't take PAL 
parts.  Only Lattice GAL parts.  I try anyway.  The programming software tells 
me that the number of fuses in the file doesn't match the number of fuses in 
the device.  Silly me!  I thought 22V10 parts were all the same.  It tells me 
that there are 5892 fuses in the GAL22V10 I specified in software and that the 
loaded JEDEC file only indicates 5828 fuses.  Then it gives me an option to 
fill in the last 64 fuse map addresses with 0. So here are my questions.


1)  Can I just tell it to fill in the remaining 64 and program a Lattice 
GAL22v10 just fine?

2)  The palasm software spits out JEDEC files for the old PAL22V10.  Can I use 
it to program a "modern" GAL part?  Or do I have to juggle some more to get 
the proper software?  If not, can anyone direct me to where I can find free or 
relatively cheapish software that will put out modern GAL jedec files?

3)  Here's the other problem.  The EMP10 programmer gives me 2 options in the 
GAL selection.  One is GAL22V10 and the other is GAL22V10B (note the B 
suffix).  I searched high and low and I can't find the GAL22V10B.  It's been 
obseleted.  All they sell are D suffix parts.  What's the difference?

If anyone can answer these questions, please answer.  Don't be shy.  You won't 
get much for your altruism, but you'll get a warm fuzzy for doing it.  I hope.

Thanks,

LT


Article: 45831
Subject: Looking for behavioral Xilinx RAM model
From: "Scott L. Baker" <scd@teleport.com>
Date: Wed, 07 Aug 2002 03:24:54 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm looking for a behavioral model for a Xilinx RAMB4_S8.

I wrote my own model, but I am seeing differences
between my simulation model and the synthesized FPGA
behavior.  Does anyone have a known-good model or
know where I can find one.

Thanks in Advance,
Scott Baker





Article: 45832
Subject: Re: Is it necessary to instantiate IPAD, OPAD, IBUF, OBUF...?
From: assaf_sarfati@yahoo.com (Assaf Sarfati)
Date: 6 Aug 2002 22:03:27 -0700
Links: << >>  << T >>  << A >>
"Daryl" <e-engineer@eastday.com> wrote in message news:<3d4f767d@shknews01>...
> Hi, FPGA gurus,
> 
>   My question is "Is it necessary to instantiate the IPAD, OPAD, IBUF, OBUF,
> IBUFG, ... in my HDL code of top-level ?"
> 
> ----- if NO,
> when I have to insert BUFG or/and BUFT explicitly, how to code to insert
> what I want solely?
-------- SNIP ----------

In Synplify, you don't have to instantiate I/O pads or BUFGs. It will
add I/O pads to all top-level ports and even create Registered I/O
pads by itself. It also recognizes clock nets and adds BUFGs
automatically.

Actually, the big problem is preventing Synplify from doing it if you
want better control over your I/O pins (for example, we wanted to use
both the registered and unregistered inputs of the same input pad -
had a terrible time convincing Synplify that that's what we REALLY
wanted).

I haven't used XST or Exemplar for some time, but I am sure that they
behave pretty much the same.

  Regards
  Assaf Sarfati

Article: 45833
Subject: xilinx: map -k
From: nahum_barnea@yahoo.com (Nahum Barnea)
Date: 6 Aug 2002 23:14:02 -0700
Links: << >>  << T >>  << A >>
Hi.
I would like to hear about the experience of xilinx users that used
"-k" flag in the "map" program.

I did'nt see a way to control this flag from the GUI, the help says 


   -k 4|5|6|7|8      Function size for covering combinational logic. 
If -k
                       is not specified, the default is -k 4.  This
gives the
                       best balance of runtime to quality of results. 
Using
                       larger values of -k can give superior results
at the
                       expense of  runtime.

And I wishto know did it realy helped virtex2 users or did it just
consume more time ?

ThankX,
NAHUM

Article: 45834
Subject: Re: Is it necessary to instantiate IPAD, OPAD, IBUF, OBUF...?
From: "Daryl" <e-engineer@eastday.com>
Date: Wed, 7 Aug 2002 14:35:40 +0800
Links: << >>  << T >>  << A >>
Hi, Assaf and others,

    Thanks for your issues, Assaf.
    Now I got your idea, I think I'd better instantiate all of IBUFs and
OBUFs explicitly in my top-level code, as well as IBUFGP and FDs, but NO
PADs.
    Right?
    Now, my puzzle turned to whether I should/had better add IBUFs or add
IFDs in on certain conditions. If I want to use OFD to save DFFs in interval
logic and reduce output delay, I have to code asynchronous outputs in
submodules? Is there a method for me to force a process or "always@.." block
to use OFD as DFF?

Best Regards,

Daryl



Article: 45835
Subject: Re: Looking for behavioral Xilinx RAM model
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 07 Aug 2002 07:50:44 GMT
Links: << >>  << T >>  << A >>
On Wed, 07 Aug 2002 03:24:54 GMT, "Scott L. Baker" <scd@teleport.com>
wrote:

>Hi,
>
>I'm looking for a behavioral model for a Xilinx RAMB4_S8.
>
>I wrote my own model, but I am seeing differences
>between my simulation model and the synthesized FPGA
>behavior.  Does anyone have a known-good model or
>know where I can find one.

There is a model in the unisim library.

The source for the unisim library is in your xilinx software
installation.

This thread contains instructions on how to compile it:
http://groups.google.com/groups?threadm=7aa9e136.0201100122.44039324%40posting.google.com

Regards,
Allan.

Article: 45836
Subject: Re: AES (rijndael) Ip core
From: "Guerre" <deton8@aol.com>
Date: Wed, 7 Aug 2002 08:34:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
"kkps" <kkps@rapid5.com> wrote in message
news:c6efc5c9.0208050742.187cb4de@posting.google.com...
> Hi all,
>
> I need to choose an AES (rijndael) IP core to use in Xilinx VirtexE.
> There is a wide perplexing selection of core providers on the
> internet. Does anybody have any recommendation regarding who is the
> best (performance & cos

I assume you already knew this, but if not, the NSA has helpfully
implemented AES in VHDL for you.  Everybody says these cores are sub-optimal
in efficiency, but hey, they work, and they are free and un-copyrighted.  If
nothing else, you can leech the test benches.

http://csrc.nist.gov/encryption/aes/round2/r2anlsys.htm#NSA

If there are any other open source AES cores in VHDL or Verilog, I'd
appreciate pointers to them here.

Guerre



Article: 45837
Subject: Re: Is it necessary to instantiate IPAD, OPAD, IBUF, OBUF...?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 07 Aug 2002 10:17:22 +0100
Links: << >>  << T >>  << A >>


Daryl wrote:

> Hi, Assaf and others,
>
>     Thanks for your issues, Assaf.
>     Now I got your idea, I think I'd better instantiate all of IBUFs and
> OBUFs explicitly in my top-level code, as well as IBUFGP and FDs, but NO
> PADs.
>     Right?

I think Assaf was saying the opposite, at least for Synplify.

>
>     Now, my puzzle turned to whether I should/had better add IBUFs or add
> IFDs in on certain conditions. If I want to use OFD to save DFFs in interval
> logic and reduce output delay, I have to code asynchronous outputs in
> submodules? Is there a method for me to force a process or "always@.." block
> to use OFD as DFF?
>

You don't have to do this. just synthesise as normal to get one of the standard
FF types.  Then use the -pr (= pack registers) flag to the Xilinx MAP program to
tell it to put FFs into the IOBs if possible. You need to obey a few rules for
this to work (applies to Virtex, XC4K is a bit different).

o No logic before an InFF or after an OutFF, not even an inversion.

o If there's both an InFF and an OutFF then they must share the same clock
(obvious for global clocks).

o If there's both an InFF and an OutFF they musy have the same initialisation
signal but the 2 FFs can be configured to use it differently. This is not so
obvious if (i) Synplify has e.g. fanned out a reset signal used by a 64-bit
bitdir registered bus (ii) Synplify uses its trick of regarding sync set/reset
as a way of absorbing logic, (iii) one direction has an init but the other
doesn't.

One final thing - by default the inferred IO pads are LVTTL. If you want
something different then you can use the Synplify xc_padtype attribute either in
the source on in a separate .sdc file.

Note that contrary to Assaf I've not had any problems getting Synplify to
synthesise correctly in the case (e.g. PCI) where I want both the direct and
registered inputs from an IO pad.


Article: 45838
Subject: Re: Programming bits reverse engineering
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 07 Aug 2002 10:26:30 +0100
Links: << >>  << T >>  << A >>


Austin Lesea wrote:

> Prashant,
>
> Use Triple DES config feature with three keys in Virtex II or Virtex II
> Pro.  Then the bits don't help you at all.
>

One thing I noticed is the the V-2 3DES keys are 64-bit but IIRC 3DES allows
up to 112-bit. Is this down to the US cryptographic export restrictions ? Or
is there some way of chaining together the 2 sets of 3 keys ?


Article: 45839
Subject: Re: xilinx: map -k
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 07 Aug 2002 10:33:55 +0100
Links: << >>  << T >>  << A >>


Nahum Barnea wrote:

> Hi.
> I would like to hear about the experience of xilinx users that used
> "-k" flag in the "map" program.
>
> I did'nt see a way to control this flag from the GUI, the help says
>
>    -k 4|5|6|7|8      Function size for covering combinational logic.
> If -k
>                        is not specified, the default is -k 4.  This
> gives the
>                        best balance of runtime to quality of results.
> Using
>                        larger values of -k can give superior results
> at the
>                        expense of  runtime.
>
> And I wishto know did it realy helped virtex2 users or did it just
> consume more time ?
>
> ThankX,
> NAHUM

Basically I think this is for designs where the input is a bunch of logic
equations (e.g. coming from compiled schematics) and MAP has to do the
work of allocating the logic to LUTs. For designs synthesised from HDLs
this has already been done by the synth tool so -k most likely won't gain
very much. In fact the Synplfy documentation recommends *not* using it
since it will make the overall QOR worse, not better.



Article: 45840
Subject: Re: xilinx: map -k
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 07 Aug 2002 10:39:13 +0100
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

>
>
> Basically I think this is for designs where the input is a bunch of logic
> equations (e.g. coming from compiled schematics) and MAP has to do the
> work of allocating the logic to LUTs. For designs synthesised from HDLs
> this has already been done by the synth tool so -k most likely won't gain
> very much. In fact the Synplfy documentation recommends *not* using it
> since it will make the overall QOR worse, not better.

I should have added that if you want to get 5+ input functions so that a
critical path becomes less routing dependent then you can always structure
your code so that the synth tool can "see" the opportunity to at least use a
MUXF5. In the worst case you can always instantiate ...


Article: 45841
Subject: Re: Xilinx hiring practises
From: Ron Huizen <rhuizen@bittware.com>
Date: Wed, 07 Aug 2002 08:50:35 -0400
Links: << >>  << T >>  << A >>
Note that the lack of relocation offer could also be tied to the fact
that you're using a headhunter. I have seen some companies say that they
can either pay reloc or a headhunter, but not both ...



John Jakson wrote:
> 
> Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3D4FE14B.D56334C2@xilinx.com>...
> > John,
> >
> > Times are tough.  Xilinx did not have layoffs (oops, not pc), or have a
> > 'RIF' as all other silicon companies did.  We tightened our belts, stuck
> > to what we do best, and continued to execute.
> >
> > Recently, we realized we have an opportunity to hire the absolute best
> > engineers that had to be let go by their companies who were unable to
> > weather the downturn.
> >
> > The terms and conditions are ours to make:  since no one else is hiring
> > (for ASIC, ASSP, or FPGA), it matters little if we do not offer relocation
> > as a benefit.  We have many other benefits that are more important.  It is
> > up to the candidate to decide what the trade-offs are, and if they make
> > sense for them.
> >
> >
> >
> > As for Peter, and myself, no one ever offered us a relocation bonus.  In
> > the "old days" (and Peter is such a distinguished gentleman I would not
> > offer to state when that was) for me, I was told that if I wanted the job,
> > I could show up and interview for it.
> >
> > I know, we walked uphill in the snow to and from school, but hey, if you
> > have never experienced tough times, you have nothing to provide you with a
> > reference.
> >
> > As for discrimination, that is unfair and scurrilous to suggest:  we hire
> > the best, end of statement.  I have engineers in their 60's working for
> > me.  I have engineers in their 20's working for me.  I don't care how old
> > they are, and neither do any other managers here.
> >
> > Peter worked in Sweden after he graduated from college in Germany.
> >
> > Austin
> >
> 
> Hi Austin
> 
> Thanks for your response, I apologize for implying anything untoward.
> 
> I very glad to hear that more senior engineers are working hard at
> Xilinx.
> 
> Anyway I was really unaware that reloc packages were so severely
> limited by the industry at large today, as it has always been my
> fortune to have been offered this in prior times for out of state
> changes even when I think the economy was far worse 84 etc. I will
> bear this in mind next time I talk to folks.
> 
> Perhaps the head hunter should have been warned too, and I couldn't
> find this info on your job site or on any of the positions in B & W.
> 
> Regards

Article: 45842
Subject: Re: New XILINX ISE not supporting 4000 series FPGAs?
From: hamish@cloud.net.au
Date: 07 Aug 2002 12:59:09 GMT
Links: << >>  << T >>  << A >>
Kevin Brace <killspam4kevinbraceusenet@killspam4hotmail.com> wrote:
>        According to the Xilinx website, for XC4000 series, the only
> design flow currently supported is EDIF.
> Since ISE 4.2 no longer comes with Synopsys FPGA Compiler II, and XST
> doesn't support XC4000 series, the ISE 4.2 user will have to buy a
> separate third party synthesis tool.

Alternatively, don't upgrade.

BTW, I think you mean 4000E, XL, etc. Plain old 4000 isn't even
supported by any tool post-XACT, afaik.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 45843
Subject: Re: parameterized / variable ucf
From: francoischoquette@hotmail.com (Francois Choquette)
Date: 7 Aug 2002 06:07:17 -0700
Links: << >>  << T >>  << A >>
If you want to use a specific UCF file for an implementation, you can
use the command line option :

NGDBUILD -uc ucf_file_name

This way, you can use a script to implement the desing using a
different UCF file for every iteration.

Hope this helps.

Francois Choquette
LACIME


nahum_barnea@yahoo.com (Nahum Barnea) wrote in message news:<fc23bdfc.0208061208.68c0f05b@posting.google.com>...
> Hi.
> Is there a way to define a variable / parameter in the xilinx ucf file ?
> 
> I want to P&R to several design parameters.
> My clock frequency determine also my I/O setup requirement etc..
> 
> Thus I am looking for a way to easily switch from one ucf to another
> by changing 1 parameter at most.
> 
> Is it possible ?
> 
> ThankX,
> NAHUM.

Article: 45844
Subject: Modelsim glbl.GTS problem
From: "Peter Baltazarovic" <baltazarovic@ncode.sk>
Date: Wed, 7 Aug 2002 16:33:05 +0200
Links: << >>  << T >>  << A >>
Hi,

    I am trying to simulate 4 x CLK multiplier with DLLs in Spartan2 (as
described in XAPP132), but in ModelSim I am getting this error:
    # ** Error: (vsim-3043) d:/Xilinx/verilog/src/unisims/OBUF.v(21):
Unresolved reference to 'glbl' in glbl.GTS.
It is because of line:
    OBUF   lckpad (.I(LOCKED_DLL), .O(LOCKED));

    Can anybody help me?

Thank you a lot.

Peter.





Article: 45845
Subject: Re: Programming bits reverse engineering
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 7 Aug 2002 15:28:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3D50E7C6.4488BFFA@algor.co.uk>,
Rick Filipkiewicz  <rick@algor.co.uk> wrote:
>One thing I noticed is the the V-2 3DES keys are 64-bit but IIRC 3DES allows
>up to 112-bit. Is this down to the US cryptographic export restrictions ? Or
>is there some way of chaining together the 2 sets of 3 keys ?

Hu?  THe DES keys are 56 bits (with headers, padded to 64 bits), and 3
are chaned together to create a 3DES encryption.



-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 45846
Subject: Re: Programming bits reverse engineering
From: prashantj@usa.net (Prashant)
Date: 7 Aug 2002 08:33:45 -0700
Links: << >>  << T >>  << A >>
Hi,
I understand the part where if you give out a programmed device, you
can make it difficult for someone to break through, but what if I gave
out the programmed bits.

I will be giving the programming bits to someone so that he could use
it. All the same I dont want him to figure out the design represented
by the programming bits. Is it possible to get the design from the
programming bits ?

You may have answered the question, but I think I'm still a little
confused.

Thanks,
Prashant


Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3D505C89.5F4223BC@xilinx.com>...
> Prashant,
> 
> Use Triple DES config feature with three keys in Virtex II or Virtex II
> Pro.  Then the bits don't help you at all.
> 
> They can't even copy the bitstream and stamp out copies because the keys
> are hidden in the part, and can not be read out.
> 
> Alternately, fill up an entire 2V6000 with your design.  It would takes
> more than ten years of engineering to understand it.  By then, you would
> be selling your new improved version.
> 
> They would never be able to recover the original verilog or VHDL.
> 
> If I gave you Microsoft Windows bits, could you figure out what Microsoft
> is doing?
> 
> Given that you can place a Micro-Blaze uP in your design, you could have
> the part call home, and get its authorization to perform its function if
> and only if the customer was a valid one.
> 
> Get creative.
> 
> Austin
> 
> Prashant wrote:
> 
> > Hi,
> >
> > I would like to give someone the programming bits for an FPGA for my
> > design. Is there anyway the programming bits could be used to reverse
> > engineer to my design ? What is the safest way to let someone use your
> > design without them being able to figure out your FPGA design ?
> >
> > Thanks,
> > Prashant

Article: 45847
Subject: Re: Programming bits reverse engineering
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 07 Aug 2002 08:45:38 -0700
Links: << >>  << T >>  << A >>
Prashant,

Someone pointed out that I missed your point:  you want to give the bits
to someone.

If you give them the bits, then you can't just give them the keys too, as
then they can decrypt the bitstream (with a c program) and see the
bitstream in the clear (unencrypted).  So the triple DES doesn't work for
your situation.

Thus the safest way to prevent them from reverse engineering is to have a
large complex design that is just not worth their time to try to figure
out.

This is part of the problem selling IP:  if it is simple, how do you
protect yourself?

A number of years ago, a large unamed telecom manufacturer I knew of, sent
an ASIC to an unamed far eastern country for every switch board that was
to be built.  The ASIC cost a lot of money to the far eastern country
factory (it was, in effect the royalty payment).  The idea was that boards
would not work without the key ASIC, and if any board was ever found
without the exclusive ASIC from the telecom giant on it, they would then
know they had been cheated.

Such a part can be done today with a Coolrunner CPLD, and then turn on the
security bits, so it can't be read back out.  Reverse engineering it
requires that they use all kinds of clever techniques to read out the
internal states of the EEPROM (e-beam, backside emission, etc) or try to
figure out what it is saying or doing that makes it the key.  Nothing is
foolproof, and as long as it is harder to crack it than it is worth, you
succeed.

Austin

Prashant wrote:

> Hi,
>
> I would like to give someone the programming bits for an FPGA for my
> design. Is there anyway the programming bits could be used to reverse
> engineer to my design ? What is the safest way to let someone use your
> design without them being able to figure out your FPGA design ?
>
> Thanks,
> Prashant


Article: 45848
Subject: Re: Programming bits reverse engineering
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 7 Aug 2002 15:55:34 GMT
Links: << >>  << T >>  << A >>
prashantj@usa.net (Prashant) writes:

>I understand the part where if you give out a programmed device, you
>can make it difficult for someone to break through, but what if I gave
>out the programmed bits.

>I will be giving the programming bits to someone so that he could use
>it. All the same I dont want him to figure out the design represented
>by the programming bits. Is it possible to get the design from the
>programming bits ?

>You may have answered the question, but I think I'm still a little
>confused.

How much money does he have, and houw much is it worth it to him?

If your design is worth $1,000,000 then worry because he can probably
find someone to get the design from the bits for that price.

If it is only worth $10,000 then he probably can't.

(You don't say which device, how complicated it is, or things like
that, but those probably aren't too far off.  Maybe someone else will
come up with different numbers.)

-- glen

Article: 45849
Subject: Getting crazy: abnormal behavior (Xilinx Spartan2E)
From: Nicolas Matringe <nicolas.matringe@ipricot.com>
Date: Wed, 07 Aug 2002 18:05:02 +0200
Links: << >>  << T >>  << A >>
Hi all
I am facing a problem I can not understand: I have a signal that come sout of a
LUT and goes:
- to a pad FF (testpoint 1)
- to an internal FF (DFF, no enable, global async reset)
The output of this internal FF then goes to the rest of the design AND to
another pad FF (testpoint 2)
I have checked with both the floorplanner and the FPGA Editor: the LUT and the
FF are in the same slice and directly connected. The FF clock input is normally
connected to the global clock (no gated clock).
The output of this FF remains low, even when its input goes high (testpoint 1
toggles, testpoint 2 remains low)
Since the LUT and the FF are in the same slice, the propagation delay is really
short, whereas the propagation delay between the LUT and the pad must be much
longer.
What am I missing? 

-- 
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 02      http://www.IPricot.com/



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