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 62425

Article: 62425
Subject: Re: Are clock and divided clock synchronous?
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 29 Oct 2003 09:44:21 -0800
Links: << >>  << T >>  << A >>
Jeff,

Read my techXclusive on the web "Does Your Design Have Enough Slack" which
describes how jitter takes directly away from the slack in your timing
budget.

ISE6.1 has new ways that keep track of jitter in the new products, so that
this effect can be carefully kept track of (between clocks from different
DCMs, 1X vs 2X, etc.).

I would say that if you ignore jitter totally, and expect to operate without
any problems, and are pushing any limit (frequency, time, part utilization,
SSO limits) you will be disappointed.

This is not unique to FPGAs or even to any one vendor:  it is a fact of life
that with clock periods approaching 2.5 ns in some designs, 500 ps P-P of
jitter becomes 20% of the entire timing budget!

If the system clock was 10 MHz, and the design was not too exciting, then no
one would care about 500 ps of jitter.

Austin

Jeff Cunningham wrote:

> Google dug up the following quote from Ray back on 2003-04-21.
>
> /quote
>
> I got nailed on an early Virtex design where the 1x and 2x clocks were
> sourced by the same DLL.  Several factors contributed:
> -  the 1x clock was very lightly loaded while the 2x clock was heavily
> loaded,
> - There was fair amount of jitter on the clock input (>300ps IIRC),
> - There was heavy output switching on pins adjacent to the clock input
> pin (adds
> to jitter at DLL clock input)
> - the failing nets were on direct flip-flop to flip-flop connections (no
> LUT) on
> FF's that were floorplanned to be adjacent.
> - static timing indicated no setup or hold violations.
>
> The combination of the jitter (which with input jitter barely in spec
> plus jitter introduced by output current modulation of input thresholds
> was likely out of spec), highly skewed loading (not convinced this is a
> real factor), and the absolute minimum flip-flop to flip-flop delay
> conspired to bite us where it counted.  Since then, we have as a policy
> treated the 1x and 2x clock domains with utmost care to make sure the
> receiver is not sensitive around the transmitter's active edge.  I
> suspect that if you have no direct connects between adjacent slices at
> the clock domain boundary, you won't have a problem.
>
> /unquote
>
> Peter & Austin, I really want to believe you. Do you think Ray's being
> overly careful? Could it be a problem in the "extreme" topology Ray
> describes?
>
> Jeff


Article: 62426
Subject: Re: Virtex-II DCM frequency synthesizer
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 29 Oct 2003 09:46:28 -0800
Links: << >>  << T >>  << A >>
Why do you want feedback?
Your 16 MHz and 52 MHz clocks have strange phase relationships for 3
periods of the 16 MHz and 12 periods of the 52 MHz, until they meet
again every 250 ns. Is it really important to have this one situation
phase aligned, when all the others inevitably are not?

Peter Alfke
=================================
Jay wrote:
> 
> "Evgeni" <evgenist@yahoo.com>
> ??????:82bfabfe.0310281848.3d2812f0@posting.google.com...
> > I'm using Virtex-II DCM frequency synthesizer to get 52MHz clock from
> > 16MHz. Two questions:
> >  1) Since my input frequency is outside the minimum operating range in
> > the low frequency mode(24MHz), I cannot use CLKFB feedback. Is there
> > any easy way to override this restriction.
> double your clock outside
> 
> >  2) I tried doing this freq. conversion without CLKFB using
> > CLKFX_DIVIDE = 4, CLKFX_MULTIPLY=13 parameters. Output is connected to
> > CLKFX. Input is connected directly from external source. I'm measuring
> > 64MHz on that output instead of 52MHz. Is there anything wrong with
> > those particular parameters?
> it seems your parameters are not recognized by the implementation, and the
> default parameters (4/1) are used.
> check your constraints.

Article: 62427
Subject: Re: Are clock and divided clock synchronous?
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 29 Oct 2003 09:46:30 -0800
Links: << >>  << T >>  << A >>
Tim,

Since Virtex everything is fully buffered, Loads can change the timing, but
only very slightly (10s of ps MAX), and not much at all on global clock
buffers.

What gets folks in trouble is what I answered in my other post on this
thread:  they fail to see what their total system jitter is, and add that
to the amount of slack they need.

Austin

Tim wrote:

> Jeff Cunningham wrote:
> > Google dug up the following quote from Ray back on 2003-04-21.
>
> <big snip>
>
> > The combination of the jitter (which with input jitter barely in spec
> > plus jitter introduced by output current modulation of input
> > thresholds was likely out of spec), highly skewed loading (not
> > convinced this is a real factor), and the absolute minimum flip-flop
> > to flip-flop delay conspired to bite us where it counted.
>
> As I recall this discussion and various previous analyses,
> the final concensus was that hugely different loads on the
> two clocks is suspect #1.
>
> If so, is this still (!) the view at Xilinx, and if it is the
> view has the clock buffering changed enough on recent products
> to alter matters?


Article: 62428
Subject: Re: Virtex-II DCM frequency synthesizer
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 29 Oct 2003 09:48:34 -0800
Links: << >>  << T >>  << A >>
Evgeni,

No, you can not use CLKFB below 24 MHz.

The M and D value is not appearing to be set at all (default is X4).

Austin

Evgeni wrote:

> I'm using Virtex-II DCM frequency synthesizer to get 52MHz clock from
> 16MHz. Two questions:
>  1) Since my input frequency is outside the minimum operating range in
> the low frequency mode(24MHz), I cannot use CLKFB feedback. Is there
> any easy way to override this restriction.
>  2) I tried doing this freq. conversion without CLKFB using
> CLKFX_DIVIDE = 4, CLKFX_MULTIPLY=13 parameters. Output is connected to
> CLKFX. Input is connected directly from external source. I'm measuring
> 64MHz on that output instead of 52MHz. Is there anything wrong with
> those particular parameters?
>
> Thanks,
> Eugene.


Article: 62429
Subject: Re: Power calculation using Xpower
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 29 Oct 2003 09:50:03 -0800
Links: << >>  << T >>  << A >>
All,

The power estimate is only as good as your simulation vectors, and their
length.

Short sims, few vectors = bad estimate.

Austin

John Blaine wrote:

> Praveen,
>
> It is difficult to estimate how much impact this will have on the power
> estimate.
> So let me take you through a few points:
>
> Using a post PAR estimate will allow XPower to have an accurate estimate
> of
> capacitance load on the internal routes so no problem here. If you are
> using post MAP
> where no SDF is generated then this is a large source of inaccuracy and
> is not
> recommended.
>
> Now lets look at the timing simulations tend to result in glitches. This
> switching translates
> into higher activity rates in XPower-> higher power.
>
> I would expect these to be fairly low load signals. Also if you have a
> fully synchronous
> design this effect will be limited.
>
> Your clocks will be set correctly (high power consuming nets).
> If you have met timing (verifed through timing analyser) then other
> heavy loaded signals like
> clock enables, should be set correctly.
>
> So in summary, if your design is post PAR, fully synchronous and has met
> timing, you should
> be OK an get an accurate power estimate.
>
> John
>
> praveen wrote:
>
> > hi all,
> >
> > i am calculating the power consumption using xilinx xpower. For
> > generating the VCD file i am not loading the SDF(Standard Delay
> > Format) during VSIM. Will it affect the power calculation.
> >
> > thanks in advance.


Article: 62430
Subject: Reconfigurable Computing Pointers?
From: "Mike" <mjd001@yahoo.com>
Date: Wed, 29 Oct 2003 17:52:37 GMT
Links: << >>  << T >>  << A >>
Hi,
    I'm looking for pointers for on dynamic digital systems design. any help
appreciated.

Thanks



Article: 62431
Subject: Re: LogiCORE PCI-X question
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Wed, 29 Oct 2003 10:09:37 -0800
Links: << >>  << T >>  << A >>

Hello,

> 1. After configuration of BAR's, is there a way for the user
> application code (inside the fpga) to get the BAR's exact value?

No.  Unless you are doing something, well... unusual, your user
application should not care about its absolute address -- only
that it is being accessed.  The LogiCORE PCI-X interface lets
you know you are being accessed, but does not let you see your
absolute address.

> 2. Is there a way to set the BAR's values internally  i.e 
> without a PCI-X configuration cycles ?

In general, no.  However, if you read the chapter in the design
guide about setting core options, you will see there's limited
support for this involving BAR0 and BAR1.

> 3. I would like to use the PCI-X core prior to the host
> configuration.  I.e after appropriate reset phase, I would
> like to assert M_REQ of the core and then I expect the core
> to assert REQ_O. Is this possible?

In that same chapter of the design guide, there is a section
about initiator options.  You can set an option that will allow
you to initiate transfers even before the busmaster is enabled.

Someone else wrote:
> So you're saying you want to initiate a data transfer between
> the time the system reboots and the BIOS assignes BAR values?
> For one, that's a little scarry, and for two, the system bus
> isn't going to be available during that time (where are you
> going to get/send data with no other devices on the bus?)

I would carefully consider what this person wrote, and make
sure you aren't trying to do something that will result in a
system failure.

Eric

Article: 62432
Subject: Re: Are clock and divided clock synchronous?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 29 Oct 2003 10:11:45 -0800
Links: << >>  << T >>  << A >>


Jim Granville wrote: 
>  It does not sound like the adjust steps are an issue from
> Tsu/Th viewpoint, but they _may_ affect a system with a critical
> jitter budget - such as those where jitter == signal to noise
> floor.
>
Jim, if your design is sensitive to 50 ps jitter, it needs an external
clean-up PLL.
Inside a digital chip there will always be some jitter, and on-chip PLL
are not so good either. Jitter is noise in the time domain, and digital
circuits are inherently noisy...

Peter Alfke

Article: 62433
Subject: Fatal Error obtained while translating in xilinx ISE 5.2
From: machosri@yahoo.com (Sriram)
Date: 29 Oct 2003 10:21:49 -0800
Links: << >>  << T >>  << A >>
Hi , 
In my design I had instantiated a multiplier and performed a MAC
(Multiply Accumalate operation using that .
The synthesis step worked but when I try the Implementation , the
translation step fails with the following error.

FATAL_ERROR:NgdBuild:basnbmain.c:1910:1.71.4.1 - Design is empty

If anybody knows the fix to this problem do help me out.

thanks,
Sriram

Article: 62434
Subject: Re: Xilinx Spartan3: Price
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 29 Oct 2003 10:53:41 -0800
Links: << >>  << T >>  << A >>


Petter Gustad wrote:
> Well, if he can team up with 250 of us and make an order of 1000 each
> as a single group we could get the $12 (I guess that is the lowest
> speed grade in the cheapest packet).
> 
Just some perspective:
When I joined Xilinx 16 years ago, the price per LUT was about $1.00
Today it is hundred times lower, at around  $ 0.01
And we are promising another factor 10 in the near future. Not too bad !
BlockRAMs and multipliers and DCMs are thrown in "for free".

BTW, the 3S1000 has about 16 000 LUTs. You do the math.

Peter Alfke

Article: 62435
Subject: Re: Memory for FPGA based LCD Driver/Controller
From: johnhandwork@mail.com (John_H)
Date: 29 Oct 2003 11:11:38 -0800
Links: << >>  << T >>  << A >>
antonis_konstantinos@hotmail.com (Antonis Konstantinos) wrote in message news:<424eaa6b.0310270255.49a377c2@posting.google.com>...
> Hi all,
> 
> I am trying to implement an LCD driver in FPGA which will drive a
> 320x240  color LCD (digital 18bit parallel input).
> 
> Could you please read below and comment if my way if thinking is
> correct or not.
> 
> For two virtual screens to be stored in memory I need 2x320x240x18
> bits = 150k x 18 bits of memory. And this seems impossible with
> Spartans' block ram. So I need an external memory.
> 
> At first I tought that I need a dual port SRAM since a host will write
> to the video memory and the driver will continuously read from that
> memory and feed the LCD. But these RAMs seem to be overpriced (Arrow
> says hundered something dollars for 4mbit memory)
> 
> Then I realised that at 60 Hz driving frequency I only need ~8 Mhz
> clock. Is it possible to use a faster main clock (like 50-60 Mhz
> maybe) and still feed the LCD at 8 Mhz and in the remaining time
> fulfill the memory read/write commands given by the host
> asynchronously?
> 
> If that is true I need a memory capable of achieving around 60Mhz.
> 
> I found the NoBL (or ZBT)SRAMs from Cypress and IDT which can go up to
> 166 Mhz and gives me full bw utilization. (no wait cycles b/w read and
> write). And the good thing is that they also come in x18 organisation
> which is just what I need!
> Digikey says ~$9 for 256kx18 100 MHz ZBT SRAM. 
> 
> Is that memory suitable for my needs or would you recommend any other
> memory?
> 
> Thanks in advance
> Antonis

If you're looking at a volume design, you'll find simple synchronous
SRAM is cheaper than the ZBT or NoBL style memories and can go quite
high in speed for lower cost than the "neat" parts.  4Mbit parts would
fit nicely.  Bus efficiency is great, but why not save 50% if you're
already significantly underutilizing the memory bandwidth?

Martin's idea of SDRAM is pretty neat, too.  You could even get away
with a narrow part (4 bits width?) and burst the data in and out using
the FPGA memory (or SRLs) as temporary buffers.  The pin count is
smaller than SDRAM, possibly saving you FPGA package cost.

You need to get data in and out of the memory at speeds that are
lethargic compared to what the FPGA and memory devices can do, so
leverage the FPGA to handle the overhead *very* quickly and use the
inexpensive memories.

Article: 62436
Subject: Electronic News Article on 90 nm soft error FUD
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 29 Oct 2003 11:13:02 -0800
Links: << >>  << T >>  << A >>
Hello from the SEU Desk:

Peter defended us rather well, but how can one seriously question real
data vs. babble and drivel?

Well, after 919 equivalent device years of experiment at sea level,
Albuquerque (~5100 feet), and White Mountain Research Center (12,500
feet) the Rosetta Experiment* on the 3 groups of 100 2V6000s has logged
a grand total of 45 single soft error events, for a grand total of 20.4
years MTBF (or 5335 FITs -- FITs and MTBF are related by a simple
formula -- mean time between failures vs failures per billion hours or
FITs).

It actual tests done by third parties, it takes from 6 to 80 soft errors
(flips) with about 10 flips on average to affect a standard non
redundant design in our FPGA.  This is just common sense, as for years
ASIC vendors trashed FPGAs as they "use 30 transistors to do the job of
just one!"  Guess what?  What was our "downfall" is now a strength!

True.  So that means that a 2V6000 at sea level gets a logic disturbing
hit once every 200 years.

535 FITs (soft errors affecting customer design) for a 6 million gate
FPGA.

The biggest part A**** makes is 6 times smaller, so for our 2V1000, we
get about 90 FITs.  For a 3S1000, it is 30% better (see blelow), or 63
FITs.  OK A****, tell us what your actual as measured FIT rate is for
your largest device?  Go ahead, I'd like to know.  How many device years
do you have to back it up?  1000 actual years?  Nope.  Didn't think so.

You know, if you want to use FITs, we'll use FITs.  But I am afraid it
will give those spreading nonsense fits (pun intended).

Now if you use triple redundant logic, checksums, ECC codes, you can
design so you NEVER HAVE AN UPSET.

As has been published, Xilinx FPGAs are on the Mars Landers (on their
way there now), so someone is not concerned about upsets.  Even periodic
reconfiguring (scrubbing) eliminates a major portion of the probability
of logic affecting upsets.  Virtex II, and II Pro have ways to actually
check, detect, and correct the flipped bits using the ICAP feature.  For
details, contact your FAE.  If 535 FITs is completely unacceptable for
that critical application you have, this makes it 0 FITs from soft
errors.

Some of our customers have now qualified Virtex II Pro as the ONLY
solution to the soft error problem, as ASICs can't solve it (easily like
we have), and other FPGAs do not have the facts to back up their
claims.  That is quite new:  the Xilinx FPGA is the only safe design
choice to make?  Maybe it is right now, as it is the only choice where
all of the variables are measured, understood, and techniqies exist to
reduce the risk to near zero, or whatever level is acceptable.

Oh, and yes, the 90nm technology is now 30% better than the 150 nm
technology (15% better than the 130 nm technology) as proven by our
tests (as presented to the MAPLD conference last month).

So, you can run around blathering on about data taken by grad students
(no offense, I was one at one time), or you can look at our real time
results from three locations on 300 devices being tested 24 by 7, or
talk to us about our beam tests in protons and neutrons, or ways to
design to get the desired level of reliability for your system.

And, you may want to consider going with the vendor who has been
actively working on soft error mitigation for more than five years now.
And has real results to show for it.

Let Moore's Law Rule!

Austin

*Rosetta Stone was the key that unlocked ancient Egyptian wisdom to the
world.  The stone had an inscription in three languages, which allowed
archeologists to decipher ancient Egyptian writings.  The Rosetta FPGA
Experiment is designed to translate beam testing (proton or neutron)
into actual atmospheric, or high altitude results, without having to
actually build huge arrays of FPGAs and send them to mountain tops
around the world to get real results. It was also designed to answer the
basic questions of altitude effects, position effects, and how smaller
device geometries behave in the real world.


Article: 62437
Subject: Re: Xilinx Spartan3: Price
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 29 Oct 2003 19:25:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp6@gustad.com> wrote:
: "Simon Peacock" <nowhere@to.be.found> writes:

:> they are both correct.. check the volumes field on the Xilinx web site.. its
:> probably 250,000

: Yes. Take a look at the * at the bottom of this page:

: http://www.xilinx.com/prs_rls/silicon_spart/03142s3_pricing.htm

: Well, if he can team up with 250 of us and make an order of 1000 each
: as a single group we could get the $12 (I guess that is the lowest
: speed grade in the cheapest packet). 

If everyone of this team of 250 could contribute one day of lead time we
could also get  in a time frame where the parts are really available on the
market :-)
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 62438
Subject: Re: Xilinx Spartan3: Price
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 29 Oct 2003 11:54:17 -0800
Links: << >>  << T >>  << A >>

Uwe Bonnes wrote: 
> If everyone of this team of 250 could contribute one day of lead time we
> could also get  in a time frame where the parts are really available on the
> market :-)
> 
One minute per team member would be sufficient.  :-)
Peter Alfke

Article: 62439
Subject: Re: Xilinx Spartan3: Price
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Thu, 30 Oct 2003 08:57:13 +1300
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FA00CB5.1766F7F7@xilinx.com...

> Petter Gustad wrote:
> > Well, if he can team up with 250 of us and make an order of 1000 each
> > as a single group we could get the $12 (I guess that is the lowest
> > speed grade in the cheapest packet).
> >
> Just some perspective:
> When I joined Xilinx 16 years ago, the price per LUT was about $1.00
> Today it is hundred times lower, at around  $ 0.01
> And we are promising another factor 10 in the near future. Not too bad !
> BlockRAMs and multipliers and DCMs are thrown in "for free".
>
> BTW, the 3S1000 has about 16 000 LUTs. You do the math.

I Just wonder why the price drops so much between 250k and 1k.

1k  @$200 = $200k
250k  @$ 12 = $3,000k

So he really only needs to find 16 or more people that want 1k to get a
discount, and as a bonus he gets many thousands of free chips.

if he could just find 25 people they would all be buying their 1k @ $120
each and getting 9k free chips.

Why not $50 @ 1k?

Ralph





Article: 62440
Subject: Re: How to protect fpga based design against cloning?
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 29 Oct 2003 20:10:17 GMT
Links: << >>  << T >>  << A >>
"Markus Zingg" wrote:

> While reading diverse articles about fpga's I got the impression that
> they have to be programmed out of a prom or through a microprocessor
> etc. However, this means that it would be very easy to "catch" this
> code in a finished design and abuse it to clone/copy such a design.

One take on this is the actual value of a bitstream and how someone
would/could use it in a commercial application and potential reproduction of
your project.  I've put a lot of thought into this and decided that, at
least for the type of work I'm doing, it's not an issue.  Why?  Because, by
the nature of the designs, if someone were to copy the bitstream with intent
to clone the design (presumably for commercial gain) they'd also have to
design their board exactly as mine.  There isn't a court in the world that
wouldn't favor the original designer when shown that evidence.

In complex designs, where a microprocessor might be running an FPGA as a
peripheral, the commercial value of the bitstream might be reduced even
further.  You could implement all sorts of little tricks to make sure you
can show a judge that the design was stolen from you.  Like, a pin on the
FPGA that, when connected to a PC serial port through a resistor displays a
repeating "STOLEN FROM ..." message.

Without doing much thinking, the only applications that I'd think truly
require bitstream protection might be government/military or when the
requirement is simply dictated down to the design engineer/consultant by the
employer, for whatever reasong (including ignorance).  In those cases Xilinx
has you covered rather well with the triple DES technology and a little $3
battery.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 62441
Subject: Re: Virtex-II DCM frequency synthesizer
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 29 Oct 2003 20:22:15 GMT
Links: << >>  << T >>  << A >>
>  2) I tried doing this freq. conversion without CLKFB using
> CLKFX_DIVIDE = 4, CLKFX_MULTIPLY=13 parameters. Output is connected to
> CLKFX. Input is connected directly from external source. I'm measuring
> 64MHz on that output instead of 52MHz. Is there anything wrong with
> those particular parameters?

DCM's can be a bundle of fun if you don't handle their post-reset behavior
properly.  You have to check the "LOCKED" pin and, if lock is not achieved,
toggle the "RST" pin.

As an example, on a working design, I hold "RST" high for about 10us and
check "LOCKED" about 200us later.  If lock is not achieved the process
repeats.  The reset tree going into the rest of the design is held in reset
until the DCM's are healthy.  Check the data sheets for lock time
information, it isn't instantaneus.

O yeah, critical in the above is to use a "garbage" clock to time the DCM
reset/monitoring function.  Don't make the mistake of using a clock coming
out of a DCM that is being reset or you'll go around in circles for a while.
Who in their right mind would do that, right?  :-(


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 62442
Subject: Re: Xilinx Spartan3: Price
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 29 Oct 2003 22:18:55 +0100
Links: << >>  << T >>  << A >>
"Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> writes:

> if he could just find 25 people they would all be buying their 1k @ $120
> each and getting 9k free chips.

Now I'm starting to understand why I'm such a lousy businessman :-(

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 62443
Subject: Re: Xilinx Spartan3: Price
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 29 Oct 2003 14:28:29 -0800
Links: << >>  << T >>  << A >>
Ralph,

It is also called "forward pricing" because it lets a customer know what it
will cost when they finally go into production a year or so from now.

A real customer doesn't care what it costs right now, because 'right now' is
not when they are going to sell anything.  They want to know what it will cost
when they go into production (along with all of their competitors).  Until
then, they need to budget for the costs, but they are not at all as concerned
about the short terem, as they are about when it is selling, and they are
trying to squeeze the best out of the (potentially thin) margins.

For example, if I know I want to hit the market next Christmas with a new GPS
videogame/handheld/FRS personnal communicator/802.11g (call it Internet
Enabled Star Treck Cache Dragon Hunt*), and I wish to sell 250K units for
$29.95, I need to make the BOM today, get pricing locked in, and be sure that
when I go to build them, I can turn a profit.

The one off price today, or next month is of no value to anyone who is really
in business (other than to let you know how much to write the check for).

Austin


*Game is not patented, or registered, but since I just made it public domain,
I do expect to see three versions of it by next fall.  The unit would
automatically register you on a website as a player, find other players in
your area, assign local FRS channels and tones to the players as teams ("red
vs. blue"), and then send GPS coordinates for "caches" that must be reached
before certain time limits in order to score points.  Once you have arrived at
a cache point, the unit verifies its location, and gets going you off to the
next one.


Ralph Mason wrote:

> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:3FA00CB5.1766F7F7@xilinx.com...
>
> > Petter Gustad wrote:
> > > Well, if he can team up with 250 of us and make an order of 1000 each
> > > as a single group we could get the $12 (I guess that is the lowest
> > > speed grade in the cheapest packet).
> > >
> > Just some perspective:
> > When I joined Xilinx 16 years ago, the price per LUT was about $1.00
> > Today it is hundred times lower, at around  $ 0.01
> > And we are promising another factor 10 in the near future. Not too bad !
> > BlockRAMs and multipliers and DCMs are thrown in "for free".
> >
> > BTW, the 3S1000 has about 16 000 LUTs. You do the math.
>
> I Just wonder why the price drops so much between 250k and 1k.
>
> 1k  @$200 = $200k
> 250k  @$ 12 = $3,000k
>
> So he really only needs to find 16 or more people that want 1k to get a
> discount, and as a bonus he gets many thousands of free chips.
>
> if he could just find 25 people they would all be buying their 1k @ $120
> each and getting 9k free chips.
>
> Why not $50 @ 1k?
>
> Ralph


Article: 62444
Subject: Re: How to protect fpga based design against cloning?
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Wed, 29 Oct 2003 22:30:27 GMT
Links: << >>  << T >>  << A >>

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:J8Vnb.151$t45.14067905@newssvr21.news.prodigy.com...
> "Markus Zingg" wrote:

> > While reading diverse articles about fpga's I got the impression that
> > they have to be programmed out of a prom or through a microprocessor
> > etc. However, this means that it would be very easy to "catch" this
> > code in a finished design and abuse it to clone/copy such a design.

> One take on this is the actual value of a bitstream and how someone
> would/could use it in a commercial application and potential reproduction
of
> your project.  I've put a lot of thought into this and decided that, at
> least for the type of work I'm doing, it's not an issue.  Why?  Because,
by
> the nature of the designs, if someone were to copy the bitstream with
intent
> to clone the design (presumably for commercial gain) they'd also have to
> design their board exactly as mine.  There isn't a court in the world that
> wouldn't favor the original designer when shown that evidence.

My belief is that for most devices, in most markets, with reasonable markups
this is true.

Consider the toy/video game market.  (I don't know if any use FPGA, but they
could.)  The markup is generally very low, using the razor model and making
most of the money off selling the games (software).   In that case, someone
will have a hard time pricing it low enough (assuming one uses cheap foreign
labor, as the cloners would).   Also, the profitable lifetime is short.

Consider the high end scientific/engineering equipment market.   The number
of devices built will be low, and they might be sold with a high markup (to
cover design cost, for example).    Usually, though, support is an important
part of the purchase, and buyers of clone devices wouldn't get any support.
There is also the embarassment of being caught with an illegal device,
especially in a public company.

If your market is primarily in places that have strong copyright laws,  that
is a big part of your protection.  If a large part of the market is in
places with weak copyright laws, then you have to consider other
alternatives.

-- glen



Article: 62445
Subject: Re: How to protect fpga based design against cloning?
From: khimbittle@cliftonREMOVEsystems.com (Khim Bittle)
Date: Wed, 29 Oct 2003 23:47:33 GMT
Links: << >>  << T >>  << A >>
On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch>
wrote:

>Hi all
>
>I don't know too much about fpga's yet so bear with me if this sounds
>too silly. I'm quite interested from what I heard so far and intend to
>dig deeper into the topic.
>
>While reading diverse articles about fpga's I got the impression that
>they have to be programmed out of a prom or through a microprocessor
>etc. However, this means that it would be very easy to "catch" this
>code in a finished design and abuse it to clone/copy such a design.
>
>So, my question is, is my impression right, and if so what common
>protection mechanisms are available? Or are there fpga's available
>that contain flash memory for the purpose of progrmming them on chip
>or such? Some scheme similar to what's available with most
>microcontrollers that contain on chip flash?
>
>TIA
>
>Markus

This is an interesting subject.  I guess there are two concerns:

1)  Theft of the configuration bitstream so that you could clone and
produce identical products.  Obviously the circuitry connected to the
FPGA would have to be a copy and probably not to hard to go after the
bad guys in the courts with copywrite laws etc.  I am more concerned
about #2.

2)  IP Theft.  The question here is ( in the Altera/Xilinx context )
if you record the configuration bitstream what can you do with it as
far as reverse engineering ?  Can anyone reasonably , meaning with
existing tools or software or ... how?,   take this bitstream and
figure out your HDL  ?  I wouldn't know where to start but perhaps
there are some factory or other smart folks here who have a better
insight into this ??  

Khim Bittle







Article: 62446
Subject: Re: How to protect fpga based design against cloning?
From: David R Brooks <davebXXX@iinet.net.au>
Date: Thu, 30 Oct 2003 08:18:53 +0800
Links: << >>  << T >>  << A >>
 As Peter Alfke has pointed out, Xilinx FPGAs can use a 3DES encrypted
bitstream, with battery-backed SRAM in the FPGA holding the key.
 But if batteries are verboten for you, bear in mind that it's one
thing to *copy* a bit stream, and quite another to reverse-engineer it
to a point where one can make useful changes. So the SIM-card idea is
still useful. That idea of shipping the SIM separately to the
end-users, so that the (contract) manufacturer cannot sell units on
the side, also has merit.

Markus Zingg <m.zingg@nct.ch> wrote:

:>You are right, and it is a problem.
:>
:>I have been thinking about it too.
:>
:>Overall I feel there isn't much security in the FPGA chips themselves, but I
:>thought it might be an idea to have a smart card chip (as used in the SIMs
:>for mobile phones). Your FPGA system configures as per normal.
:>
:>It then has encrypted conversation with the SIM (which is a far more secure
:>device), and if it confirms the SIM is valid it works as normal, else it
:>shuts down as you wish.
:>
:>This transfers the problem of cracking from the FPGA to the SIM.
:>
:>The FPGA config can still be ripped off of course, but without the SIM it
:>will be useless.
:>
:>SIMs are pretty small and the carriers are easily available.
:>
:>The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V.
:>(I run my design off 14.3181 MHz, so this is easy to obtain).
:>The SIM reader electronics is easy to implement.
:>
:>You still have to write the verification protocol.
:>Sounds easy but it is not trivial making sure it has no security holes (I've
:>worked with these chips).
:>But easier to make the SIM secure (that's what they were designed for) than
:>the FPGA/config ROM system.
:>
:>If you do manage to implement this, then it opens up a lot of possibilities.
:>
:>The SIM is detachable so you can get your stuff built in say the far east
:>and post the SIMs to the end user by trusted carrier. They can easily
:>install the SIM.
:>You might also make the SIM specific to individual signed config ROMs.
:>Or send upgrade config ROMs with SIMs.
:
:Thanks for your reply. The problem I see with this aproach - provided
:I understood you correctly - is that since the code in the fpga would
:be "open" it could be reverse engineered much easier and the sim part
:could be shorted as a result also. I might sound paranoid - I'm not, I
:just like to know what I'm dealing with. 
:
:The aproach with the Lattice PLD containing flash the other poster
:mentioned seems to be the best to me so far cause this means that a
:cracker would have to physically open the PLD and get down to this
:level where as "listening" on the bus is IMHO a lot easier. I might be
:wrong here, but at least to me the Lattice PLD aproach would be much
:harder to crack.
:
:Well, I'm looking foreward to eventually hear other ideas.
:
:Markus


Article: 62447
Subject: Re: How to protect fpga based design against cloning?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 29 Oct 2003 16:59:02 -0800
Links: << >>  << T >>  << A >>


Khim Bittle wrote: 
> 1)  Theft of the configuration bitstream so that you could clone and
> produce identical products.  Obviously the circuitry connected to the
> FPGA would have to be a copy and probably not to hard to go after the
> bad guys in the courts with copywrite laws etc.  I am more concerned
> about #2.
> 
> 2)  IP Theft.  The question here is ( in the Altera/Xilinx context )
> if you record the configuration bitstream what can you do with it as
> far as reverse engineering ?  Can anyone reasonably , meaning with
> existing tools or software or ... how?,   take this bitstream and
> figure out your HDL  ?  I wouldn't know where to start but perhaps
> there are some factory or other smart folks here who have a better
> insight into this ??
>
The simple answer is that it is impossible, since there is no
documentation about the function of the individual config bits.
The more sophisticated answer would be that is outrageously difficult
and time consuming. After all the detective work figuring out what
millions of individual bit are doing ( or not doing), you finally arrive
at a big unstructured circuit mess. 
Good luck!
I think it is easier to re-invent the functionality than to
reverse-engineer it.

Peter Alfke

Article: 62448
Subject: Re: How to protect fpga based design against cloning?
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 30 Oct 2003 01:27:29 -0000
Links: << >>  << T >>  << A >>
>                   That idea of shipping the SIM separately to the
>end-users, so that the (contract) manufacturer cannot sell units on
>the side, also has merit.

How much of a problem is that?

I'd think that major US based contract manufacturer would be
very careful.  It would be a serious damage to their reputation
if something like that happened and word about it got out.

-- 
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: 62449
Subject: using extra eeprom space
From: "Dave" <gretzteam@hotmail.com>
Date: Wed, 29 Oct 2003 20:29:07 -0600
Links: << >>  << T >>  << A >>
Hi,
I have a design using a spartanIIE and a xcs02f configuration eeprom. The
eeprom is 89% full (apparently it will always be that way even if I have a
larger design). I wonder if the fpga can use the extra 11% to store and read
data. I only need to store something like 10 bytes of data before the fpga
is powered off, and reading it back upon power up.

Rgds
Dave





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