Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 7050

Article: 7050
Subject: Re: How do FPGAs outperform DSP at FFT?
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Date: Sun, 27 Jul 1997 20:48:38 GMT
Links: << >>  << T >>  << A >>
On Fri, 25 Jul 1997 08:56:09 GMT, fliptron@netcom.com (Philip Freidin)
wrote:

>Typically, I find that the place for optimization of DSP algorithms in
>FPGAs is in how the multiplies are done. Often (say in an FIR filter) the
>multiply is by a constant. So the first optimization is to throw away the
>slices of the multiply where the constant bit is a zero. What is left is
>the '1' bits. So an optimization may be to adjust the FIR design so that
>the constants have a minimal set of '1' bits. For example you could
>support a dynamic range of constants of 8 bits, giving 0 thru 255, but set
>a rule that no constant can have more than 3 bits set. This would allow
>constants like 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, ...
>upto 224. While all possible values are not available, you get a good
>range down near zero, a reasonable selection all the way upto 224. Why
>bother? Well you can implement this constrained multiply with just one or
>two adders.  Here is another example of a constraint: the constant can
>have at most 2 bits that are non-zero, and the non-zero bits can have
>either Positive or Negative weighting. So you can do things like 7 = 8-1,
>9 = 8+1, 24 = 16+8 and 56 = 64-8, and lots more. This type of multiplier
>can be implemented in just one adder/subtractor! 

Indeed, the first method is straight forward Booth Multiplier, which
gives improvement where there is a run of identical bits. Better for
larger width data is Modified Booth triplet (signed multiplication).
Especially where you must have all possible values as coefficients. It
guarantees to reduce adder/subtractor terms by 2 when doing a new
multiplier & multiplicand every clock cycle. This is at the expense of
some add/sub selection and shifting, but nothing in life is for free.
Failing that, the "constant co-efficient" multiply is much easier to
implement with a ROM, or LUT's and cascaded adders. It's also pretty
compact. e.g. In ORCA, such an implementation allows 8x8 multipliers
to exceed 100 MHz, and require 10 PFUs for each multiplier. (a 16 bit
adder is 4 PFU's).

<snip of example design>
Nice example. Illustrated the point very nicely.

Stuart
Article: 7051
Subject: Re: Should Xiling have more local clock nets?
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Date: Sun, 27 Jul 1997 22:54:09 GMT
Links: << >>  << T >>  << A >>
On Sat, 26 Jul 1997 08:52:15 GMT, z80@dserve.com (Peter) wrote:
>
>>So try a 3.3V ORCA FPGA, and put clocks on globals, longs, or even
>>half length lines. The I/O's can direct drive all the routing (xL, xH,
>>x4, and x1, so clock pad to PFU (CLB) clock input can be fast too.
>
>If this works in Orca devices, why not in Xilinx devices?

I have absolutely no idea, so I guess we'll leave that one for Xilinx
to answer. However, a few thoughts spring to mind...

3000 series (Lucent)

The K pin can be driven in the 3000 series via a small fixed piece of
local routing by the vertical long line nearest the CLB. Assuming that
the only driving source is the single long line, then I can see no
reason why it shouldn't work providing the following steps are taken

1
The clock input pad must be on the top or bottom of the FPGA. Left or
right won't work. It's best if its the left most one, as this one can
directly drive the necessary long line. 
2
All clocked CLB's must be in the same column as the IOB. Break this
rule, and your skew will bomb.
3
Use Foundry and specify a maximum skew, so the routing doesn't go mad
and go through magic switches etc. 

I did a few examples, and it seemed fine from simulation and timing
reports. In the 3000 series architecture, there are re-powering
buffers at the top and bottom of the long line, but I don't think they
should affect this kind of application. Maybe in 3000A series it's
different. I can't tell, as I don't have XACT.

4000E, EX, XL series

The input buffer drive from I1 appears only to drive the edge decoder,
a double length line, and two single length lines, so that certainly
isn't any use for a clock input. The I2 port can drive direct routing
(no use) or the tri-state buffers running onto the inner of the 3 long
lines running above and below the two pad group. To route from either
of those long length lines to the K input will then require moving
onto the single length lines via a switch. I can only see a possible
path from the lower of the two lines in the architecture to the K
input. There are no K connect points from the vertical long lines
showing the lack of symmetry in the 4000 series architecture. I guess
this kind of approach might work if the routing can be kept the same.
Is there a clock skew specification in XACT yet? Have they kept it
over from NeoCAD in M1?

This type of clock might be safe in 4000 series' with the following
rules.

1
The clock input pad can only be on the left or right of the FPGA die.
2
All clocked CLB's must be in the same row. (I don't know about driving
IOB clocks, but it looks very dodgy).
3
The clock must be distributed on the lower long line that is driven by
the TBUF's.

All in all, a bit of a nightmare for 4000 series. If I'm wrong on any
of this, somebody please tell me.

ORCA

In ORCA, the clock distribution arrangement is very different, as
there are no global buffers per se. This gives the engineer a lot of
flexibility.

The clock input to a PFU (containing 4 flipflops) can be directly
driven by any one of the eight long and half length lines running both
horizontally, and vertically in each channel. Similar rules will apply
as with Xilinx, but there is much more freedom of placement and
routing.

The real benefit comes when you cannot locate all PFU's in one row, or
column, but can perhaps restrict them two or three columns or rows.
When you do this, you can bring the clock in on a distribution spine,
and just drive two long length lines for the rows or columns actually
being used. This might not sound like much of a big deal, but in a
2C15A, this could mean a reduction in clock loading of as much as 90%.
Driving of output flipflops isn't a problem either.

To use a phrase that has been used before:

"ORCA. Burn rubber, not boards".

Stuart

Article: 7052
Subject: Re: FPGA die photograph
From: Peter Alfke <peter@xilinx.com>
Date: Sun, 27 Jul 1997 15:58:23 -0700
Links: << >>  << T >>  << A >>
Well, there is the cover of Scientific American, July 1997.
Pelase, excuse the somewhat self-serving answer.
Peter Alfke, Xilinx
Article: 7053
Subject: Re: Why fast message delete in this group? - date format "flame"
From: Nics@organisation.com.au (Nic)
Date: Sun, 27 Jul 1997 23:38:05 GMT
Links: << >>  << T >>  << A >>
In article <33d809ad.15752806@news.mindspring.com>, tech100@mindspring.com wrote:

>Not to be critical, but how come you use a date format that cannot be
>recognized intuitively?  Isn't it easy to confuse it with the other
>non-intuitive method?    You know, 3/1/97 is March fisrt to some, and
>January third to others.

Hmmmm, it seems perfectly 'intuitive' to me to interpret a date or time in a 
sequential order from smallest to largest or largest to smallest. The fact 
that a few confused people seem to like to mix things up should not stop us 
using perfectly sensible systems. The annoying thing is that many computer 
programs and systems use this strange mixed up format by default. Must be 
due to the silly byte reversal on Intel 80XXX processors!

Nic
Article: 7054
Subject: Re: Dates (was: fast delete)
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Mon, 28 Jul 1997 09:07:14 +0100
Links: << >>  << T >>  << A >>
Nic wrote:
> 
>tech100@mindspring.com wrote:
> 
>>Not to be critical, but how come you use a date format that cannot be
>>recognized intuitively?..cut...
> 
>Hmmmm, it seems perfectly 'intuitive' to me to interpret a date or time in a
>sequential order from smallest to largest or largest to smallest. The fact
>that a few confused people seem to like to mix things up should not stop us
>using perfectly sensible systems. The annoying thing is that many computer
>programs and systems use this strange mixed up format by default. Must be
>due to the silly byte reversal on Intel 80XXX processors!

I'm told the ANSI standard is big-endian year_month_day, so there can be
no mixup as with mixed (conventional US) or little-endian (current
UK/Europe) date and big-endian time (universal).  This matters once we
get past 2000, since with two (decimal) digits at least one could always
be certain which one was the year, but in 2001...

Tim Forcer               tmf@ecs.soton.ac.uk
Department of Electronics & Computer Science
The University of Southampton, UK

The University is not responsible for my opinions
Article: 7055
Subject: Re: Should Xiling have more local clock nets?
From: Tim Warland <twarland@nortel.ca>
Date: Mon, 28 Jul 1997 09:02:04 -0400
Links: << >>  << T >>  << A >>
Tom Burgess (a fellow Canuck) wrote:
> 

> What would make me really happy (for multirate DSP) is some way of
> synchronously distributing derived clocks, each synchronously gateable.
> For example, from a 1X 100MHz fast clock input, distributing 100, 50 and
> 25 Mhz clocks on chip, with all clocks having guaranteed relative skew
> so that data could be transferred between any combination of flip-flops
> with no timing hassles. Easy to say, but hard to do I'm sure.

Actually this kind of clocking is easy to do.  There is a silicon
company
(IDT I think) that make ICs to perform that function at the board level
and do it well.  A similar "core" could be dropped into the FPGA silicon
for kick-ass clock distribution.   This however leads back to the
original
problem of power dissipation.  You can imagine what dividing and
generating
low skew, high slew clock drivers does for your power dissipation.

FPGA silicon is always a trade off.  The target is to do many things
well,
not few things exceptionally.

Tim Warland
ASIC Engineer
-- 
You better be doing something so that in the future
you can look back on "the good old days"

My opinions != Nortel's opinion;
Article: 7056
Subject: Re: PCI burst transfers
From: z80@dserve.com (Peter)
Date: Mon, 28 Jul 1997 13:06:44 GMT
Links: << >>  << T >>  << A >>

>  Either way all FPGAs suck tremendously in performance and per unit cost
>  compared to gate array or standard cell ASIC implementation.  I redid a
>  8000 gate FPGA built in a 0.6 um process with a 10,000 gate gate array (I
>  added a few extra functions) in a nearly obsolete two metal 1.0 um process.
>  The FPGA only ran at about 2/3 of the maximum target clock frequency, the
>  gate array twice as fast as needed.  The gate array was about 25% the cost
>  (for a relatively low volume video capture and processing VME card) of the
>  FPGA and the gate array NRE plus my time was paid for after selling less
>  than a 100 units.  (This didn't even include the cost of maintaining the
>  FPGA fuse files and programming parts on the production floor).
>
>  A good compromise is if you can design system ASIC(s) to be drop in compatible
>  with an existing FPGA.  The system can be brought up earlier with the FPGA and
>  lab testing and evaluation can provide valuable input to the final ASIC design
>  (and even reduced capability early beta units to customers).  Sometimes some FPGA
>  samples might run fast enough under benign or conditions to run a few systems at
>  full speed prior to sampling the ASIC.

Well put. No suprise here :)


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 7057
Subject: Re: Should Xiling have more local clock nets?
From: z80@dserve.com (Peter)
Date: Mon, 28 Jul 1997 13:06:46 GMT
Links: << >>  << T >>  << A >>
Thank you for a very informative post.

The problem is that do achieve this one needs to do a lot of hand
layout.

I have always used schematic entry only for FPGA work, with
constraints specified as net attributes. (I know what the diehards
here will say about that, but I believe FPGAs should be regarded as a
*solution* to a problem :))

With the older Xilinx devices, one could attach a L attribute to a
local clock net (forces it onto a long line), add a SC=1 (skew below
1ns) attribute, and that would do it. This was with the old (1991) APR
program. With the new devices (and using PPR) this doesn't work.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 7058
Subject: San Diego/Santa Clara/Boston--MTS-FPGA Field Applications Engineer-Recruiter
From: amaraju@onramp.net (Executive Search)
Date: Mon, 28 Jul 1997 09:53:51 -0500
Links: << >>  << T >>  << A >>
Due to explosive growth in our FPGA product line, this Microelectronics
group of a $23billion Communications company is seeking a very talented
engineer for a MTS FPGA Field Applications Engineering position.

Locations-San Diego,Ca. Santa Clara, Ca. and Boston, Ma.

Applicants should have at least 3 years exp in the design and development
of integrated circuits, either FPGA or ASIC. Expertise in VHDL or Verilog
HDL is required.

BSEE or MSEE required.
 
We are looking for a seasoned digital circuit designer with the
interpersonal skills to perform the presentation and customer relationship
roles.

Duties include:
Working with engineers to implement/optimize designs
Presentations to engineers and managers
Working with engineers to teach them tool flows
Educating customers on methods and techniques
Converting existing designs from competitors products to there FPGAs
Providing feedback for future products, features, and tools
Evaluting and prioritizing opportunities
Providing detailed technical info/assistance

FAE will be set up in a virtual office or will be located in leased
executive/shared office facilities.

Salary--$60-$90K base + 12 to 15% annual bonus and Field Sales Incentive
Plan(Normally a bonus of approximately 15 to 25/30% for design wins and
car allowance and who knows what else. 

THIS IS A VERY LUCRATIVE COMPENSATION PACKAGE FOR A TALENTED DESIGNER WHO
IS READY TO "COME OUT FROM BEHIND THE DESK".

THESE POSITIONS WON'T LAST LONG!!!

-- 
Eddie Amara- Executive Recruiter
SpencerSearch,Inc. "We Specialize in Recruiting Premier Talent for Exceptional Companies in the Semiconductor Industry" 
Home Page-http://www.spencersearch.com
Voice 972-378-0280
Fax 972-378-0279
Email amaraju@onramp.net
=====================================================================
Article: 7059
Subject: information on RIPP10
From: Mauro Olivieri <olly@dibe.unige.it>
Date: Mon, 28 Jul 1997 18:59:58 +0200
Links: << >>  << T >>  << A >>
Hello,
does anyone have information on the RIPP10 board from Altera?
Is it a relatively new product? What about the programming
software? (I tried the Altera web site but the net is VERY
slow).

Thank you,
Mauro Olivieri

-- 
*********************************************************
*  Mauro Olivieri           voice:  +39 10 3532265      *
*  Assistant Professor      fax:    +39 10 3532795      *
*  DIBE - Univ. of Genoa    e-mail: olly@dibe.unige.it  *
*********************************************************
Article: 7060
Subject: Re: free FPGA software from actel
From: Sam Falaki <Falaki@uqtr.uquebec.ca>
Date: Mon, 28 Jul 1997 17:23:34 GMT
Links: << >>  << T >>  << A >>
> >> Has somebody tested the free actel software? Is it worth to download?
> >> Is programmer support included? Is the ACTIVATOR needed or is there
> >> a free design for a simple programming hardware.

I managed to compile VHDL and target a very wide range of devices
without even going through any tutorial or reading any "help"
whatsoever.  It's really easy to use.  You can kind of guess your
way along and next thing you know you're done.  I liked it.

-- 
Sam Falaki
Graduate Student (Electrical Engineering)
Universite du Quebec a Trois-Rivieres (UQTR)
e-mail: falaki@uqtr.uquebec.ca
Article: 7061
Subject: Design Protection in FPGAs
From: Sam Falaki <Falaki@uqtr.uquebec.ca>
Date: Mon, 28 Jul 1997 17:31:08 GMT
Links: << >>  << T >>  << A >>
Hi all,

I have been mostly doing work in "academia".  Now however, I need to
make a commercial prototype and I'm worried that my design could be
copied.  Anyone have any suggestions?  For example do one-time
programmable FPGAs offer more security?  I don't have the money to
pay expensive lawyers (patent protection, etc).  I would like a quick
and easy solution if possible however all suggestions are welcome.

Regards,

-- 
Sam Falaki
Graduate Student (Electrical Engineering)
Universite du Quebec a Trois-Rivieres (UQTR)
e-mail: falaki@uqtr.uquebec.ca
Article: 7062
Subject: Re: Should Xiling have more local clock nets?
From: Tom Burgess <tburgess@drao.nrc.ca>
Date: Mon, 28 Jul 1997 10:46:21 -0700
Links: << >>  << T >>  << A >>
Tim Warland wrote:
> 
> 
> Actually this kind of clocking is easy to do.  There is a silicon
> company
> (IDT I think) that make ICs to perform that function at the board
> level
> and do it well.  A similar "core" could be dropped into the FPGA
> silicon
> for kick-ass clock distribution.   This however leads back to the
> original
> problem of power dissipation.  You can imagine what dividing and
> generating
> low skew, high slew clock drivers does for your power dissipation.
> 
> FPGA silicon is always a trade off.  The target is to do many things
> well,
> not few things exceptionally.
> 
> Tim Warland
> ASIC Engineer
> --
> You better be doing something so that in the future
> you can look back on "the good old days"
> 
> My opinions != Nortel's opinion;

Regarding power dissipation, the fantasy implementation I had in
mind would distribute a high speed reference clock with limited
fanout to a set of clock gate/dividers/buffers, perhaps one per
vertical longline or half length line. Sort of a heirarchy, with
division being done closer to the bottom of the tree. Only (high fanout)
clock nets that needed to be fast would be switching fast, and since
much of the timing path would be common regardless of divide ratio,
skew management might be easier.

	regards, tom (tburgess@drao.nrc.ca)
Article: 7063
Subject: San Diego/Santa Clara/Boston--MTS-FPGA Field Applications Engineer-Recruiter
From: amaraju@onramp.net (Executive Search)
Date: Mon, 28 Jul 1997 12:48:03 -0500
Links: << >>  << T >>  << A >>
Due to explosive growth in our FPGA product line, this Microelectronics
group of a $23billion Communications company is seeking a very talented
engineer for a MTS FPGA Field Applications Engineering position.

Locations-San Diego,Ca. Santa Clara, Ca. and Boston, Ma.

Applicants should have at least 3 years exp in the design and development
of integrated circuits, either FPGA or ASIC. Expertise in VHDL or Verilog
HDL is required.

BSEE or MSEE required.
 
We are looking for a seasoned digital circuit designer with the
interpersonal skills to perform the presentation and customer relationship
roles.

Duties include:
Working with engineers to implement/optimize designs
Presentations to engineers and managers
Working with engineers to teach them tool flows
Educating customers on methods and techniques
Converting existing designs from competitors products to there FPGAs
Providing feedback for future products, features, and tools
Evaluting and prioritizing opportunities
Providing detailed technical info/assistance

FAE will be set up in a virtual office or will be located in leased
executive/shared office facilities.

Salary--$60-$90K base + 12 to 15% annual bonus and Field Sales Incentive
Plan(Normally a bonus of approximately 15 to 25/30% for design wins and
car allowance and who knows what else. 

THIS IS A VERY LUCRATIVE COMPENSATION PACKAGE FOR A TALENTED DESIGNER WHO
IS READY TO "COME OUT FROM BEHIND THE DESK".

THESE POSITIONS WON'T LAST LONG!!!

-- 
Eddie Amara- Executive Recruiter
SpencerSearch,Inc. "We Specialize in Recruiting Premier Talent for Exceptional Companies in the Semiconductor Industry" 
Home Page-http://www.spencersearch.com
Voice 972-378-0280
Fax 972-378-0279
Email amaraju@onramp.net
=====================================================================
Article: 7064
Subject: Re: Should Xiling have more local clock nets?
From: husby@fnal.gov (Don Husby)
Date: 28 Jul 1997 17:54:26 GMT
Links: << >>  << T >>  << A >>
Tom Burgess  tburgess@drao.nrc.ca wrote:
> What would make me really happy (for multirate DSP) is some way of
> synchronously distributing derived clocks, each synchronously gateable.
> For example, from a 1X 100MHz fast clock input, distributing 100, 50 and
> 25 Mhz clocks on chip, with all clocks having guaranteed relative skew
> so that data could be transferred between any combination of flip-flops
> with no timing hassles. Easy to say, but hard to do I'm sure.

I cast my vote in favor of this option.

Either that or make FFs capable of clocking on both edges of a
clock so that some can run at double speed.




Article: 7065
Subject: Giga Ops g900 board
From: Muhammad Hamid <mhamid@cs.wright.edu>
Date: Mon, 28 Jul 1997 15:56:58 -0400
Links: << >>  << T >>  << A >>

Hi everybody,

I currently working with Giga Operation's G900 board. Trying to
reconfigure the board at run-time. Is there anyone experienced with this
board so that we can exchange ideas? The FPGA function call mechanism
seems to be not too good in this board (for my purpose).

Cheers,

Hamid




Article: 7066
Subject: Re: Should Xiling have more local clock nets?
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Date: Mon, 28 Jul 1997 21:37:57 GMT
Links: << >>  << T >>  << A >>
On Mon, 28 Jul 1997 13:06:46 GMT, z80@dserve.com (Peter) wrote:

>Thank you for a very informative post.

Pleasure. I know I'm supposed to be biased, but I prefer solutions,
not marketing BS.

>The problem is that do achieve this one needs to do a lot of hand
>layout.

True, although in my world you could place just a few PFU's/CLB's and
the clock input, and let Foundry sort it out. It might not be
completely optimal, but the nature of clock distribution in ORCA would
ensure pretty good power results anyway.

The 2TxxA series has solved a lot of "cool" engineering problems.

>I have always used schematic entry only for FPGA work, with
>constraints specified as net attributes. (I know what the diehards
>here will say about that, but I believe FPGAs should be regarded as a
>*solution* to a problem :))

Nothing wrong with schematics. Used them myself quite recently on some
designs.

>With the older Xilinx devices, one could attach a L attribute to a
>local clock net (forces it onto a long line), add a SC=1 (skew below
>1ns) attribute, and that would do it. This was with the old (1991) APR
>program. With the new devices (and using PPR) this doesn't work.

How deeply disappointing. Will M1 fix this?

Stuart

Article: 7067
Subject: Re: free FPGA software from actel
From: nctnico@cistron.nl (Nico Coesel)
Date: Mon, 28 Jul 1997 23:04:43 GMT
Links: << >>  << T >>  << A >>
Sam Falaki <Falaki@uqtr.uquebec.ca> wrote:

>> >> Has somebody tested the free actel software? Is it worth to download?
>> >> Is programmer support included? Is the ACTIVATOR needed or is there
>> >> a free design for a simple programming hardware.

>I managed to compile VHDL and target a very wide range of devices
>without even going through any tutorial or reading any "help"
>whatsoever.  It's really easy to use.  You can kind of guess your
>way along and next thing you know you're done.  I liked it.

Does the Actel package include a VHDL compiler?? How about simulation?
I'm very interested to hear some experiences from people who have been
using this package. My main concern with these type of packages is
comfortable design input (graphically or text based) and simulation
which includes timing behavior.

At the moment I have the ISPgal package from Lattice / DataIO, but
that doesn't include a good way to examine the timing behavior of the
design (which can be quite complex).

-- 
Failure does not prove something is impossible, failure simply
proves you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 7068
Subject: Re: San Diego/Santa Clara/Boston--MTS-FPGA Field Applications Engineer-Recruiter
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 29 Jul 1997 07:47:39 GMT
Links: << >>  << T >>  << A >>
In article <amaraju-2807971248030001@ppp11-5.dllstx.onramp.net> amaraju@onramp.net (Executive Search) writes:
>Due to explosive growth in our FPGA product line, this Microelectronics
>group of a $23billion Communications company is seeking a very talented
>engineer for a MTS FPGA Field Applications Engineering position.

Potential applicants should contact ATT/Lucent directly and bypass the
middle man who doesn't have the courtesy to keep job postings out of a
technical news group, and put them where they belong. By going direct you
will save Lucent big bucks, and so will be able to ask for a great signing
bonus. (negotiate 50% of the head hunter's fee you are saving them). 

Philip Freidin

Article: 7069
Subject: MEM_CS16 timing on ISA BUS
From: @ihr.mrc.ac.uk
Date: Tue, 29 Jul 1997 09:22:35 +0100
Links: << >>  << T >>  << A >>
Any advise on the timing of the MEM_CS16 line of the PC ISA Bus would be
appriciated.  I'm trying to design a DSP board with a shared memory
interface to the PC.  I want to use 16 bit transfers for the memory but
this seems to affect the video card.  I've already assertained that the
address bits of the auxiliary channel need to be used on the decode for
this signal (imposing 16 bit transfers on a 128KB page) but what other
signals need to be incorparated to produce the required decode?  I'm
using an open collector pull down transistor and a Lattice 2032 for the
decode logic.  Any help or pointers to where I can get help would be
appriciated

John
Article: 7070
Subject: Re: Design Protection in FPGAs
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 29 Jul 1997 08:37:54 GMT
Links: << >>  << T >>  << A >>
The level of protection you need, depends on what you are protecting, and 
who you are protecting it from. Here are some examples:

1) Direct copy ripoff. The bad guys copy your board layout, and all 
   prom/chip configuration data and build a direct ripoff.

2) Reverse engineer copying. You have real clever algorithms in your
   programmable devices, and the bad guys reverse engineer the design
   and then use the ideas that are extracted to build a competitive
   device.

The first case can usually be dealt with through copyright messages in
proms, and on PCB layouts. Typically I find very few clients who are
concerned with this category, because of the traditional mechanisms for
dealing with blatant ripoffs. The exceptions I have seen are in the arcade
game business (see item (4) below). 


The second case is the more common one that companies are concerened
with. Before worrying about how to protect the design, first think about
this: If someone connected a logic amalyzer to all the pins of the chip,
would they be able to figure out what is going on inside. If the answer
is yes, then additional protection effort is useless. This is typically
true of small devices (in terms of number of logic gates). If the design
is trivial, then its behaviour is not too hard to deduce. If the design
is more complex (say 5000 gates and above, with internal memory, complex
state machines, and multiple control registers that change how the chip
operates) then the logic analyzer may not be enough.

Levels Of Protection:
---------------------

1) Security fuses on PALs. This stops the trivial readback of a PAL,
   and creating a direct copy. On the other hand, PALs are trivial,
   and so the logic analyzer attack is not too hard. There is also
   software available that can deduce the contents of a PAL inspite
   of the security fuse being blown (or EPROM bit being set).

2) One time programmable CPLDs, with a security bit (typically
   EPROM/EEPROM) are more secure than SRAM FPGAs (that have an external
   configuration that is loaded at startup) for the first case. For
   the second case (extracting an idea, not just copying the code),
   both CPLDs and FPGAs have similar security, since their complexity
   is higher than PALs, and the format of the data is a trade secret of
   the IC vendor. I.E. even if you didn't set the security bit of a CPLD,
   once you had the programming info, you still wouldn't have the design,
   same as having the bitstream for an SRAM FPGA (except for the Xilinx
   6200, for which the bitstream details are published).

3) Anti-fuse FPGAs with a security bit have similar security to the CPLDs
   with a security bit. Note that both can be cracked by de-lidding the 
   device and analyzing the device with a voltage contrast scanning electron
   microscope. This is not an easy thing to do though, and is VERY expensive
   ( > $100K to get done. )
   Note also that such aggressive reverse engineering doesn't give you nice
   neat schematics. You end up with a gate netlist that is totally flat, 
   and is a hybrid mess of the design that is being ripped off, together
   with parts of the CPLD/FPGA programming hardware, startup logic, self
   test logic, and other stuff. The same also applies to trying to reverse
   engineer an SRAM FPGA bitstream. To my knowledge, this has only been
   done successfully once, by a very motivated company, and the intent was
   not to ripoff an end user's design, but rather to create competitive
   CAE software.

4) The highest security is with SRAM FPGAs that have a power-down/battery
   backed up mode of operation (such as the XC3000L products). With these
   devices, the bitstream is loaded into the device during manufacturing,
   and a battery maintains the configuration data in the device, even when
   the system is turned off. Unless you want to have a big battery, you
   need an FPGA that can maintain its data in a power down mode with very
   little power. The XC3000L parts can do this as low as 5uA, which is
   down at the battery's own leakage current, and with appropriate
   batteries, could give an operation life of 5 to 10 years. Because of the
   way these devices have been designed, if you are going to use this mode
   of protection, there is a way to tell the chip during configuration that
   read back of the bit stream is prohibited. I believe it would be very
   difficult to reverse engineer such a chip, because of the difficulty
   of maintaining the bit stream, while de-lidding the device (like a
   molded quad flatpack) and detaching it from the board, in preparation
   for the e-beam prober.

   This type of security is quite robust against both types of ripoffs
   described at the top of this article.

In summary, if your fears are of the first type of copying, then devices
with security bits, or the last example will give you varying levels of
security. If your fears are the second kind, then the more you put into
the FPGA, the less of the design is visible, and the harder it is to
reverse engineer.


Philip Freidin


In article <33DCD75C.29D3@uqtr.uquebec.ca> Sam Falaki <Falaki@uqtr.uquebec.ca> writes:
>Hi all,
>
>I have been mostly doing work in "academia".  Now however, I need to
>make a commercial prototype and I'm worried that my design could be
>copied.  Anyone have any suggestions?  For example do one-time
>programmable FPGAs offer more security?  I don't have the money to
>pay expensive lawyers (patent protection, etc).  I would like a quick
>and easy solution if possible however all suggestions are welcome.
>
>Regards,
>
>-- 
>Sam Falaki
>Graduate Student (Electrical Engineering)
>Universite du Quebec a Trois-Rivieres (UQTR)
>e-mail: falaki@uqtr.uquebec.ca


Article: 7071
Subject: MEM_CS16 TIMING (repeat)
From: John Chambers <johnc@ihr.mrc.ac.uk>
Date: Tue, 29 Jul 1997 11:47:48 +0100
Links: << >>  << T >>  << A >>
Any advise on the timing of the MEM_CS16 line of the PC ISA Bus would be
appriciated.  I'm trying to design a DSP board with a shared memory
interface to the PC.  I want to use 16 bit transfers for the memory but
this seems to affect the video card.  I've already assertained that the
address bits of the auxiliary channel need to be used on the decode for
this signal (imposing 16 bit transfers on a 128KB page) but what other
signals need to be incorparated to produce the required decode?  I'm
using an open collector pull down transistor and a Lattice 2032 for the
decode logic.  Any help or pointers to where I can get help would be
appriciated

John
Article: 7072
Subject: Re: Design Protection in FPGAs
From: "Rich K." <rich.katz@gsfc.nasa.gov>
Date: 29 Jul 1997 11:29:47 GMT
Links: << >>  << T >>  << A >>
hi sam,

for the actel antifuse devices, it is basically impossible to copy the
design from a prototype board.  i believe it would be similar for the
quicklogic parts too - my experience to date w/ m2m antifuses showed
similar properties (i.e., can't tell if an antifuse is programmed by
looking at it).  you might also want to look at some of the flash-based
devices (gatefield, i believe) although i don't know what security
arrangements they have, if any.

rk

__________________________________________________


Sam Falaki <Falaki@uqtr.uquebec.ca> wrote in article
<33DCD75C.29D3@uqtr.uquebec.ca>...
> Hi all,
> 
> I have been mostly doing work in "academia".  Now however, I need to
> make a commercial prototype and I'm worried that my design could be
> copied.  Anyone have any suggestions?  For example do one-time
> programmable FPGAs offer more security?  I don't have the money to
> pay expensive lawyers (patent protection, etc).  I would like a quick
> and easy solution if possible however all suggestions are welcome.
> 
> Regards,
> 
> -- 
> Sam Falaki
> Graduate Student (Electrical Engineering)
> Universite du Quebec a Trois-Rivieres (UQTR)
> e-mail: falaki@uqtr.uquebec.ca
> 
Article: 7073
Subject: Re: MEM_CS16 timing on ISA BUS
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 29 Jul 1997 11:50:43 GMT
Links: << >>  << T >>  << A >>
John,

Go buy this book:

http://www.annabooks.com/sx030007.htm

ISA and EISA Theory and Operation by E. Solari.  It is the bible for
designing ISA and EISA interfaces, and all your questions will be answered
there.

Austin Franklin
darkroom@ix.netcom.com


@ihr.mrc.ac.uk wrote in article <33DDA84B.2EE4@ihr.mrc.ac.uk>...
> Any advise on the timing of the MEM_CS16 line of the PC ISA Bus would be
> appriciated.  I'm trying to design a DSP board with a shared memory
> interface to the PC.  I want to use 16 bit transfers for the memory but
> this seems to affect the video card.  I've already assertained that the
> address bits of the auxiliary channel need to be used on the decode for
> this signal (imposing 16 bit transfers on a 128KB page) but what other
> signals need to be incorparated to produce the required decode?  I'm
> using an open collector pull down transistor and a Lattice 2032 for the
> decode logic.  Any help or pointers to where I can get help would be
> appriciated
> 
> John
> 
Article: 7074
Subject: Memory workshop
From: fmeyer@cs.tamu.edu (Jackie Meyer)
Date: 29 Jul 1997 13:08:40 GMT
Links: << >>  << T >>  << A >>
The advance registration deadline for the

  IEEE Workshop on MEMORY Technology, Design, and Testing

draws near, namely

  31 August 1997

Please register in advance if at all possible.

The workshop is in San Jose, August 11-12.

Workshop details are at

  <ftp://ftp.cs.tamu.edu/pub/fmeyer/service/mtdt97/abstracts.html>

Regards,

Jackie Meyer
--
Sorry, we are having sporadic problems with ftp service off site.
Any troubles, just <mailto:fmeyer@cs.tamu.edu>.  Thank you for
your patience.


Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search