Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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? > > JeffArticle: 62426
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
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
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
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
Hi,
I'm looking for pointers for on dynamic digital systems design. any help
appreciated.
Thanks
Article: 62431Hello, > 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. EricArticle: 62432
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 AlfkeArticle: 62433
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, SriramArticle: 62434
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 AlfkeArticle: 62435
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
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
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
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 AlfkeArticle: 62439
"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? RalphArticle: 62440
"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
> 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
"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
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"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. -- glenArticle: 62445
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 BittleArticle: 62446
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. : :MarkusArticle: 62447
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 AlfkeArticle: 62448
> 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
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:
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