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

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

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

Custom Search

Messages from 56425

Article: 56425
Subject: Re: ANN: Confluence -> Python for Hardware Verification
From: jjl@pobox.com (John J. Lee)
Date: 05 Jun 2003 01:38:43 +0100
Links: << >>  << T >>  << A >>
tom1@launchbird.com (Tom Hawkins) writes:
> I've search the net many times, but have never found a good
> open-source block diagram editor -- a tool that is not only
> invaluable for hardware design, but also very practical for
> software applications, especially hard real-time systems.
[...]

Not sure if this is some technical EE use of the phrase 'block
diagram', but if not, I assume you've tried dia?

I only played with it for about 5 minutes, but it seemed to do some
useful stuff.


John

Article: 56426
(removed)


Article: 56427
Subject: defparam (Synthesizable or Not?)
From: muthu_nano@yahoo.co.in (Muthu)
Date: 4 Jun 2003 20:46:39 -0700
Links: << >>  << T >>  << A >>
Hi,

Is "defparam" is synthesizable or not? I have tried with xilinx XST.
But it is giving some errors.

So, currently i am passing parameters with #().

Any one used defparam in the design?

Regards,
Muthu

Article: 56428
Subject: Xilinx Block RAM
From: muthu_nano@yahoo.co.in (Muthu)
Date: 4 Jun 2003 20:55:25 -0700
Links: << >>  << T >>  << A >>
Hi,

In all Xilinx block RAM Primitives, they have allocated Parity bits (1
per byte) for each locations. If we see the 32bits with RAM,
additional 4 bits being provided for the Parity.

In most of the cases, we are not using this. This is because, all our
RAM is internal, there is not possibility of data corruption.

If this is the case, why they have provided that parity bits.

Regards,
Muthu

Article: 56429
Subject: Re: Is it possible to simulate Nios designs with Quartus?
From: "War pawn" <warpawn@sympatico.ca>
Date: Thu, 5 Jun 2003 00:18:44 -0400
Links: << >>  << T >>  << A >>
"Jesus Jimenez" wrote in message

> designs, so my question is: is it possible?
>

I'm not too sure what your problem might be, but the answer is yes as I was
doing so last year this time (with up to 3 Nios' in a system on apex20ks).
I was using Nios 2.0 with Quartus 2.0 and then 2.1.  It's been a while but I
remember something about a whole lot of (I'm guessing) initialization
instructions that have to be carried out, and then your program afterward.
If you used the c compiler it just gets worse.

So I'd say try simulating for a longer time as a start.  you should also
take a look at where nios is fetching from.



Article: 56430
Subject: Re: An FPGA is flying to Mars
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 05 Jun 2003 00:23:26 -0400
Links: << >>  << T >>  << A >>
rk wrote:
> 
> rickman wrote:
> 
> > rk wrote:
> >>
> >> Bob Perlman wrote:
> >>
> >> >>There are also FPGAs on the way to Saturn on the Cassini
> >> >>spacecraft.
> >> >
> >> > I'm pretty sure some FPGAs that I RMA'd a while back ended up
> >> > going to Pluto.
> >>
> >> That's probably a bit doubtful as no spacecraft has yet gone to
> >> Pluto and none are en route.  There is one project that is going
> >> to go to Pluto but it's still in the early stages (the early
> >> stages can last a while ;-) and hasn't yet had it's Critical
> >> Design Review.  Perhaps what you RMA'd was for a development
> >> project for a mission to project and those sorts of things go back
> >> many, many years.
> >
> > I think you need to reread his message with a smiley (possibly
> > winking) at the end.  RMA means "Return Material Authorization" and
> > is usually used to return defective parts.
> >
> > Sometimes I think we have too many engineers in this group.  ;)
> 
> No, just thought that perhaps he was involved in one of the many Pluto
> development projects.
> 
> We of course know that all of the RMA'd parts get sent to Mars.

Perhaps you are right.  And all the EOL'd parts go to Venus!  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 56431
Subject: Re: FPGA's an Flash
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 05 Jun 2003 00:32:40 -0400
Links: << >>  << T >>  << A >>
FE wrote:
> 
>     Sorry Peter but I think you can say your product are better because you
> have more sales. Most of the time the selection of a part is historical.
> What I mean is if a company use fpga supplier Y for their old product, they
> have 99% of the chance they will use a fpga supplier Y part for their new
> product whatever the technology is the best or not because they have the
> tools (no learning curve), they have volume price discount on all fpga
> supplier Y parts independently of the volume target of this new project,
> they have good relationship with the supplier/rep/distributor, ...
> 
>     If people would switch company each time a product from one company is
> better then an other, I think you would have been in bankrupt in around 1994
> when you had your 4000 family product with your stupid tool who wasn't able
> to route anything against altera 8000 family with it easy tool max+plusII.
> 
>     Most of the time, when a company start, they select the designer's known
> fpga supplier (not necessarly the best technology) at the startup moment and
> stick with it for the rest of their life.

Actually I know of many companies that do switch parts depending on even
just a few dollars in price.  I worked at a telecom test equipment maker
who would see which company made parts that would fit a new design. 
Even if they were already buying a given part for another project, they
would still get bids on both their's and the competion's parts.  Often
this would beat the price down a few more dollars.  Or if parts were
new, sometimes too new to be available, they would get prices that lost
money for the makers until a new process came online which they knew
would turn them a profit.  Once the new process never came on line and
they kept selling the older, more expensive part at the lower price,
loosing money, or at least not making much.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 56432
Subject: Re: Clk between multiple boards
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 05 Jun 2003 05:42:11 -0000
Links: << >>  << T >>  << A >>
>I have a question about clock synchronization between multiple boards.
>I'm trying to capture data from one board on to another. For this I
>will need the clocks to be synchronized, which I'm unable to do. What
>would happen if I did the following :
>
>I connect the outputs from one board to the inputs of the 2nd board. I
>run the 2nd board at the same clock speed as the 1st board (but use
>the individual board's clocks). Meanwhile, I also take the clk from
>board 1 as an input to board 2. Now I try to capture data in board 2
>using clk from board 1 as an enable signal.
>
>What are the pitfalls using such a design ?

How are you going to meet setup/hold with that enable signal?

Do you want to transfer data at full speed?  Or just occasionally?

If just occasionally, then treat the clocks as asynchronous.
Run a do-it signal from board 1 to board 2 in parallel with
your data word. When the data is ready, flap that wire.  It
clocks the data into a buffer and sets a ready flag.  Run
that flag through the normal synchronizer.

If you need to run at full speed, then you need a FIFO.  Since
the clocks are the same frequency the FIFO can be tiny.  I think
Xilinx has an app note describing this case - or maybe a friend
just showed me this trick.  I think the min size is 4 words.  You
start things up running the FIFO half full.  That lets you drift
a word in either direction and still have a full cycle of setup/hold.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 56433
Subject: Re: Xilinx Block RAM
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Thu, 5 Jun 2003 17:47:19 +1200
Links: << >>  << T >>  << A >>
"Muthu" <muthu_nano@yahoo.co.in> wrote in message
news:28c66cd3.0306041955.76ef7d8d@posting.google.com...
> Hi,
>
> In all Xilinx block RAM Primitives, they have allocated Parity bits (1
> per byte) for each locations. If we see the 32bits with RAM,
> additional 4 bits being provided for the Parity.
>
> In most of the cases, we are not using this. This is because, all our
> RAM is internal, there is not possibility of data corruption.
>
> If this is the case, why they have provided that parity bits.

I assume you mean Spartan 3 Block ram.

You don't need to use that extra bit for parity you can use it for whatever
you like.

How about a processor with 9 bit instructions? 9 bit wide ram might just fit
your design nicely. Or perhaps 8 bit ram that can be null (as well as 0 ).

Perhaps your FFT works well with 9 bits.

etc
etc

You get the idea.  Parity is just one use of a bit.

Ralph



Article: 56434
Subject: Topic for Masters Project
From: priyal1977@yahoo.com (Priyal)
Date: 4 Jun 2003 23:09:07 -0700
Links: << >>  << T >>  << A >>
Hi,
I am a graduate student in Electrical and Computer Engineering.
I still have 1 more year to graduate.
I want to design hardware which has some practical application. 
I am looking for topics in Digital Design/VLSI on which i can do my final project.
Can anyone suggest some related topics?

Thanks

Article: 56435
Subject: Re: Xilinx Block RAM
From: "Kevin Neilson" <kevin_neilson@removethistextattbi.com>
Date: Thu, 05 Jun 2003 06:10:35 GMT
Links: << >>  << T >>  << A >>
The extra bits turn out to be really convenient in many cases.  I've used
them often for start-of-packet and end-of-packet flags.

If these are intended to be used for parity, I've wondered why Xilinx didn't
build in a hard-core parity generator/checker.  For high-speed applications,
you have to pipeline the parity-check logic, and then use a lot of flops to
delay the RAM output.

-Kevin

"Muthu" <muthu_nano@yahoo.co.in> wrote in message
news:28c66cd3.0306041955.76ef7d8d@posting.google.com...
> Hi,
>
> In all Xilinx block RAM Primitives, they have allocated Parity bits (1
> per byte) for each locations. If we see the 32bits with RAM,
> additional 4 bits being provided for the Parity.
>
> In most of the cases, we are not using this. This is because, all our
> RAM is internal, there is not possibility of data corruption.
>
> If this is the case, why they have provided that parity bits.
>
> Regards,
> Muthu



Article: 56436
Subject: Re: defparam (Synthesizable or Not?)
From: "Kevin Neilson" <kevin_neilson@removethistextattbi.com>
Date: Thu, 05 Jun 2003 06:12:40 GMT
Links: << >>  << T >>  << A >>
I use defparams with Synplify.  The new Verilog-2001 method of passing
parameters by name with the # is nicer, though.
-Kevin

"Muthu" <muthu_nano@yahoo.co.in> wrote in message
news:28c66cd3.0306041946.37cce689@posting.google.com...
> Hi,
>
> Is "defparam" is synthesizable or not? I have tried with xilinx XST.
> But it is giving some errors.
>
> So, currently i am passing parameters with #().
>
> Any one used defparam in the design?
>
> Regards,
> Muthu



Article: 56437
Subject: Galois Fields Applications
From: "Kevin Neilson" <kevin_neilson@removethistextattbi.com>
Date: Thu, 05 Jun 2003 06:19:55 GMT
Links: << >>  << T >>  << A >>
I've been studying Galois fields, and I wondered if this branch of
mathematics has any other application besides forward correction encoders
(and maybe encryption circuitry).  Galois lived a long time ago; did he have
any use in mind for his fields?  Would they just be a curiosity if not for
error correction?
-Kevin



Article: 56438
Subject: Re: Galois Fields Applications
From: H. Peter Anvin <hpa@zytor.com>
Date: 4 Jun 2003 23:45:02 -0700
Links: << >>  << T >>  << A >>
Followup to:  <eiBDa.1133510$S_4.1168146@rwcrnsc53>
By author:    "Kevin Neilson" <kevin_neilson@removethistextattbi.com>
In newsgroup: comp.arch.fpga
>
> I've been studying Galois fields, and I wondered if this branch of
> mathematics has any other application besides forward correction encoders
> (and maybe encryption circuitry).  Galois lived a long time ago; did he have
> any use in mind for his fields?  Would they just be a curiosity if not for
> error correction?
> 

"Maybe" encryption theory?  AES is based on Galois fields, you know...

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 56439
Subject: Re: Antifuse and CCC FPGA
From: H. Peter Anvin <hpa@zytor.com>
Date: 5 Jun 2003 00:57:44 -0700
Links: << >>  << T >>  << A >>
Followup to:  <Xns938FF21F0A61Crk@199.184.165.240>
By author:    rk <stellare@NOSPAMPLEASE.erols.com>
In newsgroup: comp.arch.fpga
> 
> But you know before it leaves the programmer and gets on the board.  The 
> reliability after passing programming is quite excellent.  If you had to 
> test on the board for the 2-3% dropout then that would be bad.  As an 
> aside, something I've looked into, fault coverage pre-programming for 
> antifuse FPGAs can be quite excellent through on-chip test support.
> 

Sure.  It just means that you have to program (and test) the devices
before board assembly, which isn't possible in all production flows.
Definitely not an issue for everyone, but it is an issue for some
users, and should be kept in mind.

       -hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 56440
Subject: Re: DES-encrypt, Spartan3, was Re: FPGA's an Flash
From: "raymund hofmann" <filter001@desinformation.de>
Date: Thu, 5 Jun 2003 11:33:59 +0200
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag
news:3EDE1BE7.84B46F73@xilinx.com...
> Putting a non-volatile ID number on every chip is not so difficult, but
> it must be redable after the device is packaged ( logistic nightmare
otherwise).
> That readback must be stoppable, otherwise no security.

Why shouldn't there be security ?
Because somebody can then probe the encryption algorithm with different data
until he gets what ?
It shouldn't be known what the decrypted bitstream looks like when residing
in the FPGA memory cells.

> Your suggestion still requires a decryption engine of at least DES
> quality, costing silicon area and thus increasing the price for everybody.

I doubt that this area cost is significant anymore. And it tends to get more
insignificant with time. It's more the cost of designing it / designing the
whole system.
And it's also Customers really buying it.
I suspect that many are talking about it, but much less are really "needing"
it.
Many here (including me) seem to be an example for this.

>
> Regarding key length and relative security:
> The goal should be to cause a "cost of cracking" of $100 000 or more.

Anyway, when this is well done it may get appreciated by cutomers "needing"
more security from "bitstream thiefs" trying to avoid "overkill" by putting
clumsy batteries on their boards.


> unprotected copies). The availability of ever cheaper computer power
> (extrapolated over the next several years) means that the encryption
> algorithm has to be "pretty good" and the key has to be "pretty long",
> and "pretty well hidden" ( no visibly readable fuses ).

I agree that a longer key is better, but hidden ?
Does my thinking have a fatal mistake here ?

>
> Just some thoughts, and why this is more complex than just adding a
> serial number...

And I am no FPGA designer/manufacturer caring about these details. I also
have no ambitions to become one.

Raymund Hofmann



Article: 56441
Subject: ASIC prototype software
From: "Jay" <yuhaiwen@hotmail.com>
Date: Thu, 5 Jun 2003 17:42:31 +0800
Links: << >>  << T >>  << A >>
Hi,
I'm now doing ASIC verification using Xilinx V-II FPGAs, the design has too
many gated clocks for FPGA's global resources.
I know Certify does well on such application, and I want to know is there
any other software capable to do the same job.



Article: 56442
Subject: Multipliers - Ram ratio
From: "Nick Campregher" <nicola.campregher@ic.ac.uk>
Date: Thu, 5 Jun 2003 10:47:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi all,
    what do you think is the most efficient multipliers - Ram ratio to
implment good FIR/IIR filters?

I'd assume the multipliers are 18x18, and the ram blocks will be of around
512 locations.

Thanks very much






Article: 56443
Subject: Re: Xilinx Virtex development board for cPCI
From: "Peter Matthijs" <peter.matthijs@verhaert.com>
Date: Thu, 5 Jun 2003 12:47:37 +0200
Links: << >>  << T >>  << A >>
Hi Mel,
Unfortunately 6U is no option and the Sundance carrier has a PCI-bridge
device connected to the cPCI-bus.
In our design we use a VHDL PCI core to interface with the cPCI-bus,
directly from the FPGA.
Cheers,
    Pete

"Mel" <mels_news@hotmail.com> wrote in message
news:c71e414a.0306041257.1abe4332@posting.google.com...
> Hi,
>
> Sundance do a 3u carrier on which you can plug FPGA daughter cards of
> various sizes (www.sundance.com)
>
> Don't suppose you could go to a 6U rack, as there are a lot of good
> candidates in this format:
> Nallatech do a cPCI 6U carrier with a single XCV2000E and two
> daughtercard sites, each of which can take dual XC2V8000
> daughtercards. (www.nallatech.com)
>
> Mel
>
>
> "Peter Matthijs" <peter.matthijs@verhaert.com> wrote in message
news:<3edda4d4$0$13246$4d4efb8e@news.be.uu.net>...
> > Hi,
> > For the test/debugging of our VHDL designs we're looking for a
development
> > board that has a Xilinx Virtex FPGA directly connected to a compact PCI
> > (cPCI) bus. The board must fit in a 3U 3.3V rack system. The FPGA chip
> > should have at least 1M system gates but if its less then we'll settle
for
> > that.
> > Any research labs that might have this kind of board and are interested
to
> > sell one?
> > If this exists on the market i'm also interested but haven't found it
yet.
> > Thanks,
> >     Pete



Article: 56444
Subject: Re: FPGA's an Flash
From: "Markus Meng" <meng.engineering@bluewin.ch>
Date: Thu, 5 Jun 2003 11:48:22 -0000
Links: << >>  << T >>  << A >>
Hi all,

I finally got a short answer back from a representative of SST regarding SPI
serial data flashes with a read array command of all '0' or all '1'. I'am
pretty
shure it would help if other people would ask them as well to provide this
cmd for FPGA booting ...

below the answer ...

have a nice day

Markus

Here is a partial answer to your question for you:

You are right that the read mode command is 03H but it always has been
on the 25 series devices. The 45 series which was SST's earlier part which
is not a full standard SPI device had FF as the read command.
SST is not producing this part in any other densities. However none of the
data
that our engineers currently have refers to 0x00 as a read command. SST does
indeed acknowledge your point that this would be very valuable as a boot
device
for FPGA. Your comments have been taken seriously and the technical team
will discuss internally about this. If there is an answer in the positive
from the
SST team, we'll be back in touch with you. Thank you for your interest in
SST
and of course the very astute comments!


"Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
schrieb im Newsbeitrag news:TBtBa.35461$3t6.555738@news.xtra.co.nz...
> I don't know much about Semiconductor processes.  But I wonder why it
isn't
> possible to make FPGA's with some flash memory in there, enough to hold 2x
> the bit streams for the FPGA. A little Flash boot section (like CPLDS') of
> FPGA could be used to configure the rest of the FPGA from the Embedded
> flash.
>
> This means you can self configure with a protected bitstream, you can use
> the flash in your application if you like, etc etc.   It also gives you NV
> ram in the FPGA which just can't be a bad thing.
>
> Seems like a simple idea - and a nice setup, is there a big technical
> barrier to such a setup? Is it comming?  Should I have pateneted it? Are
> there already some out there?
>
> Ralph
>
>




-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 56445
Subject: Re: Convolutional Encoder IP: Problem on puncturing
From: Beth Cowie <beth.cowie@xilinx.com>
Date: Thu, 05 Jun 2003 13:43:45 +0100
Links: << >>  << T >>  << A >>
Could you clarify what options you are using for the punctured output.
The core can produce a serial or dual output. If the core is working in
serial mode you need to handle the control signals on the input
carefully as there are 3 bits output for every 2 bits input. If the core
is working in dual channel mode, then the data can be input continuously
but will come out in blocks of 3 two bit outputs input, ie every 4 bits
input to the encoder will produce 3 times 2 bit outputs and the rdy
signal is only asserted every 3 out of 3 clock cycles.
Beth



venex wrote:

> Thanks for your aid.
>
> The rate is 1/2 and with puncturing I obtain 2/3 (The code length is 8
> and puncture code is 11 and 10 (each four bit I keep only the first,
> the second and the third).
> The bits I have indicated in the message are only a short sample.
>
> Best regards.
>
> Venex


Article: 56446
(removed)


Article: 56447
Subject: Re: An FPGA is flying to Mars
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 05 Jun 2003 07:52:33 -0700
Links: << >>  << T >>  << A >>
rk,

One thing that one manufacturer learned the hard way awhile ago was that if
you brag about having your part on the spacecraft before the mission, and
the mission does not go well (ie the hatches blow off too soon, it goes out
of control, and the payload is lost), you might suddenly not want a lot of
attention on whose part it was that was controlling the hatches.....

The problem may have nothing to do with the part.  It may have been an "act
of God" or a design flaw (so who reviewed the VHDL?).  The problem might
have been present before launch, and no one understood what the test results
meant.  (Oh, those little lights mean that the hatches blow off now?)  Who
is to say?  It isn't like you have anything left that you can do failure
analysis on.....or you can get an RMA.

So, when it lands (flys, images, etc) then the bragging might start.  Before
that, we are all a little gun shy after some spectacularly bad
goofs.....that may, or may not have had anything to do with the underlying
technology that we provide.

A successful mission depends on a massive amount of stuff going right, and
absolutely nothing going wrong.  Very little of which actually falls under
the manufacturers control at all.

Austin

rk wrote:

> Mike Butts wrote:
>
> > The May 2003 issue of IEEE Spectrum has a nifty and
> > detailed article on the exciting British Beagle 2
> > lander hitching a ride on ESA's Mars Express orbiter,
> > set to launch soon and arrive in December.
> >
> > Its robotic arm carries a bunch of instruments and
> > other devices.  "Discrete electronic interfaces
> > between each instrument and the lander would have
> > been complex to build and heavy as well.  So the
> > PAW uses a single interface with a field-programmable
> > gate array that can reconfigure itself to match each
> > instrument's needs."
> >
> > Excellent!  One of you must be able to tell us more.
> > Who's the clever designer?  Who's the lucky vendor?
> > What device?  Rad-hard?  Fault-tolerant?  Designed
> > in what language?  Verified how?  Bitstreams stored
> > where and loaded by what?  Can they upload new
> > bitstreams from Earth?  (Now that's an UPload!)
> > What if DONE doesn't go high?
> >
> > Will this be the first FPGA in Mars space?
>
> I don't recall if there were any on Mars Pathfinder but there was
> definitely an FPGA on Mars Global Survey on the laser altimeter.  The
> FPGA got put onto the instrument as it was upgraded; the original laser
> altimeter was on the ill-fated Mars Explorer.
>
> There are also FPGAs on the way to Saturn on the Cassini spacecraft.
>
>
> > Most important of all, will they send a paper to
> > FPL 2003 or FPGA 2004 or FCCM 2004?
>
> MAPLD 2003?  ;-)
>
> --
> rk, Citizen, Noooo Yawk
> "Sometimes when you connect the dots you get a picture.  Other times you
> just have a bunch of dots."
> -- rk, January 23, 2003


Article: 56448
Subject: Re: DES-encrypt, Spartan3, was Re: FPGA's an Flash
From: pqp1978@yahoo.com (EU)
Date: 5 Jun 2003 07:55:01 -0700
Links: << >>  << T >>  << A >>
Hi All...

I really donīt have any decent knowledge in silicon design, but iīm
just wondering...
Even in a standard CMOS process, would it be possible to sneak in some
antifuse(or similar) bits that are write-only? Maybe something like a
public/private key could do the job. The public key could be read from
the device, in order to encrypt the bitsteam, but the decryption
procces would need the private key, wich is not readable.
By the way, I really like the idea of having some level of protection
in the lower costs design, but I think they donīt need to be as good
as the top of line products... My specific needs are that it canīt be
copied by a tecnician in a repair shop.

bye...

Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3EDE21BD.D1E0129B@xilinx.com>...
> Raymund,
> 
> Laser popping of fuses is a well known, and well used technology in low cost
> manufacturing, but as a means of keying the device, pretty lousy security.
> Imagine just popping the lid and examining the blown holes in the polyamide?
> 
> Basically, remember that we really really really want to do what you are
> suggesting, and it isn't for lack of trying, or experimentation, that it isn't
> there.
> 
> We have two issues: no good practical low cost secure way to put keys into a
> standard CMOS process, and very few customers willing to pay a premium.
> 
> Right now we have the feature in V2 and V2P with the battery backed up RAM.
> Cost?  One lithium coin cell, (coind cell holder), a diode, and a capacitor (to
> prevent memory loss when you replace the battery).  Maybe throw in a 1Mohm
> resistor in series to help prevent memory loss if someone shorts out the battery
> while replacing it.
> 
> Not the best solution (I would love to have NVRAM in standard CMOS, too), but

> one that allows folks who absolutely have to have triple DES level encryption to
> succeed.
> 
> Austin
> 
> raymund hofmann wrote:
> 
> > "Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag
> > news:3EDB8423.29CA2C46@xilinx.com...
> > >
> > >
> > > emanuel stiebler wrote:
> > >
> > > > But, anybody out here has an idea, why there is no bitstream encryption
> > > > on the spartan 3 ? With all this gates & memory, you could do impressive
> > > > designs, but to keep them for safe you still have to go to the virtex
> > > > chips ...
> > >
> > > It's really quite simple:
> > > The priorities for Spartan are: Low cost first, features and speed second.
> > > For Virtex the priorities are reversed.
> > > Makes a lot of sense, avoids unproductive overlap, and gives the user a
> > > fair choice.  Cheap or fancy. There is no free lunch...
> > >
> > > Now, if encryption were a popular feature in the low-cost market (please
> > > tell us), then it would make sense to dedicate some silicon and a pin
> > > for the on-chip decryption.
> >
> > Why don't put a kind of "Host ID/Serialnumber" on the FPGA in some kind of
> > "one time programmable" way at Manufacturing the FPGA ?
> > I think Intel CPU's already each have different ID's since some time.
> >
> > I doubt this is a cost/performance penalty like manufacturing a FPGA on a
> > flash-process.
> >
> > This ID can then be used to decrypt a bitstream.
> > And the device should accept two kinds of bitstreams:
> > Encrypted with it's ID + Unencrypted.
> > And this ID should be electronically readeable off the FPGA.
> >
> > I think it is only a matter of time when one FPGA company starts such a
> > thing even for the "low cost" Parts.
> >
> > Of course will the FPGA Customer have to care about generating individual
> > Bitstreams for each device ID of the Part's used, if he wants "security".
> > As there often is a MCU with the FPGA(s) on Board there is additional
> > flexibility in handling the "design security".
> > Or he may choose not to encrypt.
> >
> > Raymund Hofmann

Article: 56449
Subject: Re: Topic for Masters Project
From: Kumaran Selvaratnam <selvars@yahoo.com_NOSPAM>
Date: Thu, 05 Jun 2003 11:08:17 -0400
Links: << >>  << T >>  << A >>
Maybe something like a image processing hardware, encryption engine, 
error control and correction systems, High speed arithmetic systems, 
High speed memory design, etc. Also look at emerging standards.

Good luck.
Kumaran

Priyal wrote:
> Hi,
> I am a graduate student in Electrical and Computer Engineering.
> I still have 1 more year to graduate.
> I want to design hardware which has some practical application. 
> I am looking for topics in Digital Design/VLSI on which i can do my final project.
> Can anyone suggest some related topics?
> 
> Thanks




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

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

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

Custom Search