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 19825

Article: 19825
Subject: Re: Design security
From: Ray Andraka <randraka@ids.net>
Date: Thu, 13 Jan 2000 14:54:21 GMT
Links: << >>  << T >>  << A >>
WHAT?????

If you've got something that is erasing an external e(e)prom, you've got
pretty big problems with the rest of your system.  Altera OTP FPGAs use
EPROM cells internally to hold their program that are not much different
than the EPROM cell in the configuration prom for SRAM based FPGAs.  SRAM
based FPGAs can also be loaded from other sources than a PROM, especially if
you have a microcontroller/computer connected to them.

 As far as erasing the loaded configuration goes, the configuration
flip-flops in a so-called SRAM FPGA are more robust than those you find in
the fabric or those you will find in other chips in your design.  You'll
have rampant bit failures in the design  long before you start having
failures in the configuration.  The reason?  The configuration flip flops
are designed for retention of the information, not for speed.  Flip-flops in
your design are designed for speed and so become less resistant to upset.

satish_me@hotmail.com wrote:

> Hai,
> Unless you use one time coding FPGA, there will not be any possibility
> of getting high security. The SRAM based FPGA are good for performing
> exercise, such that whether the FPGA meets our necessary requiremnts.
> Once u go for One time coding FPPGAs(Altera.....), ur design have High
> security, unless the FPGA is stolen or Mal functioning.
> This is my view for Design security.......
> In SRAM based, FPGAs the PROM contents can be occupied erased, by any
> power full magnetic filed. This is one of the major disadvantage of
> SRAM based FPGA's.
>
> Satish...
> In article <3878359A.69D0@DesignTools.co.nz>,
>   jim.granville@DesignTools.co.nz wrote:
> > Hal Murray wrote:
> > >
> > > In article <3870B679.D84288FD@ids.net>,
> > >  Ray Andraka <randraka@ids.net> writes:
> > > > The problem with putting an OTP key in the device, is that the
> non-volatile
> > > > cells can't be fabricated without additional process steps.  The
> FPGA
> > > > process is essentially the same as DRAM, which lets it be done
> with bleeding
> > > > edge process.  Put PROM cells on there, and you lose the speed.
> > >
> > > I'm not a silicon guru.  This case is different from a normal
> > > PROM in that we don't need a lot of bits.
> >
> > But you do - the whole config memory needs to go on chip, not just the
> > security bit(s), and  you'll want the config memory re-writable as
> well,
> > otherwise the anitfuse devices are equivalent.
> >
> >  A few bits of write-once is not a big problem - you just arrange a
> > kill-able element.
> >
> >  Gatefield/Actel have FLASH FPGA, but the very leading edge will
> always
> > be
> > RAM based.
> >
> >  A design option for the security paranoid is to split the design
> > between
> > the FPGA, and a sister CPLD - the FPGA can be cloned, but the system
> > cannot.
> > In a QFP44 you can get 64/72 Macrocells, which can be quite a 'lock'
> >
> > - jg
> >
> >
>
> 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: 19826
Subject: Re: fastest 32 bit RISC
From: Ray Andraka <randraka@ids.net>
Date: Thu, 13 Jan 2000 15:13:17 GMT
Links: << >>  << T >>  << A >>


Ulf Samuelsson wrote:

> I do not know the max speed available in current technologies,
> but I simulated a 32 bit ALU and a 32 bit barrel shifter on an Atmel 40K
> FPGA
> architecture which is similar to the Xilinx architecture.
>

I'm not sure I'd call the architectures similar.  Yes they share the 4K pinouts
and configuration protocol and they both utilize 4 input look up tables as the
basic logic block.  After that the similarities end.  The achilles heel of the
Atmel device is the lack of a carry chain, so for things that require arithmetic
or binary counters, the Atmel just can't compete.  A RISC processor is one of
those things.

>
> The critical path was around 250-300 ns for both.
> Since in a real 32 bit processor, this is just part of single stage in a
> processor,
> you will find that high MHz processors are hard to find.
>
> I doubt that you can get 50 Mhz with an FPGA implementation.
> If you are lucky You might get  10-15 Mhz in very advanced technology.
>

I think if you do the design carefully you can get pretty close in some of the
VIrtex and VIrtex E devices.  Alot depends on the instruction set of the
processor.  Jan Gray can probably give you some real bench marks.  I've designed
some 16 bit very simple harvard processors sort of like a simplified PIC that
take up only about 10x10 CLBs in xilinx 4K and will run at 70+ MHz in an XLA-09
part.

You can do a 32 bit barrel shift in 4K in 3 levels of logic (FG-H-FG-H-FG),
which, if floorplanned, will get you to 50 MHz in any of the xilinx 4000XLA
series  parts.  That puppy takes up an area of about 80 CLBs.  It is probably
the most expensive part of the RISC processor, if you even have one in there.

Now, all that said, it doesn't make much sense in most cases to take a
commercial RISC core (ie. an ARM7 core) and plunk itinto an FPGA. You're not
going to get anywhere near the performance the FPGA could be capable of, or of
what a purpose made chip will do, and generally speaking, it is more expensive.
Where the FPGA shines, is when you have a custom process to accelerate.  In that
case, you design a circuit optimized for the particular task, not a general
purpose processor.

>
> Also they will be quite expensive.
> Just the ALU and the barrel shifter is 30 kgates in itself.
> I have seen data on a fullblown 32 bitter indicating about 120k gates
> for a RISC processor.
> An off the shelf ARM7 will be soo much cheaper.
>
> Pretty soon, you can get silicon with a processor integrated
> with the FPGA and then you will have low cost 40-50 MHz.
>
> The 8 bit AVR RISC + FPGA (FPSLIC) will soon do 40 MHz.
>
> --
> This is a personal view which may or may not be shared
> by my employer         Atmel Sweden
> Ulf Samuelsson         ulf 'a't atmel 'd'o't com
>
> Damjan Lampret skrev i meddelandet <85clgf$o03$1@planja.arnes.si>...
> >Hi everybody,
> >
> >does anyone know how fast (in terms of clock speed or/and in terms of
> >performance) and how big is the fastest 32 bit RISC in FPGA (not restricted
> >to any particular FPGA vendor). Processor can be commercial or open source.
> >It would be best if it is with caches and MMU. Thanks.
> >
> >regards, Damjan
> >
> >
> >

--
-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: 19827
Subject: fpga board
From: elynum@my-deja.com
Date: Thu, 13 Jan 2000 15:14:00 GMT
Links: << >>  << T >>  << A >>
I have a xilinx xc400e fpga with 32kx8 sram, 25Mhz clock with parallel
port interface and a 4 digit LED display.  I've basically been working
through the a xilinx lab book with some simple examples like counters,
flip flops, simple fifos and so forth.  I'm looking for ideas as far as
other design things that I can do with this board.  Any suggestions?


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19828
Subject: Re: fastest 32 bit RISC
From: "Damjan Lampret" <lampret@opencores.org>
Date: Thu, 13 Jan 2000 16:14:58 +0100
Links: << >>  << T >>  << A >>
>
> I doubt that you can get 50 Mhz with an FPGA implementation.
> If you are lucky You might get  10-15 Mhz in very advanced technology.
>

Hmm. So something like 100-125MHz is close to impossible?

Check http://www.opencores.org at around 21th January where a 100+ MHz 32
bit RISC with caches and MMU will be published (full VHDL source though
optimized for Virtex).

regards, Damjan



Article: 19829
Subject: Re: HW resources increased
From: Sander Vesik <sander@haldjas.folklore.ee>
Date: 13 Jan 2000 15:45:34 GMT
Links: << >>  << T >>  << A >>
In comp.arch Marinos J. Yannikos <mjy@pobox.com> wrote:
> Sander Vesik wrote:
>> > computers? They must consume an awful lot of power...
>> 
>> They consume no more than "modern" computers and may well consume less
>> power than the desktop computers presently sold.

> But if the CPU cycles are put to any use, dozens of old 386 boxes can
> be replaced by a modern system, eliminating much power consumption.

Not neccessarily. For one thing, there may not be dozens of old boxes,
but just say one or two. A dozen of boxes is most probably not
replaceable by one box, as one box can not be in a dozen different
locations. And it has terribly low redundancy, even if the location
doesn't matter. 

> I won't even switch my old P133 on, since CPU-intensive stuff can run
> better on my newer systems and the P133 would make too little of 
> a difference to justify the power consumption and noise.

But nobody talked about anything "CPU intensive". How CPU intensive
is CPU intensive? 386 is more than a match for many CPUintensive tasks.

If a given box (read: solution) fully coveres the need there is 
absolutely no need for better. Instead of a pentium, I might be
interested in a 386 box that is very small and uses very little
power and is very silent.

> -mjy

-- 
	Sander

	There is no love, no good, no happiness and no future -
	these are all just illusions.
Article: 19830
Subject: Re: PCI Bus Problems with Burst Transfers
From: Dan Rymarz <m261981@boeing.com>
Date: Thu, 13 Jan 2000 16:05:20 GMT
Links: << >>  << T >>  << A >>
DRAM refresh?

Peter Lang wrote:
> 
> Hi to all,
> I am not shure this is the right newsgroup for my problem, but maybe someone
> can give
> me a hint or the name of a better fitting newsgroup.
> 
> We are designing PCI-Framegrabber cards using standard PC-platforms and
> Windows98
> The problem is that the Video Data DMA Burst via PCI-Bus sometimes stopps
> for about
> 30 microsec. While that time alle PCI Data-Transfers are aborted with a
> RETRY termination.
> As a consequence our Video Fifos get a Data Overflow!
> 
> Maybe this is a problem with the cache controller an the motherboard.
> Is anybody dealing with a similar problem?
> 
> thanks
> peter
Article: 19831
Subject: Re: Design security
From: rk <stellare@nospam.erols.com>
Date: Thu, 13 Jan 2000 11:14:32 -0500
Links: << >>  << T >>  << A >>
Steve Rencontre wrote:

> In article <387CB34F.757E9158@xilinx.com>, peter@xilinx.com (Peter Alfke)
> wrote:
>
> > What does it take to dissolve some plastic? Twenty bucks?  Fifteen pound
> > sterling?
> > Looks like a token security to me. Somewhat like the door-lock on my
> > house...
>
> Well, I was under the impression that opening up a chip in such a way
> that it continued to work and could be hacked was a bit more than just a
> matter of dunking it in solvent.

I'll disagree here with Peter, I think it's about $50.  Opening up a chip and
keeping the device functional, for an experienced lab, is not that tough, for
most parts.  There are some devices that are difficult to do, but I've never
seen any troubles with FPGAs.

rk

Article: 19832
Subject: Re: Lattice
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Thu, 13 Jan 2000 09:39:44 -0700
Links: << >>  << T >>  << A >>
elynum@my-deja.com wrote in message <85ijv0$f44$1@nnrp1.deja.com>...
>We have an ISPLSI2128VE Lattice cpld.  It keeps latching up.  The chip
>gets really hot, intermittently. At first, I thought it was the fact
>that we have 2 different power supplies on the board 3.3V and 5V and
>that they were ramping up at different speeds.  Now, I think maybe it is
>something with the chip.  Any suggestions?


Is it programmed with the proper bit stream?

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

Spelling Counts!  You don't loose your money - you lose it.



Article: 19833
Subject: DDC Core for FPGA
From: "Philippe Robert" <PhilippeR@sundance.com>
Date: Thu, 13 Jan 2000 16:43:41 -0000
Links: << >>  << T >>  << A >>
Hi

Does anyone know about an existing DDC (Digital Down Converter) in VHDL or
schematics for an Altera FPGA ?
A DDC is basically of a NCO, a decimator and of an FIR filter.

Thanks.
Philippe.


Article: 19834
Subject: Re: Xilinx Spartan2
From: Greg Neff <gregneff@my-deja.com>
Date: Thu, 13 Jan 2000 18:06:41 GMT
Links: << >>  << T >>  << A >>
In article <387CFE0E.68C97C7D@xilinx.com>,
  peter.alfke@xilinx.com wrote:
(snip)
>
> Xilinx will be offering Industrial grade in the -5 speed grade, but we
> are still
> deciding  on part/package combinations. We are interested in knowing
> which
> parts have the highest demand for I-grade.
> The low price of Spartan is partly due to manufacturing efficiencies
> and inventory management. We could easilyt hurt that cost structure by
> being too generous with Industrial options.
>
> Peter Alfke, Xilinx Applications
>
>

I think that I would be happy with the following devices in industrial
temperature range:

XC2S30TQ144
XC2S50TQ144
XC2S50FG256
XC2S100FG256

This would give us a good range of size and I/O capability.

Does anyone else on this forum need industrial temperature parts?  If
so, which device/package combinations would you like to see?

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19835
Subject: Re: Lattice
From: elynum@my-deja.com
Date: Thu, 13 Jan 2000 18:55:41 GMT
Links: << >>  << T >>  << A >>


Yes, I'm sure we're using the correct bitstream.  Another engineer
has the same part on his board no problems.  On the other board,
occasionally, it latches up.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19836
Subject: Re: Reliability of programming SRAM FPGAs
From: Dan Rymarz <m261981@boeing.com>
Date: Thu, 13 Jan 2000 19:42:47 GMT
Links: << >>  << T >>  << A >>
I don't know, but I been having a bad experience with an Altera 10k.  It
is
on the same JTAG chain as a flash based Altera 7256; which programs
fine, but the 10k loads right once out of 8 times over JTAG (it will be
loaded through the parallel inputs later).

Richard Lamoreaux wrote:
> 
> What is the reliability of the PROM based download programming as
> opposed to FLASH based devices or antifuse devices? I am looking at
> using a Xilinx Virtex device, but I need to have 100% reliability in
> the functionality after the download ends, passes CRC, and comes out
> of tristate. I understand that if the CRC is bad, the device will shut
> down, and that's OK.
> 
> Rich
Article: 19837
Subject: Re: PCI Bus Problems with Burst Transfers
From: "John L. Smith" <jsmith@visicom.com>
Date: Thu, 13 Jan 2000 14:51:41 -0800
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------C1DBB3D133F93F25C5CD0B35
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Thomas Rathgen wrote:
> 
[snip]
> BTW, I don't think the 7164 is the rigth bridge in such design.
> 

Um, don't you guys mean the SAA7146A? and Thomas, what would be
wrong with this chip in a (possibly multi-) frame-grabber?

> Peter Lang schrieb:
> >
> > Here some additional information concerning our Retry problem:
> > We are using the Philips SAA 7164 Multimedia Chip as PCI Master.
[snip]
--------------C1DBB3D133F93F25C5CD0B35
Content-Type: text/x-vcard; charset=us-ascii;
 name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
 filename="jsmith.vcf"

begin:vcard 
n:;me
x-mozilla-html:FALSE
version:2.1
email;internet:jsmith@visicom.com
x-mozilla-cpt:;0
fn:me
end:vcard

--------------C1DBB3D133F93F25C5CD0B35--

Article: 19838
Subject: Re: Reliability of programming SRAM FPGAs
From: Greg Neff <gregneff@my-deja.com>
Date: Thu, 13 Jan 2000 23:18:15 GMT
Links: << >>  << T >>  << A >>
In article <31lq7sga1tskjfor4blhuuo194feltr1an@4ax.com>,
  Richard Lamoreaux <lumpy@rtd.com> wrote:
> What is the reliability of the PROM based download programming as
> opposed to FLASH based devices or antifuse devices? I am looking at
> using a Xilinx Virtex device, but I need to have 100% reliability in
> the functionality after the download ends, passes CRC, and comes out
> of tristate. I understand that if the CRC is bad, the device will shut
> down, and that's OK.
>
> Rich
>
>

The CRC does not 100% guarantee that the PROM contents are OK, but its
very good.  You can probably dig up the info on the polynomial and
figure out what the actual reliability number is.

One thing to watch out for is the data retention spec on the PROM that
you are using.  Some are only good for ten or twenty years (this in an
issue in transportation applications that have an operational life of
30+ years).  The flash based CPLDs that I have seen are specified for
20 years retention.  OTP serial PROMs are supposed to be better than
that, so in this respect you are better off with an SRAM based device
and an external PROM.

I remember when working with fuse based PALs that in rare instances
fuses would "grow" back after a long period of time.  I don't know if
this is still a failure mode for antifuse based FPGAs or not.

Bottom line is you can't guarantee 100% that your FPGA works unless you
test it, because there are many possible failure modes, not just
configuration failure.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19839
Subject: Re: fastest 32 bit RISC
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Fri, 14 Jan 2000 00:19:54 GMT
Links: << >>  << T >>  << A >>
>Ulf Samuelsson wrote:
>> I doubt that you can get 50 Mhz with an FPGA implementation.
>> If you are lucky You might get  10-15 Mhz in very advanced technology.
...
>> ... Also they will be quite expensive. ...

Ray Andraka wrote in message <387DE9AE.7678F6F@ids.net>...
>...  Jan Gray can probably give you some real bench marks.  ...

For starters, Philip Freidin's 16-bit RISC4005 was built with advanced 1990
technology. :-)

The 32-bit J32 (1995) (www3.sympatico.ca/jsgray/homebrew.htm) fit in 60% of
an XC4010-5 and did 16 MIPS at 33 MHz.

My newer small-footprint 16-bit RISC fills 70% of an XC4005XL/XCS10XL and
has a 28 ns cycle time in an 'S10XL-4 (says trce), and that includes several
ns of delays outside the CPU core.  A similar 32-bit version has a 34 ns
cycle time in 60% of an 'S20XL-4.  These results are for the slowest speed
grades of SpartanXLs, which are among the least costly FPGAs sold.  A port
to Spartan2 will be much faster, and cost perhaps a dollar's worth of area.

One key to speed/area performance is selecting a simple instruction set that
is a good match for the FPGA architecture.  (A 32-bit barrel shifter is a
large fraction of the size of a compact 32-bit core, and is rarely
cost-effective when you can build fixed 1-bit, 4-bit, etc. shifters in 0
CLBs (using TBUFs).)

If pure speed (not area) is the goal, then using dual port selectRAM for the
register file, logic (not TBUFs) for the result mux, and assuming a MEM pipe
stage, the processor cycle time can be approximately the max of:

1. time to read the register file operands (time from latching the
instruction) and to write back a result,
2. time for operand register clock-to-out + adder delay + result mux delay +
result forwarding mux delay + operand register setup,
3. time from address register clock-to-out + selectRAM/blockRAM read + max
(result mux delay + etc, tag check).

which for a floorplanned Virtex datapath is not very many ns.

I note the 100 MHz result posting from Damjan Lampret and the opencores.org
folks.  Nice work.  Synthesized even!  Do you floorplan?

Jan Gray
Gray Research LLC



Article: 19840
Subject: Re: HW resources increased
From: "Jeffrey S. Dutky" <dutky@bellatlantic.net>
Date: Fri, 14 Jan 2000 00:33:34 GMT
Links: << >>  << T >>  << A >>
"Marinos J. Yannikos" wrote:
> 
> Sander Vesik wrote:
> > > computers? They must consume an awful lot of power...
> >
> > They consume no more than "modern" computers and may
> > well consume less power than the desktop computers
> > presently sold.
> 
> But if the CPU cycles are put to any use, dozens of old 386
> boxes can be replaced by a modern system, eliminating much
> power consumption.

And eliminating much security as well. I use old 486s (as
well as some old Sparcs) as firewalls and secure X terminals.
Neither task would be well served by consolidating all those
tasks on a single machine. Besides, the 486s and Sparcs were
free (already purchased and depreciated at least) whereas a
new machine would cost new monies.

- Jeff Dutky
Article: 19841
Subject: Re: Reliability of programming SRAM FPGAs
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 13 Jan 2000 16:47:10 -0800
Links: << >>  << T >>  << A >>


Greg Neff wrote:

>
> One thing to watch out for is the data retention spec on the PROM that
> you are using.  Some are only good for ten or twenty years (this in an
> issue in transportation applications that have an operational life of
> 30+ years).  The flash based CPLDs that I have seen are specified for
> 20 years retention.  OTP serial PROMs are supposed to be better than
> that, so in this respect you are better off with an SRAM based device
> and an external PROM.
>

If the difference between 10, 20, and 30 years retention is important to
you, I would contact the reliability department at the manufacturer for
more detailed information. Data retention is temperature dependent, and 20
degree higher or lower average temperature might have a dramatic impact on
retention time.
These are exponential functions.

Peter Alfke, Xilinx

Article: 19842
Subject: Re: Design security
From: steve (Steve Rencontre)
Date: Fri, 14 Jan 2000 03:00 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <387CB34F.757E9158@xilinx.com>, peter@xilinx.com (Peter Alfke) 
wrote:

> What does it take to dissolve some plastic? Twenty bucks?  Fifteen pound
> sterling?
> Looks like a token security to me. Somewhat like the door-lock on my 
> house...

Well, I was under the impression that opening up a chip in such a way 
that it continued to work and could be hacked was a bit more than just a 
matter of dunking it in solvent.

If you know better, I'll take your word for it.

--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk
Article: 19843
Subject: FPGA Design Jobs in Colorado
From: Jon Huppenthal <hupp@rmi.net>
Date: Thu, 13 Jan 2000 20:36:25 -0700
Links: << >>  << T >>  << A >>
SRC Computers in Colorado Springs, Colorado has immediate openings for
several FPGA design engineers. If you have experience with high
performance FPGAs and would like work for a company founded by the
legendary Seymour Cray send your resume' to RPM@SRCCOMP.com. For more
info see our website at SRCCOMP.com. As a pre-public company SRC offers
very competative benefits and salaries as well as founders stock to new
employees.

Join the future of High Performance Computing now at SRC!

Article: 19844
Subject: Re: Design security
From: krw@attglobal.net (Keith R. Williams)
Date: 14 Jan 2000 04:10:37 GMT
Links: << >>  << T >>  << A >>
On Sun, 14 Jan 3900 03:00:00, steve (Steve Rencontre) wrote:

> In article <387CB34F.757E9158@xilinx.com>, peter@xilinx.com (Peter Alfke) 
> wrote:
> 
> > What does it take to dissolve some plastic? Twenty bucks?  Fifteen pound
> > sterling?
> > Looks like a token security to me. Somewhat like the door-lock on my 
> > house...
> 
> Well, I was under the impression that opening up a chip in such a way 
> that it continued to work and could be hacked was a bit more than just a 
> matter of dunking it in solvent.

It's a simple matter that's done every day in FA labs.  
Reverse-engineering a PROM isn't much harder, but it does raise 
the cost to the perp.  Depending on the level of security needed 
both work, or neither. If you wish to keep the NSA out, well...
I'd say the only solution would be to make the application 
totally uninteresting to them. OTOH, if you want to keep a third 
world cloner out a simple DES key on anti-fuse and an encrypted 
payload may easily be enough. 

If you're really paranoid about cloners, a private/public key 
pair could be blown into every part.  I'm not sure the cost is 
justified. My boss is certainly paying enough for FPGAs as it is 
and could care less if anyone steals my design.  My boss is far 
more concerned about when I can get a VirtexEs than trivia like 
protecting the design (it's never going to be a product). 

The FPGA market is a very diverse one and not all want to pay 
more for "useless" gizmos. 

----
  Keith

Article: 19845
Subject: Re: Xilinx Spartan2
From: Mike Butts <mbutts@realizer.com>
Date: Thu, 13 Jan 2000 20:33:28 -0800
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> What are the differences between an XC2S50 (spartan 2) and a Virtex
> XCV50 other than packaging options?

Not much, so far as I can tell.  Footprint of course is different.  CLBs 
and interconnect appear to be identical.  Delay specs are mostly same or a 
little slower than the slowest Virtex.  And the libraries in 2.1i list
all the same primitives for both Virtex and Spartan-II.

Configuration looks identical, except curiously Virtex SelectMAP is
"replaced" by Spartan-II Slave Parallel.  A cursory look says the
pinout and mode pins are the same, so we see little if any difference
there.  No mention in Spartan-II of partial configuration or readback,
but then that wasn't mentioned in Virtex at its intro either.

Here's what Xilinx says on their "Ask Sparty" Architecture page:
> Spartan-II FPGAs are a cost-optimized Virtex architecture designed in
> an 0.18u/0.22u, 6LM process, while Virtex FPGAs are currently in the
> 0.22u, 6LM process. In the first half of 2000, Virtex FPGAs will also be
> available in the 0.18u/0.22, 6LM process. From a price standpoint, the
> Spartan-II family will feature more aggressive pricing than the Virtex
> family. From a feature standpoint, Spartan-II FPGAs are the same as
> Virtex FPGAs with the exception of the low power features. Spartan-II
> FPGAs have replaced the two temperature diode pins found on Virtex
> FPGAs with two pins for low power (powerdown and powerdown
> status). The Spartan-II family will be available in only the most popular
> and lowest cost package parts, which results in lower prices to our
> customers and will share only two common packages with the Virtex
> family, which are the FG256 and FG456 packages   

> Although the Spartan-II devices are based on the Virtex architecture,
> Xilinx does not guarantee that the Spartan-II devices will be 100%
> bitstream compatible with Virtex devices. 

The price is probably the biggest difference.  Check out XAPP169, which lists
the XC2S200 at $10 in 20K per month volume.

    --Mike
Article: 19846
Subject: Re: fastest 32 bit RISC
From: "Damjan Lampret" <lampret@opencores.org>
Date: Fri, 14 Jan 2000 06:02:04 +0100
Links: << >>  << T >>  << A >>
>
> I note the 100 MHz result posting from Damjan Lampret and the
opencores.org
> folks.  Nice work.  Synthesized even!  Do you floorplan?
>

No floorplanning.

Actually core CPU is not a problem. Caches and MMU slow down entire design
(to something like 100MHz). W/o caches and MMU it would run at 150 MHz. We
are playing with smallest Virtex (so design is efficient in terms of area
size) but fastest speed grade (-6). Complete design also includes SDRAM
controller and UART. Everything in XCV50-6.

regards, Damjan





Article: 19847
Subject: 8259 interrupt controller functionality
From: "Juergen Marquardt" <marquardt.juergen@uumail.de>
Date: Fri, 14 Jan 2000 06:06:56 +0100
Links: << >>  << T >>  << A >>
Hi,
did anyone know or built 8259 interrupt controller functionality
into an FPGA or CPLD?
If commercial, than at low cost for small series.

Regards
Juergen


Article: 19848
Subject: Re: fpga board
From: Ray Andraka <randraka@ids.net>
Date: Fri, 14 Jan 2000 05:22:11 GMT
Links: << >>  << T >>  << A >>
An easier question to answer might be what can't you do.  For example,
there's an awful lot of signal processing that can be done with such a set
up, depending mostly on what kind of sample rates you need to handle.

elynum@my-deja.com wrote:

> I have a xilinx xc400e fpga with 32kx8 sram, 25Mhz clock with parallel
> port interface and a 4 digit LED display.  I've basically been working
> through the a xilinx lab book with some simple examples like counters,
> flip flops, simple fifos and so forth.  I'm looking for ideas as far as
> other design things that I can do with this board.  Any suggestions?
>
> 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: 19849
Subject: Re: DDC Core for FPGA
From: Ray Andraka <randraka@ids.net>
Date: Fri, 14 Jan 2000 05:28:27 GMT
Links: << >>  << T >>  << A >>
I've done several.  What are your requirements such as input sample rate,
SFDR, SNR, tuning range, and decimating filter characteristics?

Philippe Robert wrote:

> Hi
>
> Does anyone know about an existing DDC (Digital Down Converter) in VHDL or
> schematics for an Altera FPGA ?
> A DDC is basically of a NCO, a decimator and of an FIR filter.
>
> Thanks.
> Philippe.

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




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