1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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/

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

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

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