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 86450

Article: 86450
Subject: Re: good bye nios (o;
From: Jedi <me@aol.com>
Date: Tue, 28 Jun 2005 14:26:33 GMT
Links: << >>  << T >>  << A >>
Ben Twijnstra wrote:
> Hi Rick,
> 
> What about Arrow?
> 

One of the worst distributors here besides Memec...
Can try..but takes probably at 1 or 2 weeks until
they reply (o;


rick

Article: 86451
Subject: Re: Two Verilog FSM style compare
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 28 Jun 2005 07:50:32 -0700
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:


> So... you should make the entire design in just one always block? :-)

It can be done.

http://www.designabstraction.co.uk/EXAMPLE/HTML/verilog.htm

     -- Mike Treseler

Article: 86452
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 16:59:04 +0200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> with some trick a RAM based FPGA can be made secure as well but
generically
> its nogo for security related stuff

No tricks.

> XP10 is available. When I asked a disti (WBC) where I could get XP, the
> answer was "from me", ie the disties are able to ship immediatly.

And what is the price of LFXP3? This chip seems to be very promising
and if it is less than 30$, it would be perfect.

> I guess, any comment: "comparable to Quartus" is understood as
> VERY bad insulting comment in the Xilinx side of the world.

:o)))

Quartus is extremely good (but quite slow), especially the full version,
and since Xilinx is a really big player, I anticipate that their software is
also very good, however I have no experience with ISE. It's a compliment,
not an insulting comment. ;-)

> expensive, yes expect any V4 to be >=100USD

Too much for this application.

    Thank you for your comment, Piotr


Article: 86453
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 17:06:20 +0200
Links: << >>  << T >>  << A >>
Vladislav Muravin wrote:

> In the past, we had to choose FPGAs for ASIC prototyping and I was greatly
> disappointed by Altera tools

Well, I'm amazed by Quartus. :-)

> Yes, Altera tools, but not FPGAs! FPGAs are always extraordinary stuff,
> regardless of their vendor!

ProASIC+ LEs cannot compute multi-input xors -- big disappointment. :-(
Only one RAM read port: even bigger disappointment.

> yet it still has some completely useless warnings.

Generally, I prefer 100 not important warnings than the lack of one,
important. :-)

> If you are not planning massive production and you need only a few units,
> think no further.

Today I need only a prototype, but I am not planning mass production, at
most 1000 devices in the best case.

    Best regards
    Piotr Wyderski



Article: 86454
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 17:14:16 +0200
Links: << >>  << T >>  << A >>
allanherriman@hotmail.com wrote:

> I'm curious.  Why do you need an FPGA with bitstream encryption?

Because I need a safe place to store the symmetric key. The
best option would be to store it inside the chip, but it can't be
done using a SRAM-based device. So the best I can do is to
store it in an external encrypted memory. But since the device
has volatile configuration memory, the decoder (and its key!)
must also be encrypted. The best soulution would teleport
the key from a smartcard directly into the FPGA, but no such
technology is available... ;-)

    Best regards
    Piotr Wyderski



Article: 86455
Subject: Re: Good FPGA for an encryptor
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 28 Jun 2005 08:18:47 -0700
Links: << >>  << T >>  << A >>
Comment:

-snip-

  >>expensive, yes expect any V4 to be >=100USD
> 
> 
> Too much for this application.
> 

Virtex 4 in the smaller parts (LX15, LX25, FX12) are all less than $100 
(based on forward pricing in quantities, see the various press releases).

If this is a hobby project, then you are better off going to the Xilinx 
web store and buying a Spartan 3 (or buying the Digilent S3 pcb complete).

Austin

Article: 86456
Subject: Re: Good FPGA for an encryptor
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 28 Jun 2005 17:20:49 +0200
Links: << >>  << T >>  << A >>
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> schrieb im Newsbeitrag
news:d9roji$rlv$1@panorama.wcss.wroc.pl...
> Antti Lukats wrote:
>
> > with some trick a RAM based FPGA can be made secure as well but
> generically
> > its nogo for security related stuff
>
> No tricks.
>
> > XP10 is available. When I asked a disti (WBC) where I could get XP, the
> > answer was "from me", ie the disties are able to ship immediatly.
>
> And what is the price of LFXP3? This chip seems to be very promising
> and if it is less than 30$, it would be perfect.

I dont have pricing handy, but from face to face talk, the Lattice person
promised to meet any Xilinx S3 price for comparable density for EC, and XP
is projected 10% more than EC. Well there was a small misunderstanding at
the conversation, when I mentioned the S3-1000 price then Lattice said at
first that they would not get that price, but he heard me wrong, I said 16,
and it was understood a 6 (EUR), so as per Lattice direct promise they have
no problems with 16EUR price for a device that is comparable to s3-1000, but
they would not give it for 6 :(

I can not guarantee what price you will actually get, but check them out.
Notice that the only device from XP currently available is XP10. Just say
that your target price is $30 and force them (nicely) to meet the price. As
they don not have any other silicon to offer rigth now as XP10 I am sure you
will get XP10 priced to meet your target price.

> > I guess, any comment: "comparable to Quartus" is understood as
> > VERY bad insulting comment in the Xilinx side of the world.
>
> :o)))
>
> Quartus is extremely good (but quite slow), especially the full version,
> and since Xilinx is a really big player, I anticipate that their software
is
> also very good, however I have no experience with ISE. It's a compliment,
> not an insulting comment. ;-)
>
> > expensive, yes expect any V4 to be >=100USD
>
> Too much for this application.
>
>     Thank you for your comment, Piotr
>



Article: 86457
Subject: Re: proth siever in FPGA?
From: "Alex" <alex@greenbank.org>
Date: 28 Jun 2005 08:22:09 -0700
Links: << >>  << T >>  << A >>
Thanks Ben!

>From my existing testing the inner loop will be iterated all 50,000,000
times on >99.9% of runs. Even if I do one loop per clock cycle (highly
unrealistic) on the 50MHz Spartan-3 I' looking at one test per second
per siever, and only 512bits going in and out of the siever per test.

There's no memory access whilst in the main loop so I mind if it's a
bit
slow grabbing data or returning results.

As for the memory the main chip (XC3S200FT256) has 12 18kbit block
RAM (216K bits) the board comes with a 1M-Byte SRAM (in two 256Kx16
chips) on the back. No SDRAM to worry about.

Ta. -Alex


Article: 86458
Subject: Re: Good FPGA for an encryptor
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 28 Jun 2005 08:25:46 -0700
Links: << >>  << T >>  << A >>
Good point:

A lot of folks get the issues of security and encryption all mixed up.

Why, in fact, do you need anything at all?

Best to start from the beginning, and build your requirements from the 
basics.

What is needed?  Do you need to authenticate (is this the system to whom 
I am speaking....)?  Do you need to pass secure keys (update keys in an 
insecure channel)?  There are many things which are really nice, and 
clever, but are they needed?  Who is the attacker?  Will they have 
physical access?

I am guessing that Piotr has thought all this through, so I will not 
question his requirements.

If local secure storage is required for information (pads, session keys, 
etc.), and the attacker has physical access, then one way to maintain 
security is to use a device with encrypted bitstreams, as readback is 
prohibited when the decryptor is being used (in V2, V2P, V4).

Austin

Piotr Wyderski wrote:

> allanherriman@hotmail.com wrote:
> 
> 
>>I'm curious.  Why do you need an FPGA with bitstream encryption?
> 
> 
> Because I need a safe place to store the symmetric key. The
> best option would be to store it inside the chip, but it can't be
> done using a SRAM-based device. So the best I can do is to
> store it in an external encrypted memory. But since the device
> has volatile configuration memory, the decoder (and its key!)
> must also be encrypted. The best soulution would teleport
> the key from a smartcard directly into the FPGA, but no such
> technology is available... ;-)
> 
>     Best regards
>     Piotr Wyderski
> 
> 

Article: 86459
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 17:27:24 +0200
Links: << >>  << T >>  << A >>
Rudolf Usselmann wrote:

> What cypher are you going to use ?

128 bit AES and a good hashing method to generate "session" keys.
 
> We are getting about 20 Gbps in a Virtex 2 3000, for 1Gbps
> you can get away in a Spartan 3.

Exactly, even the smallest Cyclone, 1C3-8, would perform
this task easily. But there is no way to send the key securely
to the FPGA and hence my favourite FPGA family can't be
used.

> My guess is that you can do 1 Gbps in any low cost/low end
> FPGA with the right architecture ...

The problem is not with a proper implementation, I can do
it easily, but with the word "any". ;-) Any low cost SRAM
-based FPGA has enough performance, but there is no way
to store the key securely (there's no "secure environment"
and no secure communication channel between the scrambler
and a smart card, so I can't just send the key and I can't
send an encrypted version of the key, because the majority
of available chips is unencrypted, i.e. it's impossible to
implement a secure key exchange protocol). Flash-based
and SRAM-based devices have no such problem, you can
store the "auxilary" key(s) inside the chip.

    Best regards
    Piotr Wyderski



Article: 86460
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 17:38:24 +0200
Links: << >>  << T >>  << A >>
Laurent Gauch wrote:

> Piotr wants to do crypto in the FPGA. Also, he certainly needs secret 
> keys inside the FPGA for working with digital crypto (speudo). Piotr 
> needs FPGA bitstream encryption to make sure the secret key is safe

EXACTLY! :-)

> and to protect his design and encryption method !

Well, there's no need to protect these parts of my design.
Only the secret key must be stored in an extremely secure
location, because there's no way to change the key.

    Best regards
    Piotr Wyderski 



Article: 86461
Subject: Re: Good FPGA for an encryptor
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 28 Jun 2005 17:41:22 +0200
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag
news:d9rpon$lbe1@cliff.xsj.xilinx.com...
> Comment:
>
> -snip-
>
>   >>expensive, yes expect any V4 to be >=100USD
> >
> >
> > Too much for this application.
> >
>
> Virtex 4 in the smaller parts (LX15, LX25, FX12) are all less than $100
> (based on forward pricing in quantities, see the various press releases).
>
> If this is a hobby project, then you are better off going to the Xilinx
> web store and buying a Spartan 3 (or buying the Digilent S3 pcb complete).
>
> Austin

Hi Austin,

I think my estimate was more realistic, it is for the small volume project
(at least the way I understood the OP) and I did mean pricing as of today.
Sure the prices for the devices you mentioned do fall below $100 margin,
some day in some qty. But for buying small qty of V4 as of today I would
expect near 100$ pricing or am I mis understanding the pricing policy? I
dont remember seeing V4 price forecasts going much lower than $80 USD for
5-10k yearly volumes. Sure I would welcome a lower pricing :)

as of 1 off testing, it sure makes sense to buy a low cost kit for
evaluation, here are you absolutly right

Antti



Article: 86462
Subject: Re: FPGA for video processing
From: "Lee" <leejal@comcast.net>
Date: 28 Jun 2005 08:49:28 -0700
Links: << >>  << T >>  << A >>
How much do you want to spend?
Which brand of FPGA (Altera or XIlinx)?
What other features needed - DVI in/out Analog out?
I am working on a board with DVI  In/out, RGB analog in/out,
It will have 2, Xilinx 3S400's on it.


Article: 86463
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 17:52:42 +0200
Links: << >>  << T >>  << A >>
allanherriman@hotmail.com wrote:

> 'Doing crypto' does not imply a requirement for bitstream encryption.

Of course, but...

> One needs to change the keys from time to time

... here it is impossible. No frequent key updates,
no forward secure protocols, nothing can be used.
Only a secure key storage is allowed, which means 
a physically secure storage, i.e. storing the key
in an FPGA or at least an external, unprotected
storage with encrypted contents.

> so they can't be part of the bitstream.

Unencrypted bitstreams can be modified (it doesn't mean
reserse engineering of the chip, just simply modify several
bits of the bitstream and update the CRC) and then the
"enemy" can analyse the errors produced by the chip to
reconstruct the key. It's one of the simplest methods of
breaking (wanna be) secure devices -- no extensive
number crunching etc., is needed, just "inject" some bugs
into the chip, record the results and then extract statistical
correlations between the errors and the key bits.

> IP protection makes sense

There's no particularly valuable IP to protect.

    Best regards
    Piotr Wyderski



Article: 86464
Subject: V4 and NBTI question, again..
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 28 Jun 2005 17:53:57 +0200
Links: << >>  << T >>  << A >>
Hi

Xilinx answer record 21127 and related information, - I am still a little
unsure if I did understood it all correctly and what the actual impact of
the NBTI issues actually are.

I have had some trouble with DCM lately, so I am little bit more worried,
AR21127 says that if the V4 is powered but not configured the DCM
performance will start to degrade (there are actuall changes of the
silicon!), but this process is reversable, like self healing so if the V4 is
later powered and configured for the same amount of time then DCM
performance will slowly be restored to be inside the specification again.
We have a design were we really can not guarantee that the V4 is configured
withing 10 minutes from power on, as the bitstream is on removeable media
and the media may not be inserted or may not contain a valid bitstream. I
also have 2 LX25 based boards and both have been poered and not configured
for some time, I wonder if I should start healing the boards or maybe the
DCMs have not been damaged at all.

So a direct question:

The DCM performance degration when powered and not configured, is it damging
the silicon or not? And if it is, is it fully self healing (unlimited number
of times, unlimited time of being powered and not configured) or is there
some limit how many times the V4 can self heal itself?

or maybe somebody has a better explanation how to understand this issue.

Also little more worring is the fact that AR21127 promises the 'workaround'
macros for V4 for the case of low DCM input frequency to be available in mid
June, but they are still not available, its now 28 june in Europe I guess
its past 'mid-June' on the US westcoast as well.

Is there anyone around who could clarify the issue once and for all? Austin,
can you comment please?

Antti




Article: 86465
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 18:01:52 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Virtex 4 in the smaller parts (LX15, LX25, FX12) are all less than $100 

Still three times too much, Virtex4 chips are just to big,
the goal is to design a device with the price of less than
~$70 @ 1000 specimen. But this must include a smart
card, a small PCB, several connectors and wires etc.,
so the chip should cost below $30.

> If this is a hobby project

Well, it isn't, or better: it should not end up as a non-profit
project. It's current status is "small research project". 

    Best regards
    Piotr Wyderski



Article: 86466
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 18:08:38 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Best to start from the beginning, and build your requirements from the 
> basics.

I have all of them.

> Do you need to authenticate (is this the system to whom 
> I am speaking....)?

Yes, definitely.

>  Do you need to pass secure keys (update keys in an 
> insecure channel)?

Yes.

> Who is the attacker?

A company with the budget of 20--100k$.

> Will they have physical access?

To the PCB: yes, virtually unlimited, but they
will have no access to the die.

> I am guessing that Piotr has thought all this through, so I will not 
> question his requirements.

Thank you. :-)

    Best regards
    Piotr Wyderski



Article: 86467
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Tue, 28 Jun 2005 18:19:01 +0200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> I said 16, and it was understood a 6 (EUR), so as per Lattice direct
promise
> they have no problems with 16EUR price for a device that is comparable to
s3-1000

16EUR would be perfect, my sweet dreams come true. :-)

> but they would not give it for 6 :(

Actually, I wouldn't either. :-P

Thank you Antti once again! It seems that I have to find
a Lattice distributor in Poland and purchase a single XP
chip.




Article: 86468
Subject: Re: Good FPGA for an encryptor
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 28 Jun 2005 18:31:24 +0200
Links: << >>  << T >>  << A >>
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> schrieb im Newsbeitrag
news:d9rt9f$6h$1@panorama.wcss.wroc.pl...
> Antti Lukats wrote:
>
> > I said 16, and it was understood a 6 (EUR), so as per Lattice direct
> promise
> > they have no problems with 16EUR price for a device that is comparable
to
> s3-1000
>
> 16EUR would be perfect, my sweet dreams come true. :-)
>
> > but they would not give it for 6 :(
>
> Actually, I wouldn't either. :-P
>
> Thank you Antti once again! It seems that I have to find
> a Lattice distributor in Poland and purchase a single XP
> chip.
>
check the disti, yes. but you are bette off to by the XP low cost eval
board. the XP10 you would get in BGA and it doesnt makes sense togo doing
anything with it.

and íf you have some FPGA then you can simple test your design on whatever
you have ready and at the same time verify that your design is also
synthesizeable for XP using lattice tools.

BTW the lattice tools look almost 100% the same as xilinx tools as they are
both based on Neocad :)

Antti




Article: 86469
Subject: V4 and NBTI answer
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 28 Jun 2005 09:37:52 -0700
Links: << >>  << T >>  << A >>
Antti,

As usual, I will answer your questions below,

Austin

Antti Lukats wrote:

-snip-

> So a direct question:
> 
> The DCM performance degration when powered and not configured, is it damging
> the silicon or not?

No, no damage at all.  It is the classic NBTI Vt shift of the pmos 
devices (trapped charges).  This is 30 years old.  Nothing new here, 
except that the DCM balance for high frequency operation (anything 
greater than 300 MHz falls into this category because of the new 
differential balanced delay lines) is affected by non-use (ie the DCM is 
stuck at 0, or stuck at 1).  The effect is slight, and only affects the 
DCM for high frequency mode.  It also requires a high ambient 
temperature (like 85C).  It also requires time.  Any interruption or 
change allows recovery.


  And if it is, is it fully self healing (unlimited number
> of times, unlimited time of being powered and not configured) or is there
> some limit how many times the V4 can self heal itself?

Unlimited.  The time to shift back is roughly equal to the time to 
shift.  The more shifting that goes on, the more the shift diminishes, 
and actually stops (becomes a total non-issue, all charge traps are 
filled).  Just leaving the device unpowered allows shift back as well. 
The only way we were able to affect the operational specifications was 
in the burn in (>1000 Hrs, all Vcc's at ABS MAX, temp at ABS MAX). 
Taking one of these devices after burn-in, and using it for awhile, made 
it meet specifications again...

> 
> or maybe somebody has a better explanation how to understand this issue.
> 
> Also little more worring is the fact that AR21127 promises the 'workaround'
> macros for V4 for the case of low DCM input frequency to be available in mid
> June, but they are still not available, its now 28 june in Europe I guess
> its past 'mid-June' on the US westcoast as well.

Don't know about the availability of the macros.  I do know that some of 
it is now built into the software (so you don't even need to know).

The need for the work-around macros diminshes as we see that this issue 
is probably a complete NON ISSUE.  Obviously, anyone who thinks they 
will be subjetc to this, please contact your FAE to discuss it in full. 
  The last 10 discussions have resulted in "no problems" so I doubt you 
are affected, but one can never be sure.

> 
> Is there anyone around who could clarify the issue once and for all? Austin,
> can you comment please?

Just did my best.  As for 'once and for all,' I doubt I am that good. 
Anything more?


Article: 86470
Subject: WTB FutureElectronics Cyclone NiosII Kit
From: "John Cain" <jjcain@ppilabs.com>
Date: Tue, 28 Jun 2005 09:55:11 -0700
Links: << >>  << T >>  << A >>
I am looking for a Future Electronics Cyclone NiosII Development Kit with a
1C12 Cyclone FPGA. It was on sale last month for $50 and sold out. Please
respond to ppilabs@yahoo.com.




Article: 86471
Subject: Re: V4 and NBTI answer
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 28 Jun 2005 18:58:39 +0200
Links: << >>  << T >>  << A >>
Hi Austin

you are pretty good ! :)
nothing more at the moment, thank you,

Antti


"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag
news:42C17CE0.5040101@xilinx.com...
> Antti,
>
> As usual, I will answer your questions below,
>
> Austin
>
> Antti Lukats wrote:
>
> -snip-
>
> > So a direct question:
> >
> > The DCM performance degration when powered and not configured, is it
damging
> > the silicon or not?
>
> No, no damage at all.  It is the classic NBTI Vt shift of the pmos
> devices (trapped charges).  This is 30 years old.  Nothing new here,
> except that the DCM balance for high frequency operation (anything
> greater than 300 MHz falls into this category because of the new
> differential balanced delay lines) is affected by non-use (ie the DCM is
> stuck at 0, or stuck at 1).  The effect is slight, and only affects the
> DCM for high frequency mode.  It also requires a high ambient
> temperature (like 85C).  It also requires time.  Any interruption or
> change allows recovery.
>
>
>   And if it is, is it fully self healing (unlimited number
> > of times, unlimited time of being powered and not configured) or is
there
> > some limit how many times the V4 can self heal itself?
>
> Unlimited.  The time to shift back is roughly equal to the time to
> shift.  The more shifting that goes on, the more the shift diminishes,
> and actually stops (becomes a total non-issue, all charge traps are
> filled).  Just leaving the device unpowered allows shift back as well.
> The only way we were able to affect the operational specifications was
> in the burn in (>1000 Hrs, all Vcc's at ABS MAX, temp at ABS MAX).
> Taking one of these devices after burn-in, and using it for awhile, made
> it meet specifications again...
>
> >
> > or maybe somebody has a better explanation how to understand this issue.
> >
> > Also little more worring is the fact that AR21127 promises the
'workaround'
> > macros for V4 for the case of low DCM input frequency to be available in
mid
> > June, but they are still not available, its now 28 june in Europe I
guess
> > its past 'mid-June' on the US westcoast as well.
>
> Don't know about the availability of the macros.  I do know that some of
> it is now built into the software (so you don't even need to know).
>
> The need for the work-around macros diminshes as we see that this issue
> is probably a complete NON ISSUE.  Obviously, anyone who thinks they
> will be subjetc to this, please contact your FAE to discuss it in full.
>   The last 10 discussions have resulted in "no problems" so I doubt you
> are affected, but one can never be sure.
>
> >
> > Is there anyone around who could clarify the issue once and for all?
Austin,
> > can you comment please?
>
> Just did my best.  As for 'once and for all,' I doubt I am that good.
> Anything more?
>

:) no, question answered!

Antti





Article: 86472
Subject: Re: proth siever in FPGA?
From: "JJ" <johnjakson@yahoo.com>
Date: 28 Jun 2005 11:17:49 -0700
Links: << >>  << T >>  << A >>
Slightly off topic since I don't know this proth sieve

If you are interested in trully huge primes, perhaps the mersenne
primes search might be something to consider as background material.

If you google comp arch group for FPGA Mersenne you should find a
recent (1-2 month or so) mention about an engine that did huge 64 bit
int FFTs on I think 2^24 points, this is used to do huge number
arithmetic in shorter order. It used 384 18.18 muls on biggest V2Pro to
drive the FFT kernal. The 64b math was needed to prevent loss of
accuracy to do these huge muls needed for prime checking. The math was
mostly beyond me but the FPGA HW was quite interesting.

Ofcourse it turns out the memory management was the real problem here,
if you can imagine doing a 2^24 pt 64 precision FFT.

This must be some sort of Uni assignment right?
better than what I was offered

johnjakson at usa dot com


Article: 86473
Subject: Re: V4 and NBTI question, again..
From: Ray Andraka <ray@andraka.com>
Date: Tue, 28 Jun 2005 16:19:47 -0400
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

>Hi
>
>Xilinx answer record 21127 and related information, - I am still a little
>unsure if I did understood it all correctly and what the actual impact of
>the NBTI issues actually are.
>
>I have had some trouble with DCM lately, so I am little bit more worried,
>AR21127 says that if the V4 is powered but not configured the DCM
>performance will start to degrade (there are actuall changes of the
>silicon!), but this process is reversable, like self healing so if the V4 is
>later powered and configured for the same amount of time then DCM
>performance will slowly be restored to be inside the specification again.
>We have a design were we really can not guarantee that the V4 is configured
>withing 10 minutes from power on, as the bitstream is on removeable media
>and the media may not be inserted or may not contain a valid bitstream. I
>also have 2 LX25 based boards and both have been poered and not configured
>for some time, I wonder if I should start healing the boards or maybe the
>DCMs have not been damaged at all.
>
>So a direct question:
>
>The DCM performance degration when powered and not configured, is it damging
>the silicon or not? And if it is, is it fully self healing (unlimited number
>of times, unlimited time of being powered and not configured) or is there
>some limit how many times the V4 can self heal itself?
>
>or maybe somebody has a better explanation how to understand this issue.
>
>Also little more worring is the fact that AR21127 promises the 'workaround'
>macros for V4 for the case of low DCM input frequency to be available in mid
>June, but they are still not available, its now 28 june in Europe I guess
>its past 'mid-June' on the US westcoast as well.
>
>Is there anyone around who could clarify the issue once and for all? Austin,
>can you comment please?
>
>Antti
>
>
>
>  
>
Antti, you can download the verilog macro from the website.  In order to 
get the VHDL one, you have to ask.  The VHDL one is not really ready, it 
has a number of things in it that won't synthesize properly under 
synplify.  Both versions use a pair of counters that are asynchronously 
reset by a level on the incoming clock.  The design has some potential 
metastability hazards, and because of the set up, I suspect won't detect 
clock presence reliably with higher frequency clocks.  The design is 
also a little on the resource intensive side, and can be made quite a 
bit smaller by rethinking the clock detection and using a shift register 
for saving the calibration constants rather than lut ram (eliminates the 
addressing and decodes).  The other issue is that you really need to 
jump through hoops to keep the macro from getting trimmed out during map 
if it is for an unused DCM.  The patch in 7.1 puts the macro in after 
map, so that it doesn't get trimmed out, however, if the other gotchas 
in 7.1 are forcing you to 6.3 then you need to come up with a null DCM 
on your own (there is supposedly a strategic patch for 6.3, but I have 
not been able to find it yet)..  Either way, you need to load a 
bitstream right away to avoid the NBTI all together.

The function of the macro is actually rather simple.  Basically, it has 
a clock sense circuit that detects missing clock in and missing feedback 
(you don't need the feedback detect logic if you are doing the feedback 
inside the FPGA).  The sense logic in the macro is a little hokey, and 
uses more area than it needs to.  A state machine basically waits for no 
clock to be detected, then it reads the DRP port on the DCM at addresses 
42h, 51h and 4Eh and stores them in LUT RAM.  It then writes "0000" to 
4E, apparently this shuts off the DCM outputs, and then it cycles 
through 4 states in sequence that write values alternately to 42 and 
51.  These apparently tweak the internal calibration to keep the delay 
lines toggling.  It continues to cycle through those 4 states until 
clock is restored (or reset is released).  When that happens, it writes 
the stored values for 42,51 and 4E back into the DRP port, triggers a 
DCM reset and goes back to the initial state.  I rewrote the macro using 
srl16s for the drp value storage (this eliminates the addressing logic), 
and used my own clock detection circuit that cuts the clock detection 
circut size to less than 30% of the original.  I also cleaned up the 
state machine so that it is a single machine rather than a 
conglomeration of smaller machines. The clock for the detect circuit is 
a ring oscillator divided down to about 8 Mhz.  Xilinx routes it on 
local routing rather than on a clock net, probably to avoid using up 
clock nets for designs that use a lot of clocks.  I also made a null DCM 
macro which basically removes the clock detect logic, and alters the 
reset logic.


-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 86474
Subject: INFO:Par:252 - The Map -timing placement will be discarded
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Tue, 28 Jun 2005 16:47:13 -0400
Links: << >>  << T >>  << A >>
Hello,

I get a strange INFO message in ISE 7.1 that i have not got in ISE 6.x

------------------------------------------------------------------------------------
INFO:Par:252 - The Map -timing placement will be discarded and your design 
will
be placed using the command line options specified in PAR.

------------------------------------------------------------------------------------

Can somebody explain to me why it is discarding timing driven packing & 
placement?
Could it be that the highest place and route effort overrides timing driven 
packing & placement?

Thanks

Vladislav






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