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 19625

Article: 19625
Subject: timing diagrams
From: elynum@my-deja.com
Date: Wed, 05 Jan 2000 01:10:21 GMT
Links: << >>  << T >>  << A >>
Does anyone know where I can get a good book or article on timing
diagrams?  I haven't had a lot of experience when it comes to stuff like
timing violations as far as I need something that will explain how to
understand clock to output times, setup and hold times and their
importance in simulation.

Thanks



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19626
Subject: CLKDLL
From: erika_uk@my-deja.com
Date: Wed, 05 Jan 2000 01:12:46 GMT
Links: << >>  << T >>  << A >>
Hi all,

from the XAPP132(Figure 13,15), i can't see why a SRL16 is introuced at
the output of the LOCKED pin, from where it's drived, from the
"ordinary" slices....

any explanation please


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19627
Subject: STARTUP
From: erika_uk@my-deja.com
Date: Wed, 05 Jan 2000 01:32:14 GMT
Links: << >>  << T >>  << A >>
hi all,

Many of you mention that the virtex-startup has not to be used for high
frequency designs.

i have created a "dummy" design (one FDC) , i want to know what is the
delay of GSR. i have found that the GSR width increase by really small
amount (<2ns) comparing to the reset pulse

so can we conclude that if the reset pulse is too narraow, the
virtex-startup can be even incorporated in high frequency design

by the way for real time operating system, let's say video for example,
from where the reset pulse is derived

thanks in advance


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19628
Subject: STARTUP
From: erika_uk@my-deja.com
Date: Wed, 05 Jan 2000 01:33:40 GMT
Links: << >>  << T >>  << A >>
hi all,

Many of you mention that the virtex-startup has not to be used for high
frequency designs.

i have created a "dummy" design (one FDC) , i want to know what is the
delay of GSR. i have found that the GSR width increase by really small
amount (<2ns) comparing to the reset pulse

so can we conclude that if the reset pulse is too narraow, the
virtex-startup can be even incorporated in high frequency design

by the way for real time operating system, let's say video for example,
from where the reset pulse is derived

thanks in advance


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19629
Subject: Re: fpga cost
From: steenl@pal.ECE.ORST.EDU (Steen Larsen)
Date: 5 Jan 2000 01:50:48 GMT
Links: << >>  << T >>  << A >>
In article <3873489A.62646EDE@nospam.erols.com>,
rk  <stellare@nospam.erols.com> wrote:
>John Cain wrote:
>
>> Ray,
>>
>> I have found that intermittant pin connections on FPGA PLCC sockets are
>> usually due to scope probing during development which bends the contact
>> leafs inward. This is especially severe when the SW guys are checking the
>> HW.
>>
>> Ray Andraka wrote in message <38603C1A.8AB55592@ids.net>...
>> >Rich.
>> >
>> >I'm surprised you've had good luck with the PLCC 84 sockets and FPGAs.
>> I've had
>> >some very bad experiences with those.  THey seem OK the first time you put
>> a chip
>> >in.  Remove and replace the chip once or twice and let the games begin.
>
>John, I agree 100%.  When I first started using them it was very convenient to
>slide the probe tip between the socket contact and the side of the device; it
>sticks in rather nicely.  It was one of those "nice thought, bad idea" sort of
>things.  As I said in a previous post, with the use of a good extraction tool
>and some care, I haven't had any problems since then, even treating the boards
>somewhat roughly.  I also note that these sockets come on commercial test
>equipment; HP is one vendor that uses them, and they're usually pretty careful
>about reliability.  I'd be interested in hearing about any problems other
>people have had.
>
>Of course, me attempting to solder and then do a R&R on a PLCC84 which have
>much lower reliability than the socket. :-)
>

I agree with John too.  After finding it out we started using "bird's nest"
adapters that would explode a PLCC socket to a 100mil pin array with another
PLCC socket in the center.  I have seen them for 44PLCC and 84PLCC.  They are
a great alternative to over-exuberant probers... 

Regards, 
-steen
Article: 19630
Subject: Re: fpga cost
From: "John Cain" <jjcain@goodnet.com>
Date: Tue, 4 Jan 2000 17:52:51 -0800
Links: << >>  << T >>  << A >>
Ray,

I have found that intermittant pin connections on FPGA PLCC sockets are
usually due to scope probing during development which bends the contact
leafs inward. This is especially severe when the SW guys are checking the
HW.



Ray Andraka wrote in message <38603C1A.8AB55592@ids.net>...
>Rich.
>
>I'm surprised you've had good luck with the PLCC 84 sockets and FPGAs.
I've had
>some very bad experiences with those.  THey seem OK the first time you put
a chip
>in.  Remove and replace the chip once or twice and let the games begin.
>




Article: 19631
Subject: REad function query
From: #YEO WEE KWONG# <P7102672H@ntu.edu.sg>
Date: Wed, 5 Jan 2000 10:44:28 +0800
Links: << >>  << T >>  << A >>
Hi,

I have a query below, hope you can help:

I use the std.textio and ieee.std_textio libraries for the program
below: 

Can anyone explain why Option B don't work (by not giving the right
result like for instance to read a decimal no of 20, option B gives me a
value of x00??)

Instead, i have to do a workaround by reading in as integer then convert
to std_logic_vector to get a right answer?

constant cSignalSize : integer := 5;

process
begin

	:
	:
  variable vValueField  : std_logic_vector(15 downto 0) := (others =>
'0');;
  variable vTempInteger : integer;
  variable vInLine	: line;
  variable vReadStatus  : boolean;
	:
	:


   -- Option A
   read(vInLine, vTempInteger, vReadStatus); 
   vValueField(cSignalSize - 1 downto 0) :=
conv_std_logic_vector(vTempInteger, cSignalSize);

   -- Option B
   read(vInLine, vValueField(cSignalSize - 1 downto 0), vReadStatus);  

end process;

Thanks for your help.

Wee Kwong


Article: 19632
Subject: Re: synthesis opportunities
From: Randy Yates <yates@ieee.org>
Date: Tue, 04 Jan 2000 22:22:41 -0500
Links: << >>  << T >>  << A >>
Eileen Haldeman wrote:
> [...]

Sure, I'm always up for an opportunity to synthesize...
-- 
% Randy Yates                   % "Though you ride on the wheels of tomorrow,
%% DIGITAL SOUND LABS           %  you still wander the fields of your
%%% Digital Audio Sig. Proc.    %  sorrow."
%%%% <yates@ieee.org>           % '21st Century Man', *Time*, ELO
http://www.shadow.net/~yates
Article: 19633
Subject: Re: fpga cost
From: Ray Andraka <randraka@ids.net>
Date: Tue, 04 Jan 2000 23:00:59 -0500
Links: << >>  << T >>  << A >>
That wouldn't surprise me.  I'm usually called in after the customer has run into a
dead end in the lab. By then, the sockets are already toast.  I've also seen bad
surface mount connections on those PLCC sockets that go onto a PLCC footprint.  I
guess they are hard to inspect or something.  My other objection to sockets is that
sockets pull the part farther away from decoupling and can introduce ugly
reflections on pins.  Not really an issue unless you are pushing the part's
capability.

Steen Larsen wrote:

> In article <3873489A.62646EDE@nospam.erols.com>,
> rk  <stellare@nospam.erols.com> wrote:
> >John Cain wrote:
> >
> >> Ray,
> >>
> >> I have found that intermittant pin connections on FPGA PLCC sockets are
> >> usually due to scope probing during development which bends the contact
> >> leafs inward. This is especially severe when the SW guys are checking the
> >> HW.
> >>
> >> Ray Andraka wrote in message <38603C1A.8AB55592@ids.net>...
> >> >Rich.
> >> >
> >> >I'm surprised you've had good luck with the PLCC 84 sockets and FPGAs.
> >> I've had
> >> >some very bad experiences with those.  THey seem OK the first time you put
> >> a chip
> >> >in.  Remove and replace the chip once or twice and let the games begin.
> >
> >John, I agree 100%.  When I first started using them it was very convenient to
> >slide the probe tip between the socket contact and the side of the device; it
> >sticks in rather nicely.  It was one of those "nice thought, bad idea" sort of
> >things.  As I said in a previous post, with the use of a good extraction tool
> >and some care, I haven't had any problems since then, even treating the boards
> >somewhat roughly.  I also note that these sockets come on commercial test
> >equipment; HP is one vendor that uses them, and they're usually pretty careful
> >about reliability.  I'd be interested in hearing about any problems other
> >people have had.
> >
> >Of course, me attempting to solder and then do a R&R on a PLCC84 which have
> >much lower reliability than the socket. :-)
> >
>
> I agree with John too.  After finding it out we started using "bird's nest"
> adapters that would explode a PLCC socket to a 100mil pin array with another
> PLCC socket in the center.  I have seen them for 44PLCC and 84PLCC.  They are
> a great alternative to over-exuberant probers...
>
> Regards,
> -steen

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19634
Subject: Re: STARTUP
From: Ray Andraka <randraka@ids.net>
Date: Tue, 04 Jan 2000 23:04:31 -0500
Links: << >>  << T >>  << A >>
The problem is not that the pulse is too narrow to work, rather it is the
fact that the pulse may not end on the same clock cycle for all flip-flops
in the design because of distribution delays.  In the absence of some other
considerations in the design, this can lead to part of the design coming
out of reset a clock cycle ahead of other parts of the design.  Naturally,
that can cause problems.

erika_uk@my-deja.com wrote:

> hi all,
>
> Many of you mention that the virtex-startup has not to be used for high
> frequency designs.
>
> i have created a "dummy" design (one FDC) , i want to know what is the
> delay of GSR. i have found that the GSR width increase by really small
> amount (<2ns) comparing to the reset pulse
>
> so can we conclude that if the reset pulse is too narraow, the
> virtex-startup can be even incorporated in high frequency design
>
> by the way for real time operating system, let's say video for example,
> from where the reset pulse is derived
>
> thanks in advance
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19635
Subject: Re: An online division unit with constant divisor
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com>
Date: Wed, 05 Jan 2000 13:25:05 +0100
Links: << >>  << T >>  << A >>
Christer Ericson wrote:
> 
> On Tue, 04 Jan 2000 10:29:20 +0100, Terje Mathisen
> <Terje.Mathisen@hda.hydro.com> wrote:
> >[...]
> >I disagree with the exact algorithm he chose for the cases where the
> >reciprocal value ends with a fraction which is less than 0.5, but the
> >final results are correct and the running speed is pretty much the same
> >anyway.
> 
> Terje, could you please elaborate on your prefered alternative
> version for that case?

OK.

If the exact reciprocal is on the form 0xXXXXXXXX.0XXX... then a 33-bit
reciprocal is needed.

This reciprocal value will have both the top and the bottom bit set, so
either of them can be added in after the multiplication.

a) Remove the top bit, put remaining 32 bits into EBX

; EAX has number to be divided

  mov ecx,eax		; Make a copy of the input
  mov ebx,[bottom_32_bits_of_reciprocal]

  mul ebx
  add edx,ecx		; Add into the top dword, effectively mul by 2^32
; At this point we can get an overflow, which must be handled:
  rcr edx,1
; Find the final answer by shifting down EDX:
  mov cl,[bits_to_shift]
  shr edx,cl

b) Remove the bottom bit:
  
  mov ecx,eax		; Make a copy of the input
  mov ebx,[top_32_bits_of_reciprocal]
  mul ebx
  shr ecx,1		; Shift down the input, to correspond to a 0.5 multiplier
  add eax,ecx		; Add into the bottom dword
  adc edx,0		; Propagate any carry
; Find the final answer by shifting down EDX:
  mov cl,[bits_to_shift]
  shr edx,cl

With a couple of small tweaks, the same code can be used for all kinds
of divisors:

  mov ebx,[top_32_bits_of_reciprocal]
  mov ecx,eax		; Make a copy of the input
  mul ebx
  and ecx,[mask_33rd_bit] ; -1 or 0 for 33 vs 32-bit reciprocals
  shr ecx,1		; Shift down the input, to correspond to a 0.5 multiplier
  add eax,ecx		; Add into the bottom dword
  adc edx,0		; Propagate any carry
; Find the final answer by shifting down EDX:
  mov cl,[bits_to_shift]
  shr edx,cl

If powers of two are quite likely, esp. if a divisor of 1 is possible,
then it becomes useful to specialcase this:

  mov ebx,[top_32_bits_of_reciprocal]
  mov ecx,eax		; Make a copy of the input
  mov edx,eax		; Multiply by 2^32
  test ebx,ebx
   jz power_of_two
  mul ebx
  and ecx,[mask_33rd_bit] ; -1 or 0 for 33 vs 32-bit reciprocals
  shr ecx,1		; Shift down the input, to correspond to a 0.5 multiplier
  add eax,ecx		; Add into the bottom dword
  adc edx,0		; Propagate any carry
; Find the final answer by shifting down EDX:
power_of_two:
  mov cl,[bits_to_shift]
  shr edx,cl

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
Article: 19636
Subject: Lattice Vantis GDX
From: Stef Winteraeken <swin@oce.nl>
Date: Wed, 05 Jan 2000 13:25:14 +0100
Links: << >>  << T >>  << A >>
Who wants to share his experiences with Generic Digital Crosspoints
(GDX) of Lattice Vantis with me?

All relevant info appreciated.

Thanks.
Stef
Article: 19637
Subject: Re: fpga cost
From: rk <stellare@nospam.erols.com>
Date: Wed, 05 Jan 2000 08:35:22 -0500
Links: << >>  << T >>  << A >>
John Cain wrote:

> Ray,
>
> I have found that intermittant pin connections on FPGA PLCC sockets are
> usually due to scope probing during development which bends the contact
> leafs inward. This is especially severe when the SW guys are checking the
> HW.
>
> Ray Andraka wrote in message <38603C1A.8AB55592@ids.net>...
> >Rich.
> >
> >I'm surprised you've had good luck with the PLCC 84 sockets and FPGAs.
> I've had
> >some very bad experiences with those.  THey seem OK the first time you put
> a chip
> >in.  Remove and replace the chip once or twice and let the games begin.

John, I agree 100%.  When I first started using them it was very convenient to
slide the probe tip between the socket contact and the side of the device; it
sticks in rather nicely.  It was one of those "nice thought, bad idea" sort of
things.  As I said in a previous post, with the use of a good extraction tool
and some care, I haven't had any problems since then, even treating the boards
somewhat roughly.  I also note that these sockets come on commercial test
equipment; HP is one vendor that uses them, and they're usually pretty careful
about reliability.  I'd be interested in hearing about any problems other
people have had.

Of course, me attempting to solder and then do a R&R on a PLCC84 which have
much lower reliability than the socket. :-)

Have a good evening,

----------------------------------------------------------------------
rk                               The world of space holds vast promise
stellar engineering, ltd.        for the service of man, and it is a
stellare@erols.com.NOSPAM        world we have only begun to explore.
Hi-Rel Digital Systems Design    -- James E. Webb, 1968

Article: 19638
Subject: Re: Decoding RSPC (Reed Solomon Product Code)
From: Christof Paar <christof@ece.wpi.edu>
Date: Wed, 5 Jan 2000 10:29:15 -0500
Links: << >>  << T >>  << A >>
The following book might be of help, although it is out of print. Perhaps
you can find it in a good library:

Schouhamer Immink, K.A.: Coding techniques for digital recorders.
   Prentice Hall, New-York etc. 1991   

You can also check the following web site which describes some research on
RS decoders on FPGAs:

  http://www.ee.byu.edu/~ahlquist


Finally, if you click the "Recent Publications" button at our web site at

  http://www.ece.wpi.edu/Research/crypt

you will find an article by Rosner/Paar about arithmetic for RS decoders
on FPGAs.

Hope that is of some help,

Christof

! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2000) !
!                   WPI, August 17 & 18, 2000                         !
!          http://www.ece.wpi.edu/Research/crypt/ches                 !

***********************************************************************
                 Christof Paar,  Assistant Professor
          Cryptography and Information Security (CRIS) Group
      ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon:(508) 831 5061  email: christof@ece.wpi.edu   
fax:(508) 831 5491  www: http://www.ece.wpi.edu/People/faculty/cxp.html
***********************************************************************

> MK Yap wrote in message <84savt$bo2$1@violet.singnet.com.sg>...
> >Hi,
> >
> >I'm writing a prog (VHDL or C) to enable block encoding and decoding of CD
> >sectors.  In the ECC (error correction coding) field, RSPC(Reed Solomon
> >Product Code) is used. The RSPC is a product code over GF(2^8) producing P
> >and Q parity bytes.  The GF(2^8) field is generated by the primitive
> >polynomial
> >P(x) = x^8 + x^4 + x^3 + x^2 + 1
> >The P parities are (26,24) RS codeword over GF(2^8) and the Q parities are
> >(45,43) RS codeword over GF(2^8).
> >
> >My question is: How can I write the encoding and decoding algorithm for the
> >ECC field?? The RS used are non standard RS codes (n,k) in which n is
> >usually n=2^m -1 which m=8 in this case...
> >I tried to look for more info from books but it is really limited... I came
> >across some books saying that conventional RS decoding can be used.. that
> is
> >the berlekamp, Peterson and Weldon algorithm.  But I see no connection
> >between them coz the derivation is based on a fundamental which is
> >different.
> >
> >Pls enlighten... by providing some books, paper, web site or perhaps
> >explanation of theory behind them...  Thank you very much!!
> >
> >Happy Millenium 2000!!
> >
> >MKYap
> >
> >
> >
> 
> 
> 


Article: 19639
Subject: FPGA and SW Engineering opportunities in CT
From: jlamontagne@my-deja.com
Date: Wed, 05 Jan 2000 16:46:01 GMT
Links: << >>  << T >>  << A >>
FPGA Designers
Location: Central Connecticut
Salary: Open

5+ years experience in designing high speed FPGAs.  Experience with
ATM, Fram Relay, IP or SONET, very high speed data communications
protocols is crucial.  Track record of FPGA development using
VHDL/Verolog Design simulation using Model Technology desirable.  You
will work with timing designer, schematic capture packages and provide
written specifications for all phases of their design.  BSCS or BSEE. A
candidate should be comfortable working with the demands of a small
startup company. Specifically, the ability to be self-directed, to be
able to solve system and tool problems as they arise, etc., would be
helpful. Candidates should have good design skills, coding skills, and
debugging skills.

Embedded Software Engineers
Location: Central Connecticut
Salary: Open

Significant experience in C programming language. Experience in real-
time embedded systems, especially for the Data Communications and/or
Telecommunications markets. Experience with Data Communications
protocols, especially TCP/IP, ATM, SONET, Ethernet, SNMP, etc.
Experience with the VxWorks and Tornado operating environment or
another real time operating system such as PSOS, VRTX, QNX, etc.
Experience with RISC processors would be helpful, particularly Power PC
microprocessor.

Design and develop a real-time control and maintenance system for
carrier class networking products. Experience in real-time embedded
systems, such as VxWorks, PSOS, VRTX, etc. in the LAN/WAN area.
Experience in fault tolerant systems highly desirable. BSCS or BSEE.

The Client, located in central Connecticut, develops leading edge, high
speed networking products for telecom service providers.  Founded in
1/99 by a team of experienced networking professionals with a
successful track record of developing innovative new networking
products at companies such as Sahara Networks, Cascade, Ascend, Lucent,
Fore Systems and General DataComm.  The company is privately held pre-
IPO, with 65 person staff  and assets of $35M.  They offer full
benefits and relocation (lump sum).

If interested, please send resume to:   jobs@careergroupstaffing.com

James LaMontagne, CPC
Career Group Staffing
181 Park Avenue, PO BOX 772
West Springfield, MA 01090
(413) 785-1818
FAX (413) 785-1977
http://www.careergroupstaffing.com




Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19640
Subject: Re: Design security
From: randombit@my-deja.com
Date: Wed, 05 Jan 2000 17:48:53 GMT
Links: << >>  << T >>  << A >>
In article <J2pb4.1167$B9.1464225@feed.centuryinter.net>,
  "Larry Edington" <larryeSpam.Me.Not@centuryinter.net> wrote:
> I'm not concerned about a hacker obtaining the contents of the 'logic'
in
> the FPGA. That I know would be very difficult and those with the
resources
> to do so would spend those resources designing a new device from
scratch.
>

A pirate could take your config eeprom to a chip vendor
(Clear Logic turns Altera configs to ASICs; Chip Express
would laser-cut a chip in a day; I think they could
work from config file.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19641
Subject: Re: Design security
From: randombit@my-deja.com
Date: Wed, 05 Jan 2000 17:58:52 GMT
Links: << >>  << T >>  << A >>
In article <AAyb4.1186$B9.1484255@feed.centuryinter.net>,
  "Larry Edington" <larryeSpam.Me.Not@centuryinter.net> wrote:
> So it looks like I do understand after all.

Its a really interesting, important problem.  Heavily
related to crypto, tamper-resistance, watermarking, etc.

If you add some extra logic you could prove (later,
in court) that the copy is yours, even if you don't
get inside the copy.  E.g., pull the clone chip,
and present an undocument signal to it which causes
it to spit out "This IP is property of WidgetCorp".
This would work even if the pirates went to ASIC from
your config file.

> It's not a military device and doesn't have to be super spook secure.
I just
> wanted to make it hard for casual copying. I know it can be reverse

No one has yet mentioned physical packaging, perhaps because
its weak, but a blob of opaque epoxy will present a small obstacle.



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19642
Subject: Re: Design security
From: randombit@my-deja.com
Date: Wed, 05 Jan 2000 18:14:19 GMT
Links: << >>  << T >>  << A >>


Since the pirates will be doing a lot of reverse engineering,
its worthwhile pointing out that a DES cracker is less than
a quarter million U$D.  3DES (with a 56x3 bit key) would
be slower but who cares, its just used at init time.  There are
probably some good compound-LFSR-based stream ciphers which would take
less resources too, though less well known/historical as DES.

Also, if you make each eeprom's key unique, you 'watermark'
the eeprom: you can tell whose instance was cloned.

It would be a pain by hand but the right combo of circuits
and tools would make it worthwhile.  Security always costs
*some* convenience.




In article <dPOb4.669$197.60977@news.goodnet.com>,
  "John Cain" <jjcain@goodnet.com> wrote:
> Larry,

> SRAM FPGAs could easily be made secure by the addition of a fixed DES
> Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed.
> Now you can OTP the FPGA device key & encript the external
configuration
> eeprom and everything remains protected.
>
> A DES cell would not be that big with current FPGAs based on <0.25u
CMOS
> processes. Better FPGA protection is definitely necessary as digital
> embedded
> products become a single chip system based on an FPGA.
>



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19643
Subject: Re: Design security
From: Ray Andraka <randraka@ids.net>
Date: Wed, 05 Jan 2000 20:12:06 -0500
Links: << >>  << T >>  << A >>
One of the problems with encrypting the bitstream is that a large part of
the bit stream and its timing is a known constant (header, and lots of zero
bits), which makes it a bit easier for the attacker.

randombit@my-deja.com wrote:

> In article <AAyb4.1186$B9.1484255@feed.centuryinter.net>,
>   "Larry Edington" <larryeSpam.Me.Not@centuryinter.net> wrote:
> > So it looks like I do understand after all.
>
> Its a really interesting, important problem.  Heavily
> related to crypto, tamper-resistance, watermarking, etc.
>
> If you add some extra logic you could prove (later,
> in court) that the copy is yours, even if you don't
> get inside the copy.  E.g., pull the clone chip,
> and present an undocument signal to it which causes
> it to spit out "This IP is property of WidgetCorp".
> This would work even if the pirates went to ASIC from
> your config file.
>
> > It's not a military device and doesn't have to be super spook secure.
> I just
> > wanted to make it hard for casual copying. I know it can be reverse
>
> No one has yet mentioned physical packaging, perhaps because
> its weak, but a blob of opaque epoxy will present a small obstacle.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19644
Subject: Desperate Xilinx problem SOLVED!
From: jonathan@canuck.com (Victor the Cleaner)
Date: 6 Jan 2000 05:04:44 GMT
Links: << >>  << T >>  << A >>
As some might recall, I posted a couple of weeks ago regarding
a bone-chilling Spartan problem that we'd been battling for a 
(large) number of weeks.  Tonight it was solved, and you aren't
going to believe it...

To recap:  The problem could be reproduced in about 20 lines of
VHDL.  We had experienced it in both the XCS40 (PQFP208) and the
XCS10 (PLCC84), both in 5V.  The short version is that upon 
completion of configuration (via JTAG, and yes, the DONE pin went
high indicating successful config) the part's combinatorial logic
(ie address decoders) would work flawlessly and the registered
logic (ie a couple of latches off of a 2MHz data bus) would never
accept data, instead holding their outputs permanently low despite
probes indicating all the signals necessary for setting them were
present.

To cut to the smooching and violin music, the problem was not with
the VHDL, constraints, or anything else.  It was with Foundation
2.1i w/ service pack 3.  We don't yet understand on a cycle-by-cycle
basis exactly what was going on, but the essence of it is that 
there's a configuration option in the bitstream generator that tells
the part how many CCLK cycles to wait after completion of configuration
before letting all the registers out of reset.  This is straightforward
enough if you're doing serial configuration, but we're doing JTAG, and
it's not entirely clear at this point what the precise relationship is
between the JTAG timing and that of a serial clock not being used for
configuration.  In any event, the default setting for this is "3",
and this is apparently one more than actually occurs in the course of
JTAG programming.  So it sat, holding every register in the part in
reset, patiently waiting for a clock pulse that never came.  Changing
this setting to its lowest value, "2", caused the design to magically
leap to life.

Where to find this bit of pure evil?  In the Design Manager:

Design
	Options
		Configuration
			Edit Options
				Startup
					Release Set/Reset C2 C3 C4 

If we'd been doing serial programming instead of JTAG, we would have
never suffered this bizarre failure.

Extensive thanks for the interminable perseverance demonstrated by
Kirk Saban of Insight (our disty) and Harvey Ehrenholz of Electrosource,
(the rep) both here in Calgary.  It was another of Insight's FAEs that 
gave us the hint leading to the answer after the Xilinx factory app engs 
failed to reproduce the error.  Presumably their software was not set to 
the out-of-box defaults.  Xilinx will be getting the bill for the single
malt.

And thanks, of course, to all the comp.arch.fpga readers who 
responded to my pleas for help. 

Jonathan

Article: 19645
Subject: BGA sockets and Virtex
From: "Marc Battyani" <Marc_Battyani@csi.com>
Date: Thu, 6 Jan 2000 11:23:07 +0100
Links: << >>  << T >>  << A >>
Has anybody tried and used a Virtex in a BGA socket ?
If yes which socket models ?
It's for a 100MHz design.

Thanks
Marc Battyani



Article: 19646
Subject: Re: BGA sockets and Virtex
From: "Olaf" <Olaf_Birkeland@coldmail.com>
Date: Thu, 6 Jan 2000 12:32:54 +0100
Links: << >>  << T >>  << A >>
Marc Battyani <Marc_Battyani@csi.com> wrote in message
news:7F332B48B96A2E07.CD1B60C042D659F2.0650BA8808E3C344@lp.airnews.net...
> Has anybody tried and used a Virtex in a BGA socket ?
> If yes which socket models ?
> It's for a 100MHz design.
>

I've used BGA sockets from Advanced Interconnections
(http://www.advintcorp.com) for this ("TrueBGA" series, requires no adapter
soldered to BGA package, same footprint as BGA package itself) with a Virtex
BGA560 package. I had some trouble with the corner guides which were too
tight (had to remove some epoxy), Avanced claims that they have fixed this
now. The coin screw has been a bit difficult to tighten hard enough (partly
due to the previous problem), thus I've enlarged the cutout for a
screwdriver. Also had one socket delivered which lacked two solder balls.
Don't bee too scared by these faults, this was ~1 year ago when the product
was brand new.

I've only used 66 MHz externally with full scale operation, but have tried
some test signals at 100 MHz. Didn't show significant difference from the
expected behavious of a PCB mounted device with the same load (~8 cm track)

Regards,
- Olaf


Article: 19647
Subject: Re: Design security
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Thu, 06 Jan 2000 14:29:56 GMT
Links: << >>  << T >>  << A >>
On Tue, 04 Jan 2000 12:03:20 +0100, Armin Mueller
<armin.mueller@stud.uni-karlsruhe.de> wrote:

>Now, the "plain text" is (nearly) known. Altera config files consist 
>of e.g. 90% zeroes, 9% single bit bytes.

Compression sort of helps that particular nasty. Add the use of a
feedback based encryption scheme (so long as the compression didn't
start with a "known" header that was also encrypted) and you'd be
pretty safe. I would personally NEVER use DES in ECB mode.

If greater design security than this is required, you will likely be
building stuff with explosives rigged to an ejector seat, or the
product will spend all of it's time guarded by men with attack dogs
and automatic weapons.

Cheers
Stuart
For Email remove "NOSPAM" from the address
Article: 19648
Subject: Re: Design security
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Thu, 06 Jan 2000 14:29:57 GMT
Links: << >>  << T >>  << A >>
On Wed, 05 Jan 2000 18:14:19 GMT, randombit@my-deja.com wrote:

>Since the pirates will be doing a lot of reverse engineering,
>its worthwhile pointing out that a DES cracker is less than
>a quarter million U$D.  3DES (with a 56x3 bit key) would

At that financial cost, the kind of people you will be dealing with
STEAL designs, not crack them. They might also not be averse to a bit
of "roughing up", or considerably, worse in the pursuit of what would
have to be lucrative returns on their "investment".

>be slower but who cares, its just used at init time.  There are
>probably some good compound-LFSR-based stream ciphers which would take
>less resources too, though less well known/historical as DES.

Stream ciphers range from the noddy continuous XOR with '1' to the
"perfection" of the truly random one-time pad. The BIG problem with
the use of a stream cipher is (just like a one-time-pad) it can NEVER
be restarted with a different message. That's essentially going to
prevent the field upgrading of the FPGA. Minor drawback, but there you
go.

>Also, if you make each eeprom's key unique, you 'watermark'
>the eeprom: you can tell whose instance was cloned.

Making each corresponding FPGA key unique is a nice way to "license"
your hardware upgrades. Maintenance anyone?

Cheers
Stuart
For Email remove "NOSPAM" from the address
Article: 19649
Subject: Re: BGA sockets and Virtex
From: Peter A Dudley <padudle@sandia.gov>
Date: Thu, 06 Jan 2000 15:36:09 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------6C3E34CE8D1C75220EF226DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Marc

We are using a 3M/TexTool BGA Socket that works pretty well. It clamps
on the side above the centerline of the balls so that they can be
soldered down later. We're using the sockets for an ASIC not an FPGA but
its the same Amkor Super BGA package that the Virtex uses.

We wanted to use the same board layout with the socket as we did with
the soldered down part as you are doing. We accomplished this even
though the socket is a through hole device by putting a via for each BGA
pad and opening up the via hole size a little. The pins on the socket
are very slim so we can solder the socket into the vias or we can solder
the BGA directly onto the BGA pads.

In this configuration, I believe this 3M/TexTool BGA Socket should work
well above 100MHz. We're hoping to do above 500MHz because the ASIC is
GaAs.

Good Luck

	Pete
--------------6C3E34CE8D1C75220EF226DE
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Dudley
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Peter Dudley
n:              Dudley;Peter
org:            Sandia National Labs
adr:            box 5800;;Mail Stop 0505;Albuquerque;NM;87185;USA
email;internet: padudle@sandia.gov
title:          SMTS
tel;work:       505.844.5565
tel;fax:        505.844.2925
note:           Digital Signal Processing in Hardware and Software
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------6C3E34CE8D1C75220EF226DE--



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