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 86525

Article: 86525
Subject: Re: Good FPGA for an encryptor
From: Kolja Sulimma <news@sulimma.de>
Date: Wed, 29 Jun 2005 17:49:58 +0200
Links: << >>  << T >>  << A >>
Austin,

at FPL2004 differential power analysis on FPGAs was demonstrated.
FPGAs have large capacitive loads on the interconnect that help the
attacker.

This is not true for bit stream encryption, but here the attacker has
the advantage to learn all about your implementation of the algorithm by
experimenting with his own V4 and his own keys first before trying to
crack a foreign key.
Anyway, we are not talking about reverse engineering here, so I do not
care about bit stream encryption. I just want the key stored in the
FPGA. You can do that without opening up the FPGA and without knowing
the bitstream.

I know people who succeed with this approach for most smart cards, which
is a lot harder than for FPGAs because these have logic cells and
interconnect that tries to consume the same power independent of the
data. All differential and so on.

Kolja Sulimma



Austin Lesea schrieb:
> Kryten,
> 
> I disagree:  Virtex 4 FPGAs may be the only really secure means of
> developing a good crypto application.
> 
> What can be more regular than an ASIC?  It is all there, every bit of
> information, to be sliced and diced.
> 
> With an encrypted bitstream in an FPGA, there is an additional level of
> encryption that makes it even harder to crack.  Not only is the design a
> secret, and its implementation, but the attacker does not even know
> where any wires of interest, or any bits of interest are being kept.
> 
> Additionally, security minded companies do not need to have a "secure
> foundry" build their chips:  any foundry that makes the FPGA 'could'
> modify the masks, but that can be easily detected by comparing the FPGA
> with the original mask set (simple inspection).
> 
> Attacks of DPA, flipping individual bits with laser/particle beams, etc.
> all fail due to the immense complexity of the problem.  The FPGA with a
> billion transistors is not a stupid 'smart card' running a simple 8 bit
> uP program than can be easily spoofed.
> 
> I have challenged, and continue to challenge anyone to crack the FPGA
> security (only by breaking it can we make it better).
> 
> To that end, we still have some USB V2 Pro Logic Vault cards that are
> available for serious security hacking.
> 
> Austin
> 
> 

Article: 86526
Subject: Re: Low cost altera board
From: "Hans" <hans64@ht-lab.com>
Date: Wed, 29 Jun 2005 15:56:32 GMT
Links: << >>  << T >>  << A >>

I emailed their support line to see if they can supply the board with a 1C12 
and they replied that an updated 2C20/2C35 is in the make. They offered to 
replace the board as soon as the 2C20/2C35 becomes available (obviously you 
need to pay the price difference :-).

Hans.
www.ht-lab.com

"Tommy Thorn" <foobar@nowhere.void> wrote in message 
news:RB6ue.1566$p%3.12347@typhoon.sonic.net...
> Alex Gibson wrote:
>> Came across this
>> http://www.terasic.com/english/fpga_01.htm
>>
>> Just wondering if anyone has one or has tried one?
>>
>> Designed for multimedia.  EP1C6Q248C8
>> vga , tvout , audio out(line out) , ps2 , rs232 , usb programming
>> cf card , config prom , 16 bit audio , 1MB flash + 8MB ram.
>> Looks quite good for US$149
>
> I dare say.  Run through the getting started manual and it doesn't seem to 
> shabby.  On page 46 they even remind you to take a rest :-) Too bad it's 
> such a tiny FPGA and so little memory.
>
> Tommy 



Article: 86527
Subject: Re: Spartan-3e order of availability?
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 29 Jun 2005 08:59:07 -0700
Links: << >>  << T >>  << A >>
My answers are inserted below.

<oen_no_spam@yahoo.com.br> wrote in message
news:1119869955.246586.18810@f14g2000cwb.googlegroups.com...
> Hi Steven,
>
> What prices can we expect in comparison to Spartan3?
> What prices can we expect in comparison to Spartan3?

For low to medium pin count packages, Spartan-3E is priced at or below a
comparably sized Spartan-3 FPGA.  Spartan-3 is llower cost for high pin
count packages.

> Let's say a XC3S250E compared to a XC3S200 in the same package.

For 2006 delivery, the XC3S250E will be lower cost.

> Will the CP132 package be priced next to the TQ144?

The CP132 package is generally about the same price as the TQ144.

> When XC3E250E components will be available?

The XC3S250E FPGA starts sampling in the September 2005 time frame, after
the XC3S100E and XC3S500E FPGAs.

>
> Thanks,
>
> Luiz Carlos
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.



Article: 86528
Subject: Re: ADPLL for NRZ
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 29 Jun 2005 18:19:05 +0200
Links: << >>  << T >>  << A >>

"Vladislav Muravin" <muravinv@advantech.ca> schrieb im Newsbeitrag
news:YYwwe.8234$mK5.579394@news20.bellglobal.com...

> I think there is a nice book on this subject written by Best.
>
> Here is its full name:
> R. E. Best. Phase-Locked Loops Design Simulation and Applications. The
> McGraw-Hill Companies, New York, New York, 1999

Nice book, but does not really provide ideas about clock recovery. "only"
PLL design.

> What is the maximum NRZ data rate? If it's small enough to be oversampled
by
> higher frequency clock, there could be an alternative implementation.
> You can use a self-resettable NCO which is reset to a seed FTW each NRZ
> posedge / negedge.

Have a look at the USB specs, there is a paper on their homepage which
describes a DPLL vor CDR (clock/data recovery) in USB full speed (12 Mbit/s)
using a 48 MHz clock. I tried to copy their FSM and it didnt work for me,
maybe I messed something up. But my own CDR works fine on USB.

BTW, plain NRZ will not work reliable, you need a minimum transition density
in your datastream. So a least scambling is neccessary (SDH) or NRZI (USB)
or whatever.

Regards
Falk




Article: 86529
Subject: Re: ADPLL for NRZ
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 29 Jun 2005 18:20:50 +0200
Links: << >>  << T >>  << A >>
One more hint.

Have a look at UART designs. This is a very good starting point. Once you
REALLY understood a UART design, you see the major problems. And maybe find
solutions to them.

Regards
Falk




Article: 86530
Subject: Re: Small FPGA
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 29 Jun 2005 18:22:27 +0200
Links: << >>  << T >>  << A >>

"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag
news:42c27017$0$23344$ba620e4c@news.skynet.be...

> Yes, indeed my "style" is more based on FPGA experience.
> What would be the "CPLD" way to code a debouncer ?

A counter and some logic will do. CPLD or FPGA doesnt matter here.

Regarads
Falk




Article: 86531
Subject: Re: Small FPGA
From: Sylvain Munaut <com.246tNt@tnt>
Date: Wed, 29 Jun 2005 18:36:07 +0200
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
> "Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag
> news:42c27017$0$23344$ba620e4c@news.skynet.be...
> 
> 
>>Yes, indeed my "style" is more based on FPGA experience.
>>What would be the "CPLD" way to code a debouncer ?
> 
> 
> A counter and some logic will do. CPLD or FPGA doesnt matter here.
> 
> Regarads
> Falk

The problem is that I need 8 of them + some other stuff,
the debouncers fits but uses most of the 72 macrocells and the price
goes high quickly for more macrocells.


	Sylvain

Article: 86532
Subject: Re: Small FPGA
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 29 Jun 2005 18:55:51 +0200
Links: << >>  << T >>  << A >>

"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag
news:42c2cdce$0$337$ba620e4c@news.skynet.be...

> The problem is that I need 8 of them + some other stuff,
> the debouncers fits but uses most of the 72 macrocells and the price
> goes high quickly for more macrocells.

I assume the debouncers are for push buttons? This can be easyly handled in
a microcontroller. And this is also very cheap.

Regards
Falk




Article: 86533
Subject: Re: Xilinx Virtex 4 device technology
From: "Amr Ahmadain" <amrahmadain@gmail.com>
Date: 29 Jun 2005 10:03:05 -0700
Links: << >>  << T >>  << A >>
Austin,

Thanks for your reply. But does that mean there isn't at least any
consideration to use the SOI technology in the near future in building
your devices? I think they do offer intrinsic performance and low-power
edge compared to bulk CMOS.

Thanks again.!

Amr


Article: 86534
Subject: Re: ADPLL for NRZ
From: "Peter Alfke" <peter@xilinx.com>
Date: 29 Jun 2005 10:08:58 -0700
Links: << >>  << T >>  << A >>
It's time for some basic explanation:
NRZ stands for Not-Return-to-Zero, which means High for 1 and Low for
0. And no clock! How can you recover the clock? It's impossible if the
data can be an endless string of either 0 or 1. So there must be
transitions on which to re-adjust the clock recovery circuit.
One way is to scramble the data, which creates additional transitions
(The very low probability of the scrambler actually eliminating
transitions can be statistically ignored).
Or you re-code the data with additional bits, like 8B10B where 8 bits
of arbitrary data are sent as a 10-bit stream with several transitions
( or 64B66B in a similar way).
After that decision, you know how long the clock recovery circuit has
to coast without re-synchronization. And you can design an analog or
digital PLL to do the clock recovery.
UARTS rely on a start bit before, and usually also one or two stop bits
after the data byte.
The start bit is oversampled, usually 16 times, and the local clock is
supposed to be accurate enough to recover the 8 data bits, until the
next start bit provides re-synchronization.
Peter Alfke


Article: 86535
Subject: Re: Xilinx Virtex 4 device technology
From: "Peter Alfke" <peter@xilinx.com>
Date: 29 Jun 2005 10:14:51 -0700
Links: << >>  << T >>  << A >>
Amr, within a company like Xilinx, there are hundreds of ongoing
considerations and investigations and plans about hundreds of
possibilities. This newsgroup is a public forum, and you should not
expect us to describe all our planned and not planned developments.
Austin and I are reasonably candid, but we also have an obligation to
keep future plans under wraps. This is a competitive field...
Peter Alfke


Article: 86536
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Wed, 29 Jun 2005 19:48:26 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> I have challenged, and continue to challenge anyone to crack the FPGA 
> security

How much is the award? ;-)

> (only by breaking it can we make it better).

Good point. BTW, Austin, why isn't it possible to implement
bitstream encryption on all Xilinx devices? Is the circuit too
complex, i.e. does it consume too much silicon?

> is not a stupid 'smart card' running a simple 8 bit 
> uP program than can be easily spoofed

Well, good smart cards are extremely hard to crack
-- they are explicitely designed to survive an attack,
FPGA chips are not (at least most of them).

    Best regards
    Piotr Wyderski



Article: 86537
Subject: edn macro in ISE
From: "Yaseen Zaidi" <yaseenzaidi@NETZERO.com>
Date: 29 Jun 2005 11:18:51 -0700
Links: << >>  << T >>  << A >>
I like to use a Xilinx written macro (edn) in my design using ISE 6.3.
I seems ISE does not accept edn file. I could not find any
documentation on using edn netlist for ISE. It follows the macro is
little old and older foundation had provision where edn elements could
be instantiated. However, I like to do this for ISE. The edn is
synthesized and optimized netlist. Where in ISE design flow I can have
this netlist recognized and interfaced with existing hdl or netlist
files?

Thanks,


Article: 86538
Subject: Re: Spartan-3e order of availability?
From: oen_no_spam@yahoo.com.br
Date: 29 Jun 2005 11:34:01 -0700
Links: << >>  << T >>  << A >>
Hi Steven,

Thankyou for your answers.

I have another doubt:
At XILINX web site we have:
           TQ144   PQ208   FT256
XC3S200-4  $15.10  $20.25  $25.55
XC3S400-4  $22.00  $25.50  $27.00

I know these prices are for small quantities but, why the package has
so different impact for the two components?
69.2% from TQ144 to FT256 on XC3S200, and
22.7% from TQ144 to FT256 on XC3S400!
Note that both components use all available pins/balls in all mentioned
packages.

If we need a lot of pins, it looks like using two XC3S200-TQ144 is
better than using one XC3S200-FT256. Some more pins, double the logic,
more components = better discount! I know some facts are missing, but I
really never understood why this huge price difference.

Can we expect the same behavior for SPARTAN3E (XC3S250E to XC3S500E) ?

Luiz Carlos


Article: 86539
Subject: Re: Good FPGA for an encryptor
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 29 Jun 2005 20:34:18 +0200
Links: << >>  << T >>  << A >>
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> schrieb im Newsbeitrag
news:d9umt3$6io$1@panorama.wcss.wroc.pl...
> Austin Lesea wrote:
>
> > I have challenged, and continue to challenge anyone to crack the FPGA
> > security
>
> How much is the award? ;-)
>
> > (only by breaking it can we make it better).
>
> Good point. BTW, Austin, why isn't it possible to implement
> bitstream encryption on all Xilinx devices? Is the circuit too
> complex, i.e. does it consume too much silicon?
>
> > is not a stupid 'smart card' running a simple 8 bit
> > uP program than can be easily spoofed
>
> Well, good smart cards are extremely hard to crack
> -- they are explicitely designed to survive an attack,
> FPGA chips are not (at least most of them).
>
>     Best regards
>     Piotr Wyderski
>

Pjotr,

I bet you are not getting much direct answers (about the award) when asking
in public, so let me anser -

if you could today prove that you can with 100% success crack the V2Pro/V4
security by non destructive methods, then

1) you should be VERY QUIET, asking 'how much is the award is already almost
too non-quiet in this matter'
2) get a VERY GOOD lawer

The lawer would negatiote an escrow account for you, up to the sum the cost
of one set of masks, that would be yours only if you keep your mouth shut
forever, covered by some very strict agreement.

If the lawer doesnt get the deal for you, then you did hire the wrong lawer.

Thats my 2 cent opinion.

You think its worth the trial?

I have done the impossible once, but I would spend my time (unless paid per
hour) to crack the V4 security. The impossible I did was an ultimate hack
based on 3 info pieces:

1) satellite position in the sky
2) transponder number eg frequency
3) "has digital audio" with true random keys (non machine generated!)

based on the info above and only on that info without ever seeing the
original device I designed a PCB board with Z80 + 13GALs

my design did learn the random keys in 130 milliseconds, and had implemented
all unknown to me error correction methods and actually proved to have
better error recovery then the original ASIC from Matsushita. When snow did
fall onto the sattellite dishes in Norway then Filmnet was forced to turn
off the keys, as that did bring the signal quality a little better for the
matsushite ASIC, my version tolerated more errors in incoming data.

If I would not achived that task, I would consider it impossible. I have
done some more things in my early childhood, but I would really not spend my
time in attempt to hack the V4 security.

OTOH, I could design a system that makes it possible to use security keys in
RAM based FPGA (without bitstream security), but I dont think I could sell
it, as I am very bad at selling things :(

Antti














































Article: 86540
Subject: Cyclone online store
From: Jedi <me@aol.com>
Date: Wed, 29 Jun 2005 19:05:03 GMT
Links: << >>  << T >>  << A >>
Evening (o;

Besides Altera's own online shop...

...is there a distributor in Europe selling them online as well?


thx
rick

Article: 86541
Subject: Re: Good FPGA for an encryptor
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Jun 2005 12:11:40 -0700
Links: << >>  << T >>  << A >>
Piotr,

See below,

Austin

Piotr Wyderski wrote:

> Austin Lesea wrote:
> 
> 
>>I have challenged, and continue to challenge anyone to crack the FPGA 
>>security
> 
> 
> How much is the award? ;-)

The pride and sense of accomplishment.  Really, no monetary value. 
Heck, I'd buy you a dinner (~ $50 or ~ 50 Euro) just because I'm 
generally a nice guy.

> 
> 
>>(only by breaking it can we make it better).
> 
> 
> Good point. BTW, Austin, why isn't it possible to implement
> bitstream encryption on all Xilinx devices?

Sure.  It is just an IP core.

  Is the circuit too
> complex, i.e. does it consume too much silicon?

Not really complex, but yes, it consumes area.  And since  mroe than 99% 
of present users don't use it, it is not possible that you will see it 
in any product that is price sensitive (ie Spartan).  In products where 
the price is primarily set by the features (ie Virtex), the decryptor is 
a very small part of the pricing (perhaps actually 0).

> 
> 
>>is not a stupid 'smart card' running a simple 8 bit 
>>uP program than can be easily spoofed
> 
> 
> Well, good smart cards are extremely hard to crack
> -- they are explicitely designed to survive an attack,


Yet, the research being done does show that in less than an hour, with 
modest lab equipment, a differential power attack succeeds in finding 
the hidden key value.

> FPGA chips are not (at least most of them).

Well, I don't know about anyone else's FPGA, but Xilinx APD FPGAs 
(Virtex) is designed with security applications in mind.  In fact, we 
have now had more than three annual reviews with the security community 
(academia, experts, users) on just this subject.

Lots of features some people would like to see, and lots of holes that 
need to be plugged up (or thoguht through).  If someone really cared, 
and really spent money on FPGAs for this application, it would help us a 
lot.  Right now, it is something that we spend just enough time on to 
get the basics right, but no more.

We are presently used in many secure applications -- we just don't hear 
about them (they are secret!).  So we do get whispers about what is not 
liked, and what is liked, and what might be next they would like to see.

For example:  3DES is not OK.  256AES is OK.  Poly E-fuse is not OK.  BB 
RAM is OK.  No one ever tells us why (that is a secret).  SO we are so 
far in the OK category ....

Article: 86542
Subject: Re: V4 and NBTI question, again..
From: Ray Andraka <ray@andraka.com>
Date: Wed, 29 Jun 2005 15:43:49 -0400
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Marc,
>
> Contact your FAE for information.
>
> The information packet on this subject states the shift in Vt is 
> reversable.
>
> Austin

As does everything I found in general on NBTI by searching google with 
"NBTI"

-- 
--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: 86543
Subject: Re: edn macro in ISE
From: Duane Clark <dclark@junkmail.com>
Date: Wed, 29 Jun 2005 19:57:11 GMT
Links: << >>  << T >>  << A >>
Yaseen Zaidi wrote:
> I like to use a Xilinx written macro (edn) in my design using ISE 6.3.
> I seems ISE does not accept edn file. I could not find any
> documentation on using edn netlist for ISE. It follows the macro is
> little old and older foundation had provision where edn elements could
> be instantiated. However, I like to do this for ISE. The edn is
> synthesized and optimized netlist. Where in ISE design flow I can have
> this netlist recognized and interfaced with existing hdl or netlist
> files?
> 

If you put the edn files into your project directory (the one with the 
*.npl file), then ISE will find them. They show up as "?" in the sources 
window, just the same as unisim primitives, but they will be found and 
included during translate.

If you want to put the edn files in a different location, then in the 
Translate properties dialog, add the path to the edn files in the "Macro 
Search Path" entry.

Article: 86544
Subject: Re: V4 and NBTI question, again..
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Jun 2005 13:59:08 -0700
Links: << >>  << T >>  << A >>
Ray,

Nice thing about and old well known behavior.  It is old, and well known!

Austin

Ray Andraka wrote:

> Austin Lesea wrote:
> 
>> Marc,
>>
>> Contact your FAE for information.
>>
>> The information packet on this subject states the shift in Vt is 
>> reversable.
>>
>> Austin
> 
> 
> As does everything I found in general on NBTI by searching google with 
> "NBTI"
> 

Article: 86545
Subject: Re: ADPLL for NRZ
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Wed, 29 Jun 2005 17:19:54 -0400
Links: << >>  << T >>  << A >>
Alex,

I apologize for long answer, but I hope it's helpful.

I have read Peter Alfke's response. He's right (as always).

Let's distinguish between clock recovery and the engine / logic which keeps 
lock on a certain clock (PLL).

Clock recovery is done using a certain reference information, which could be 
a timestamp followed by dedicated
processing logic, or even a 0-->1 / 1--> 0 transition, as in our case.

So..... Let's go into UART a little bit. Say, a 18.432 MHz clock oversamples 
an asynchronous input.
Assume the data rate is 115200 bps, which is exactly 18.432 MHz / 60.
Once a falling edge is detected, you reset a counter to 59 or 0  (here : 
seed) and count down or up, respectively.
Once a counter reaches zero or 59, respectively, this is your sampling point 
for the data. So you can sample as much data as you'd like.

Ok, if so far we understand, let's move to the next step.
Let's assume that there is an asynchronous serial interface with any data 
rate up to..... well... 20 Mbps.

Now, NCO (Numerically Controlled Oscillator) is fed with FTW (Frequency 
Tuning Word), which is basically
the value added to N-bit counter each clock cycle. Take a look Analog 
devices, DDS chips, such as AD9954.
They have a very nice explanation of this concept.

Now, going further with NCO and FTW, let's take a look at the example.
Say you have 160 MHz clock and 32 bit NCO, which represents approximately 
37.25 millihertz resolution.
Assume 11.5 Mbps data rate, which corresponds to 0x12666666 AFTER TRUNCATION 
of fractional part.
On negative edge and positive edge of the incoming data NCO accumulator is 
reset to zero and counts.
MSB of an NCO is the recovered clock! Isn't this nice?

This mechanism is something that I implemented with ~135 MHz recovered clock 
up to 11 mbps.

But the problem is when your reference is applied once in a long period of 
time, or there is a "bad" relationship between
the data rate and the higher speed clock, so the sampling point could be 
shifted.
That's why there are scramblers or any other, that ensure that there are not 
more than X consecutive ones or zeroes
so that the distance between consecutive posedges and negedges is sufficient 
to ensure "tracking" after the recovered clock...


Vladislav



Now,
"Alex" <jovajsha@yahoo.com> wrote in message 
news:STxwe.1848$R5.438@news.indigo.ie...
> Vladislav,
>
> Could you please explain to me what did you mean by "reset to a seed FTW"?
> Many thanks.
>
> Alex
> "Vladislav Muravin" <muravinv@advantech.ca> wrote in message
> news:YYwwe.8234$mK5.579394@news20.bellglobal.com...
>> Alex,
>>
>> I think there is a nice book on this subject written by Best.
>>
>> Here is its full name:
>> R. E. Best. Phase-Locked Loops Design Simulation and Applications. The
>> McGraw-Hill Companies, New York, New York, 1999
>>
>> What is the maximum NRZ data rate? If it's small enough to be oversampled
> by
>> higher frequency clock, there could be an alternative implementation.
>> You can use a self-resettable NCO which is reset to a seed FTW each NRZ
>> posedge / negedge.
>>
>> Hope this helps.
>>
>> Vladislav
>>
>> "Alex" <jovajsha@yahoo.com> wrote in message
>> news:4Stwe.1813$R5.506@news.indigo.ie...
>> > Hi,
>> >
>> > I am trying to find some literature of how to design All Digital PLL
> which
>> > would extract clock from NRZ signal. The main problem here is that zero
>> > crossing is not present every bit. Also, does anyone know how to set
>> > digital
>> > filter parameters (in practice) based on loop bandwidth, tracking band
> and
>> > parameters like that? Thanks.
>> >
>> > Alex
>> >
>> >
>> >
>>
>>
>
> 



Article: 86546
Subject: Re: Small FPGA
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 30 Jun 2005 10:52:00 +1200
Links: << >>  << T >>  << A >>
Sylvain Munaut wrote:
> Falk Brunner wrote:
> 
>>"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag
>>news:42c27017$0$23344$ba620e4c@news.skynet.be...
>>
>>
>>
>>>Yes, indeed my "style" is more based on FPGA experience.
>>>What would be the "CPLD" way to code a debouncer ?
>>
>>
>>A counter and some logic will do. CPLD or FPGA doesnt matter here.
>>
>>Regarads
>>Falk
> 
> 
> The problem is that I need 8 of them + some other stuff,
> the debouncers fits but uses most of the 72 macrocells and the price
> goes high quickly for more macrocells.

Then use less :)
A debounce really just needs to remove the unwanted edges, so
you do not need many macrocells/key.
ie Slower clock, and fewer MC is another way.
-jg


Article: 86547
Subject: PPC405 Question
From: "Gladiator" <maleche@gmail.com>
Date: 29 Jun 2005 16:16:05 -0700
Links: << >>  << T >>  << A >>
Hi,

I am working with the PPC405 processor on a Virtex2Pro board and was
wondering if it's possible to access the reservation granule where
reservations for the semaphore instructions <i>lwarx</i> and
<i>stwcx</i> are set?

Your help will be greatly appreciated

Robin Maleche


Article: 86548
Subject: Re: Good FPGA for an encryptor
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Wed, 29 Jun 2005 23:35:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <42C2F26C.2010105@xilinx.com>,
Austin Lesea  <austin@xilinx.com> wrote:
>Not really complex, but yes, it consumes area.  And since  mroe than 99% 
>of present users don't use it, it is not possible that you will see it 
>in any product that is price sensitive (ie Spartan).  In products where 
>the price is primarily set by the features (ie Virtex), the decryptor is 
>a very small part of the pricing (perhaps actually 0).

But not MUCH area.  It's getting into the noise (I doubt it is larger
than a single BlockRAM: the point when it gets significant on the
smaller parts.  Probably significantly smaller).

I suspect that it is mostly 

A: A product differentiator.  It's one of the real reasons to go for
Virtex 4 over ANY other FPGA solution right now.  If you are suitably
paranoid, its really the best out there to my knowledge of the
commodity FPGAs (256b vs 128b AES: 256b papers over a lot of sins,
especially if every instance is given its own key, and using SRAM
instead of EEPROM is IMO, far better for the paranoids).

as well as

B: Not used enough.  It's a very powerful mechanism, and if people
started using it on a more regular basis, it would end up in the
Spartan line. 

>For example:  3DES is not OK.  256AES is OK.  Poly E-fuse is not OK.  BB 
>RAM is OK.  No one ever tells us why (that is a secret).  SO we are so 
>far in the OK category ....

You don't need them to tell you why, its pretty obvious:

AES-256 is approved through Top Secret.  3DES isn't.  So there is at
least hope of getting an instance approved.

256 bit keys paper over a lot of sins in ways that 112 (3DES) and 128
(AES-128) can't.  EG, if each instance has its own key, and through
some miracle-process, the key bits can be read out with 50% accuracy
(half right, half don't know) in a destructive process, the 256-bit
system is still brute-force-proof, but the 128-bit system can then be
brute-forced.

Nonvolatile keys are easy to recover unless you physically destroy the
device (hard to get UL listing for putting Thermite on the chips).
Unless there are severe memory effects (and see above for how severe
it needs to be), you pull the power, wipe the keys, and all is good.


Also, what the spooks would probably want but telling you would
violate what they can say:

Ability to change the key from within the device (no external pins).
An abitiy to do partial reconfiguration from within the device (but
NOT externally) when encryption is active.

Both together would probably make the JTRS crowd unbelievably happy.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 86549
Subject: Re: Small FPGA
From: "Peter Alfke" <peter@xilinx.com>
Date: 29 Jun 2005 16:36:54 -0700
Links: << >>  << T >>  << A >>
If you need to debounce 8 switches, you might want to use a common
anti-bounce delay cicuit.
Accept any activation of any key, but immediately start a delay circuit
that ignores all key level changes.  That should suppress the bounce.
Peter Alfke




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