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 22300

Article: 22300
Subject: Re: Vital glitch
From: Oliver.W@gmx.ch
Date: Thu, 04 May 2000 15:42:53 GMT
Links: << >>  << T >>  << A >>
Hi Jamil,

[...]
> Is it an important warining that I should take care of,
> or is it going to vanish on the real hardware (CPLD)
[...]

Maybe you can ignore it, but you should know, what you are going to
ignore :-)
Vital supports four modes of signal sheduling:
 - VitalInertial   -> same as VHDL Inertial delay (NO GLITCH MODE)
 - VitalTransport  -> same as VHDL Transport delay (NO GLITCH MODE)
 - OnEvent         -> special Mode for Glitch Handling
 - OnDetect        -> special Mode for Glitch Handling

The Modes for glitch handling are producing a glitch warning message
AND 'X' values (when an how long depends on the Sheduling Mode which
is used).
-> take a look into section 7 of the LRM for more details.
          ->>>>> http://www.vhdl.org/vi/vital/Dev/doc/lrm.tar.gz

The warning messages are normal :-). If these glitches are detected
internally (between two FF), then you can ignore them (in case
of a real problem at this point, the FF after the glitch producing
logic gets an 'X' with the next cycle and your system will not
work anymore).
If you have logic AFTER a FF which CAN produce glitches to the
chip boundaries you maybe have to take care about and not ignore
these messages :-) -> maybe you can write an 'X' detection around
your Chip IOs (Testbench). Then you will detect these problems,
even you switch off the 'Vital glitch Message Mode' in the simulator.

With QuickHDL/ModelSim you can switch off these warnings by the
'+no_glitch_msg' option.


Good Luck

--
Oliver

e-mail: Oliver.W@gmx.ch



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22301
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 4 May 2000 16:56:55 GMT
Links: << >>  << T >>  << A >>
In article <39118F77.B79F009@free-ip.com>,
David Kessner  <davidk@free-ip.com> 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

	(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).

	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.

	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".
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 22302
Subject: RF System Design Engineer
From: George Davis <george.davis@conexant.com>
Date: Thu, 04 May 2000 17:35:34 GMT
Links: << >>  << T >>  << A >>


RF SYSTEM DESIGN ENGINEER
Newport Beach, Ca
Conexant Systems, Inc. is a top-ten North American semiconductor
supplier, and the world's largest independent company focused
exclusively on providing semiconductor system solutions for
communications electronics. With revenues of approximately $1.5 billion,
Conexant has aligned its business to target the fastest-growing markets
of the worldwide communications marketplace. We have an exceptional
opportunity for a RF Systems Engineer at our Newport Beach, CA
headquarters.

We have exceptional opportunities for RF Systems Engineers to provide
support in
           	 specification, design, and simulation of complex
digital cellular and cordless
             	 communication systems. You will perform trade-off
studies to provide specification
          	 subsystems.

Requires BSEE or equivalent and 3 years hands-on experience. Experience
with receivers, transmitters, or synthesizer. Also, experience with
mixers, LNA's, and PA's.  Must be able to apply system work toward
implementation of RF ASIC devices. Strong background in communication
theory and knowledge of system simulation using state-of-the-art CAD
tools helpful. System development or hardware design in one of the
following areas a plus: GSM, CDMA, TDMA, cordless or GPS platforms.
Multiple openings from junior to very senior.

We offer highly competitive salaries and a comprehensive benefits
package including stock options.  Please call (949)483-9349 or email
resumes to:  george.davis@conexant.com.  Website: www.conexant.com.

We are an equal opportunity employer supporting diversity in the
workplace.

--
George Davis
Conexant Systems, Inc.
949-483-9349
george.davis@conexant.com


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

Article: 22303
Subject: Re: How to Prevent theft of FPGA design
From: David Kessner <davidk@free-ip.com>
Date: Thu, 04 May 2000 11:45:32 -0600
Links: << >>  << T >>  << A >>
"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.

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).  

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



>         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

Article: 22304
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 04 May 2000 13:48:48 -0400
Links: << >>  << T >>  << A >>
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

I read your app note and I think it covers all of the bases. I realize
that the Dallas serial number chips do not provide the kind of security
that is really needed if someone is willing to copy the hardware and
change the Dallas chip to a CPLD or a micro. 

But I would like to point out (again) that I think a small micro would
be a better candidate than a CPLD as the security device. From some of
the pointers that showed up in this thread, I have found some 8 bit
micros that come in 8 pin packages and will do the job quite nicely. A
CPLD will be at least 16 pins (I don't even know if they come that
small, likely they are 20 pins or more) and may well cost more than a
micro. 

There is one thing that is not clear to me. I would expect the securtity
device to be set to a known starting state which is picked randomly by
the FPGA. Then the resulting bitstream is tested to verify operation.
This has some problems which I won't go into. But your method seems not
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. 

This also means that the protection could be attacked by copying the
bitstream if the device is not one that needs to be kept running
uninterrupted for very long periods of time. If the product being
protected can be reset periodically then only the first M bits of the
bitstream would need to be copied. For example, if it is reset once a
day and clocked at 1 MHz, you would need to record 10**6 * 3600 * 24
bits or about 10**11 bits. This is about the same as the example LFSR
length or 2**36 bits which is 2**33 bytes or 8 GB. So this is still the
upper bound.

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. 

Anyone else have a comment?


-- 

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: 22305
Subject: Product Applications Engineer
From: George Davis <george.davis@conexant.com>
Date: Thu, 04 May 2000 18:01:11 GMT
Links: << >>  << T >>  << A >>


PRODUCT APPLICATIONS ENGINEER
Newport Beach California
Conexant Systems, Inc., formerly Rockwell Semiconductor Systems, is the
world's largest semiconductor company totally dedicated to
communications technologies. We are a driving force in 60% of all
Internet connections, 70% of the world's fax machines, and 80% of CDMA
cell phones. For decades, our mixed signal computing solutions have been
inside faxes, computer modems, cellular and cordless phones, PC
multimedia peripherals, digital infotainment appliances and network
access equipment.  We currently have exceptional opportunities for
Product Application Engineers in our Wireless Communications Division at
our Newport Beach headquarters.

Engineer will be liaison between customers, field personnel and design
team to accelerate customer design-in of wireless communications
products for cordless and cellular phones; create and present seminars;
write application notes, articles and other technical marketing
documents.  Positions available in the following areas of technical
expertise:  RF circuits for GSM handsets; Real-time embedded software in
C for GSM handsets and GPS products; and real-time embedded software in
Assembly for DSS products.  Requires engineering; strong background in
RF circuit or MMI software design; strong technical communication,
presentation and customer interface skills; wireless systems analysis
and problem solving; use of standard lab equipment.  Domestic and
international travel required.

We offer highly competitive salaries and a comprehensive benefits
package including stock options.  Please call (949)483-9349 or email
resumes to:  george.davis@conexant.com.  Website: www.conexant.com.

We are an equal opportunity employer supporting diversity in the
workplace.

--
George Davis
Conexant Systems, Inc.
949-483-9349
george.davis@conexant.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22306
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 4 May 2000 18:18:17 GMT
Links: << >>  << T >>  << A >>
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: 22307
Subject: Re: How to Prevent theft of FPGA design
From: David Kessner <davidk@free-ip.com>
Date: Thu, 04 May 2000 12:23:45 -0600
Links: << >>  << T >>  << A >>
Rickman wrote:
> David Kessner wrote:
> > 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 read your app note and I think it covers all of the bases. I realize
> that the Dallas serial number chips do not provide the kind of security
> that is really needed if someone is willing to copy the hardware and
> change the Dallas chip to a CPLD or a micro.
> 
> But I would like to point out (again) that I think a small micro would
> be a better candidate than a CPLD as the security device. From some of
> the pointers that showed up in this thread, I have found some 8 bit
> micros that come in 8 pin packages and will do the job quite nicely. A
> CPLD will be at least 16 pins (I don't even know if they come that
> small, likely they are 20 pins or more) and may well cost more than a
> micro.

In the case of my app note, a uC would not be a good choice.  The
reason for this is that the PRBS is clocked into the FPGA using
the main system clock.  For a uC to do that, a slower clock would
need to be used.  The nice thing about using the system clock is
that it isn't something that can be easily tampered with.  You
absolutely wouldn't want to use a dedicated PRBS clock because a
would-be pirate could just tie it low and disable the whole thing.

As long as you resolved this clock issue then there is nothing wrong
with using a uC rather than a CPLD.

I can think of some solutions to the clock issue, but you have to 
be careful that you don't increase the size of the logic in the FPGA.
If you do that then the total cost needs to be adjusted.

There are some 36 macrocell CPLD's for under US$2 in 100's, and 
approaching $1 in larger lots.  This is similar to many uC's that 
I know of.  


> There is one thing that is not clear to me. I would expect the securtity
> device to be set to a known starting state which is picked randomly by
> the FPGA. Then the resulting bitstream is tested to verify operation.
> This has some problems which I won't go into. But your method seems not
> 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, the bitstream runs continuously.  And, yes, this will cause some
power consumption.  You might be able to use a low power CPLD with a
slower clock-- but this would add cost.  Everything is a tradeoff.

The bitstream must run continuously because it is the same every time.
That is, the first 100+ bits are always the same every time the system
is reset.  If the bitstream was not continuous then there would be only
a relatively small number of bits to capture and copy.  Since it does
run continuously there are so many bits to copy that this type of attack
is not practical.

An alternative (mentioned by others) is more of a query/response system
where the FPGA queries the CPLD/uC with some random data and checks for
a proper response.  This would be as secure (but not more secure) than
my
approach, but the amount of logic required would be much more than the
10
slices needed in a Spartan-2.


> This also means that the protection could be attacked by copying the
> bitstream if the device is not one that needs to be kept running
> uninterrupted for very long periods of time. If the product being
> protected can be reset periodically then only the first M bits of the
> bitstream would need to be copied. For example, if it is reset once a
> day and clocked at 1 MHz, you would need to record 10**6 * 3600 * 24
> bits or about 10**11 bits. This is about the same as the example LFSR
> length or 2**36 bits which is 2**33 bytes or 8 GB. So this is still the
> upper bound.
> 
> 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.
> 
> Anyone else have a comment?

I didn't think of a frequent reset attack.  It is something to consider.
While many devices wouldn't work properly with frequent resets, I'm
sure that there are devices out there that would be just fine with that.

For low power applications where frequent resets are "doable" then 
one solution would be to use a low power CPLD (Xilinx/Phillips
Coolrunner)
and a faster clock.  If this isn't low power enough then this approach
wouldn't work.  Of the top of my head, I don't know how low power the 
Coolrunner is in this type of application.  


David Kessner
davidk@free-ip.com

Article: 22308
Subject: Mixed Signal Design
From: George Davis <george.davis@conexant.com>
Date: Thu, 04 May 2000 18:26:45 GMT
Links: << >>  << T >>  << A >>


DESIGN ENGINEER/ASIC/MIXED SIGNAL
Newport Beach, CA
Conexant has an immediate need for Analog/Mixed Signal Design Engineers
at our Newport Beach Corporate Headquarters.  This engineer will be part
of the Wireless ASIC team developing highly integrated systems on a chip
solutions for wireless communications applications.  Responsible for the
design of embedded mixed signal components in these devices from initial
specification developed in conjunction with systems and hardware groups
through design verification, integration, and test.  As not all mixed
signal blocks will be designed internally, working with external design
teams is a must and good communications skills are essential.

Required skills:
5 + years experience a minimum.  Experience with Mixed Signal Block
Specification Development and Analog design(ADC/DAC/PLL/OSC/low-power).
 Experience with Analog Block Level Layout , Analog BIST support, and
Analog Modeling.

We offer highly competitive salaries and a comprehensive benefits
package including stock options.  Please call (949)483-9349 or email
resumes to:  george.davis@conexant.com.  Website: www.conexant.com.

We are an equal opportunity employer supporting diversity in the
workplace.

--
George Davis
Conexant Systems, Inc.
949-483-9349
george.davis@conexant.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22309
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 4 May 2000 18:43:30 GMT
Links: << >>  << T >>  << A >>
In article <3911C031.D9CD4F0F@free-ip.com>,
David Kessner  <davidk@free-ip.com> wrote:

>In the case of my app note, a uC would not be a good choice.  The
>reason for this is that the PRBS is clocked into the FPGA using
>the main system clock.  For a uC to do that, a slower clock would
>need to be used.  The nice thing about using the system clock is
>that it isn't something that can be easily tampered with.  You
>absolutely wouldn't want to use a dedicated PRBS clock because a
>would-be pirate could just tie it low and disable the whole thing.
>
>As long as you resolved this clock issue then there is nothing wrong
>with using a uC rather than a CPLD.

	You have the FPGA derive the uC's clock.  Thus, you don't have
to worry about a separate clock being attacked, and you can suspend
and slow down the uC after a given period of time.  This adds VERY
little cost, as a clock divider by 2^N only requires N luts.

	This also allows stopping/suspending and resuming the checking
circuit.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 22310
Subject: Re: How to Prevent theft of FPGA design
From: David Kessner <davidk@free-ip.com>
Date: Thu, 04 May 2000 13:16:06 -0600
Links: << >>  << T >>  << A >>
"Nicholas C. Weaver" wrote:
> >As long as you resolved this clock issue then there is nothing wrong
> >with using a uC rather than a CPLD.
> 
>         You have the FPGA derive the uC's clock.  Thus, you don't have
> to worry about a separate clock being attacked, and you can suspend
> and slow down the uC after a given period of time.  This adds VERY
> little cost, as a clock divider by 2^N only requires N luts.
> 
> This also allows stopping/suspending and resuming the checking circuit.

Nice solution!  

David Kessner
davidk@free-ip.com

Article: 22311
Subject: Re: How to connect JTAG to XCS10pc84 FPGA device
From: a@z.com
Date: Thu, 04 May 2000 15:18:50 -0400
Links: << >>  << T >>  << A >>
Hi,

INIT must be low for JTAG configuration.

Catalin

e97bjli@thn.htu.se wrote:

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

Article: 22312
Subject: Re: Wait until statement problem in synthesis
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 04 May 2000 20:03:02 GMT
Links: << >>  << T >>  << A >>
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: 22313
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 4 May 2000 20:08:12 GMT
Links: << >>  << T >>  << A >>

	One final note, an LFSR is a VERY bad choice for E.  According
to David Wagner, finding the initial state of an N bit LFSR only takes
a sequence of N bits if you know the taps, N^2 if you don't.

	Which means using a CPLD would probably not work out well,
instead an at least slightly more robust encryption implemented in a
uC.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 22314
Subject: Re: How to Prevent theft of FPGA design
From: a@z.com
Date: Thu, 04 May 2000 16:08:27 -0400
Links: << >>  << T >>  << A >>
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

Article: 22315
Subject: Re: [BitGen] - pb option UserClk
From: Christian Mautner <at@utanet.cmautner>
Date: 04 May 2000 22:09:55 +0200
Links: << >>  << T >>  << A >>
"Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr> writes:

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

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.

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. Otherwise you have to do, for
example, this: 
-g StartUpClk:CCLK
-g DoneActive:C1
-g OutputsActive:C2
-g GSRInactive:C3

You have to search the dialogs for the appropriate checkboxes, if you
use the GUI.

chm.

-- 
cmautner@  -  Christian Mautner
utanet.at  -  Vienna/Austria/Europe
Article: 22316
Subject: Re: How to Prevent theft of FPGA design
From: Steve Dewey <steve@s-dewey123.demon.co.uk>
Date: Thu, 4 May 2000 22:01:56 +0100
Links: << >>  << T >>  << A >>
In article <3910C989.39F4F092@ids.net>, Ray Andraka <randraka@ids.net>
writes
>Heavy Sigh!   This subject comes up about once every 6-9 months. 

Has anyone used the Clear Logic parts ? Prototype using altera 10K parts
and then ask Clear Logic to produce some clones for you from your
bitstream. Goodbye external configuration stream, goodbye 99 % of the
security issue. Also goodbye in-field reprogramability, but you cannot
have everything. 

I have not had any contact with Clear Logic, I've just read the press
releases.

-- 
Steve Dewey

Article: 22317
Subject: edif
From: Christian Mautner <at@utanet.cmautner>
Date: 04 May 2000 23:18:02 +0200
Links: << >>  << T >>  << A >>

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
Article: 22318
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 04 May 2000 17:31:24 -0400
Links: << >>  << T >>  << A >>
"Nicholas C. Weaver" wrote:
> 
>         One final note, an LFSR is a VERY bad choice for E.  According
> to David Wagner, finding the initial state of an N bit LFSR only takes
> a sequence of N bits if you know the taps, N^2 if you don't.
> 
>         Which means using a CPLD would probably not work out well,
> instead an at least slightly more robust encryption implemented in a
> uC.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

How many bits does it take if you don't know the value of N? I would
guess that it takes the full 2^(N-1), but I don't know for sure. 

I am surprized that it only takes N^2 bits to determine the intial state
and tap arrangement of a LFSR. I know that not all possible combinations
of taps produce a non-repeating pattern of maximal length, but if you
have N bits in your LFSR, you should have up to 2^(N-1) possible LFSR
tap combinations. I am surprized that even if you know N, you would only
need N^2 bits to distinguish between 2^(N-1) combinations. 

I assume that if you use logic other than XOR functions in the feedback
loop, then it is not a LFSR by definition?


-- 

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: 22319
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 04 May 2000 17:42:14 -0400
Links: << >>  << T >>  << A >>
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: 22320
Subject: Re: How to Prevent theft of FPGA design
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 4 May 2000 21:43:05 GMT
Links: << >>  << T >>  << A >>
In article <3911EC2C.5CFAD988@yahoo.com>,
Rickman  <spamgoeshere4@yahoo.com> wrote:
>"Nicholas C. Weaver" wrote:
>
>How many bits does it take if you don't know the value of N? I would
>guess that it takes the full 2^(N-1), but I don't know for sure. 

	Probably not, you would have to ask a cryptographer to be
sure, but you could probably take a sample, apply the algorithm for
LFSR size 1-k, and see which ones give you results which match for a
longer string.


>I am surprized that it only takes N^2 bits to determine the intial state
>and tap arrangement of a LFSR. I know that not all possible combinations
>of taps produce a non-repeating pattern of maximal length, but if you
>have N bits in your LFSR, you should have up to 2^(N-1) possible LFSR
>tap combinations. I am surprized that even if you know N, you would only
>need N^2 bits to distinguish between 2^(N-1) combinations. 
>
>I assume that if you use logic other than XOR functions in the feedback
>loop, then it is not a LFSR by definition?

	Probably, but it may be equally weak.  You really should be
willing to spend more area and do something known to be robust, such
as DES for K < 54, or AES for a keysize of 128-192-256


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

Article: 22321
Subject: Re: How to Prevent theft of FPGA design
From: Robert Posey <muddy@raytheon.com>
Date: Thu, 04 May 2000 16:58:25 -0500
Links: << >>  << T >>  << A >>


"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.

Doesn't Xilinx have a temperature sensor in their FPGA's?  Could either it,
or some version of the various simulated A/D circuits be used to get a real
random number.

> >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: 22322
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 04 May 2000 17:59:35 -0400
Links: << >>  << T >>  << A >>
"Nicholas C. Weaver" wrote:
> 
> In article <3911EC2C.5CFAD988@yahoo.com>,
> Rickman  <spamgoeshere4@yahoo.com> wrote:
> >"Nicholas C. Weaver" wrote:
> >
> >How many bits does it take if you don't know the value of N? I would
> >guess that it takes the full 2^(N-1), but I don't know for sure.
> 
>         Probably not, you would have to ask a cryptographer to be
> sure, but you could probably take a sample, apply the algorithm for
> LFSR size 1-k, and see which ones give you results which match for a
> longer string.
> 
> >I am surprized that it only takes N^2 bits to determine the intial state
> >and tap arrangement of a LFSR. I know that not all possible combinations
> >of taps produce a non-repeating pattern of maximal length, but if you
> >have N bits in your LFSR, you should have up to 2^(N-1) possible LFSR
> >tap combinations. I am surprized that even if you know N, you would only
> >need N^2 bits to distinguish between 2^(N-1) combinations.
> >
> >I assume that if you use logic other than XOR functions in the feedback
> >loop, then it is not a LFSR by definition?
> 
>         Probably, but it may be equally weak.  You really should be
> willing to spend more area and do something known to be robust, such
> as DES for K < 54, or AES for a keysize of 128-192-256
> 
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

That sounds nice in theory, but that would be bigger than some of the
FPGAs that I use. This type of protection does not need to be of
cryptographic quality. It only needs to be "good enough" so that it will
withstand an economical attack. If it takes more than a week of time, it
is likely to deter all but the most determined. I doubt that many
designers even have the skills to decrypt a LFSR. If the length is
increased to say 48 bits, then I would bet that it would be enough of a
deterrence to ward off most companies. 

But surely there must be some FSM that would not be so easily decoded
and yet would be straight forward to construct. There are 2^(2^N)
possible functions of N inputs. This number gets incredibly large very
quickly. There may be a definable subset at least as large as 2^N which
can not be decoded in N^2 samples and yet can be constructed with a
small number of gates. 

Anyone know of any?


-- 

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: 22323
Subject: Q: simplest FPGA structure for novel technology demonstration
From: Paul Bunyk <paul@pbunyk.physics.sunysb.edu>
Date: 04 May 2000 18:54:46 -0400
Links: << >>  << T >>  << A >>

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!  :)

-- 
  ("`-''-/").___..--''"`-._   UNIX *is* user-friendly, he is just very 
   `6_ 6  )   `-.  (     ).`-.__.`) picky about who his friends are...
   (_Y_.)'  ._   )  `._ `. ``-..-'      Paul Bunyk, Research Scientist
 _..`--'_..-_/  /--'_.' ,'art by           (and part-time UN*X sysadm)
(il),-''  (li),'  ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul
Article: 22324
Subject: Re: How to Prevent theft of FPGA design
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 05 May 2000 12:12:40 +1200
Links: << >>  << T >>  << A >>
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. 
 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...

 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



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