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 102175

Article: 102175
Subject: Re: CoolRunner XPLA3 getting axed?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 11 May 2006 07:31:50 -0700
Links: << >>  << T >>  << A >>
see other postings in this newsgroup - xilinx online shop doesnt carry
any silicon devices any more.

Antti


Article: 102176
Subject: can increase simulation run time while running modelsim?
From: "Subhasri krishnan" <subhasri.krishnan@gmail.com>
Date: 11 May 2006 07:52:11 -0700
Links: << >>  << T >>  << A >>
Hi all,
I use a test fixture to do post-translation simulation on my design.
Is there any way to increase the run time while modelsim is running? or
after it has finished running? Sometimes I need to extend it to just a
few more milliseconds but running it all over again takes about an hour
on my machine. 
Thanks in advance.
Subhasri.K


Article: 102177
Subject: Re: Synplify - Not satisfactory results with re-timing option
From: "Hans" <hans64@ht-lab.com>
Date: Thu, 11 May 2006 14:57:21 GMT
Links: << >>  << T >>  << A >>
Perhaps because retiming in Synplify is using a wireload model? Retiming 
works best when you have accurate delay models, i.e. after P&R (even 
placement info seems to do the trick). Have a look at Physical synthesis 
tools,

Hans.
www.ht-lab.com

"srini" <g.shrinivasan@gmail.com> wrote in message 
news:1147345711.235371.234320@q12g2000cwa.googlegroups.com...
> Hi,
> I had a strange experience with the Synplify Pro 8.4. I used the
> re-timing option thinking that it will help to improve the timing
> performance of the design as they have claimed in their docs. But my
> design's timing performance has gone down by about 5 Mz and I ended up
> not meeting my timing constraints. Why is it so? Can anyone tell me
> about this?
>
> Thanks & Regards,
> Srini.
> 



Article: 102178
Subject: Re: Xilinx warning for DCM
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 11 May 2006 08:51:45 -0700
Links: << >>  << T >>  << A >>
Also,

Be sure you are not using CLK90, 180, 270 CLK2X nor CLK2X_b and CLKDV.

Basically if you use any of the DLL outputs, this restriction does 
apply.  Another easy way to tell is if you are not connecting CLKFB, you 
are OK.  If you have connected CLKFB, then the device wants to use the 
DLL as well as the DFS, and the restriction is back again.

Austin



Peter Alfke wrote:

> Just ignore the warning. You cannot use CLK0, but you are using CLKFX,
> and you specified multiply by 3 and divide by 1.
> Sometimes these warnings are over-eager...
> Peter Alfke
> 

Article: 102179
Subject: Re: CoolRunner XPLA3 getting axed?
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 11 May 2006 17:53:38 +0200
Links: << >>  << T >>  << A >>
Martin Thompson schrieb:

>>What can a Spartan 3E do what a Spartan 3 can't? 
> 
> Configure itself from parallel flash...

OK, nice feature. But not the killer.

> As Jerry Avins on comp.dsp says:
> "Engineering is the art of making stuff you want from stuff you can
> get"

Yeah, this sounds like the original phrase.

Regards
Falk

Article: 102180
Subject: Re: reverse engineering ?
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 11 May 2006 08:57:36 -0700
Links: << >>  << T >>  << A >>
All,

That said, we are not aware of anyone who has ever reverse engineered a 
Virtex device bitstream (unencrypted).

There have been inquiries to vendors 'who do this for a living' and they 
have refused to quote on anything larger than a Virtex 1000 class 
(V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e).

It seems that they feel it isn't worth the headaches.  Not that it isn't 
"possible."  But then, it is "possible" I could visit the moon.

As for once the bit stream has been encrypted (since Virtex II, 6 years 
and counting), no one has broken it (3DES).  And they have been trying.

More than one outfit.

It is even more unlikely that a direct attack on the newer 256 bit AES 
encryption with battery backed up keys will also be able to succeed.

Austin

fpga_toys@yahoo.com wrote:

> binaryboy wrote:
> 
>>is it easy to reverse engineer ASIC/FPGA ?
>>do u have any reference for this ?
> 
> 
> Easy is VERY relative to ones experience and resources. The straight
> forward answer is that it's probably very very hard for you since you
> are asking. For most mortals ASICs are also very very hard as well, and
> relatively easy for those that do it every day for a living (requires
> some signficant investments in equipment and training).  FPGAs with
> built in crypto are a little tougher nut to crack, but far easier than
> ASICs .... still takes some special equipment but far less work.
> Standard FPGA bitstreams for most FPGAs requires a two step process,
> first finding the map for the device (which may require reverse
> engineering some vendor tools first) then writing a netlist generator
> using the map from the bitstream. This requires the least skill, and
> can be done by most mortals that understand programming at an
> undergraduate level and basic FPGA architecture in somewhere between a
> few weeks to a few months for someone fairly bright and skilled, a bit
> longer if they have a difficult time playing deductive reasoning games
> or lack programming experience. Turning the extracted netlist into a
> usable readable design for modification or clean room specification is
> fairly linear in time by it size ... which can be significantly reduced
> if your reverse engineering tools can "reverse compile" the netlist
> into a higher level form, such as good high level VHDL/Verilog or C.
> 
> There are professionals that do reverse engineering for a living ... we
> find that the experience from each project greatly helps develop the
> skills/experience for the next.
> 
> You might find boomerang on sf.net interesting ... binary ISA streams
> are about the same difficulty as unencrypted bitstreams, with the minor
> twist that most FPGA bit streams are undocumented, forcing a two step
> learning curve.
> 

Article: 102181
Subject: Re: CoolRunner XPLA3 getting axed?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 11 May 2006 09:41:02 -0700
Links: << >>  << T >>  << A >>
ispLever  includes all you need.
the cable can be made out of wires similarly as xilinx cable III
or you may buy a ready made cable for 65 usd or as a better
deal machXO starterkit for 99 USD (includes the cable)

Antti


Article: 102182
Subject: Re: CoolRunner XPLA3 getting axed?
From: "bart" <bart.borosky@latticesemi.com>
Date: 11 May 2006 09:56:09 -0700
Links: << >>  << T >>  << A >>
> Thanks for the info.  Is the ISPLever - Starter equivilent to the XIlinx
> Webpack?

Ditto to what Antti says on ispLEVER Starter plus a couple of links...

Yes, ispLEVER Starter is a web downloadable version of ispLEVER for
Windows, which you can download here:
http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm

ispLEVER Starter supports the ispMACH 4000V device, among others.

> Also what tools do I need for In system Programming?
The programming tools are called ispVM, which you can download here:
http://www.latticesemi.com/products/designsoftware/ispvmsystem/index.cfm

Both downloads are complimentary, but you will need to register for
Lattice web account prior to downloading these tools.

Regards,
Bart Borosky, Lattice


Article: 102183
Subject: Re: sqrt(a^2 + b^2) in synthesizable VHDL?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 11 May 2006 13:27:22 -0400
Links: << >>  << T >>  << A >>
Marko S wrote:
> Thank you all. I will have a look at "Dijkstra's square root". I have 2000 
> clock cycles at 40 Mhz to complete the calculation (It should be enough). It 
> is used for calculating the AM envelop after demodulating the signal with a 
> coherent detector
> 
> 
> 
> You can se the principle of the detector at 
> http://www.cycom.co.uk/art1.html.
> 
> 
> 
> 
> 
> "Symon" <symon_brewer@hotmail.com> wrote in message 
> news:4462fbb4$0$15793$14726298@news.sunsite.dk...
> 
>>"Michael Schöberl" <MSchoeberl@mailtonne.de> wrote in message 
>>news:4462f354$1@news.fhg.de...
>>
>>>Marko S schrieb:
>>>
>>>>How do i calculate sqrt(a^2 + b^2) in synthesizable VHDL?
>>>>The signals a and b are 32 bit signed fix point numbers 
>>>>(std_logic_vector (31 downto 0)).
>>>
>>>how accurate? how fast? latency?
>>>
>>>just for the sqrt(x) I once worked an idea to take len=ceil(log_2(x)) by 
>>>counting the length of x (leading 0s) ...
>>>then you shift x>>(len/2) or something (+1?) ... this worked as a good 
>>>approximation and I added only one or two stages of a newton-raphson
>>>
>>
>>Hi Marko,
>>For square root, you could use  modified Dijkstra's square root.
>>
>>http://lib.tkk.fi/Diss/2005/isbn9512275279/article3.pdf
>>
>>One clock per output bit. No multipliers.
>>
>>HTH, Syms.
>>
> 
> 
> 

You aren't really looking for square root, you are looking for vector 
magnitude.  Vector magnitude can be computed without computing the 
square root.  For arbitrary precision, you can use the cordic algorithm 
in vectoring mode.  It basically rotates the vector to the I axis using 
a series of progressively smaller fixed angle rotations selected so that 
each elemental rotation is done with a shift and add operation. After 
rotating the vector the I axis, the magnitude is read directly from the 
non-zero (I component) of the rotated vector.  If you don't need a lot 
of precision, there are table methods and linear approximations (the 
most famous is "larger plus half smaller" that will often get you a good 
enough answer with less computation.  Either way, computing magnitude 
using a square root is going about it the hard way (hardware-wise 
anyway).  For 32 bit arguments, CORDIC is going to be your best bet.

Article: 102184
Subject: Re: [Newbie] 64-point complex FFT with 32 bit floating-point representation
From: Ray Andraka <ray@andraka.com>
Date: Thu, 11 May 2006 13:39:38 -0400
Links: << >>  << T >>  << A >>
Franco Tiratore wrote:

> Hi all.
> 
> I'm currently trying to understand whether or not it is possible to
> implement a 802.11a-compliant OFDM modulator/demodulator on an FPGA.
> As far as I understand, the critical part of the project is the
> 64-point complex FFT with 32 bit floating-point representation (each
> real or complex number is represented in 32-bit floating-point). The
> FFT block should perform this calculation in no more than 2.5 us.
> I'm not an expert in this field, can anyone help me to understand
> whether or not this performance is achievable with the FPGAs currently
> available on the market? If yes: can you address me to some specific
> FPGA model? If not: what is the critical part of my specifications? (I
> suppose the time delay and the floating point spec).
> 
> This is only one of my current doubts.
> I hope we can start a profitable discussion. :-)
> 
> Ciao,
> Franco
> 

Pretty much any of the current FPGA offerings are capable of 64 point 
FFTs in 2.5 us.  For OFDM, there really isn't any need to use floating 
point.  Floating point trades accuracy for dynamic range.  In the case 
of OFDM, you have 64 point FFT, so at most you'll have a growth of 6 
bits in your data.  Presumably, the data is coming from a DAC through 
some filters, so the dynamic range of the data coming into the FFT is 
also not that large.  A single precision floating point FFt is going to 
have a 24 bit data path plus an 8 bit exponent.  A 24 bit fixed point 
data path with no exponents is more than enough for this application.

There are FFT cores in the cores offered by the major FPGA vendors. 
These are not bad considering the price (free).  You can obtain 
considerably higher performance and smaller size from third party IP 
providers, but it is not free.

In any event, you need to look at the entire OFDM receiver, as the FFT 
is only one block of it, and can be readily found off-the-shelf.



Article: 102185
Subject: Re: Installing BFM toolkit
From: "jenze" <jenze@et.upb.de>
Date: 11 May 2006 10:43:59 -0700
Links: << >>  << T >>  << A >>
Hi jm,

what i try to say is that you can "port" the BFM 7.1 tollkit for use in
EDK 8.1. Of course you can use the BFM 7.1 with EDK 7.1 ;). Anyway, you
must have access to some BFM toolkit to get BFM models. The BFM toolkit
was supplied by xilinx for free for 6.3 and 7.1 (you only have to sign
up for the coreconnect suite), so i see no problem if i give the BFM
7.1 toolkit  to you, since its not available from the xilinx website
any longer. Please contact me directly (mail).

Regards

Jens

jmariano schrieb:

> Hi Jens,
>
> Sorry for the late replay and tanks for your input. I was able to solve
> my problem by
> simulating my core directly in ISE, but my the problem remains.
>
> I'm using XPS 7.1, so if I understand correctly, I have to change to
> 8.1, to preform BFM
> simulation, since the wizard in XPS 7.1 doesn't allows me to do so,
> since I don't have the BFM
> toolkit installed.
> 
> Regards
> 
> jm


Article: 102186
Subject: Re: reverse engineering ?
From: "JJ" <johnjakson@gmail.com>
Date: 11 May 2006 11:01:28 -0700
Links: << >>  << T >>  << A >>

binaryboy wrote:
> is it easy to reverse engineer ASIC/FPGA ?
> do u have any reference for this ?

It was only ever "easy" maybe 25 years ago or more for full custom VLSI
and has gotten progressively harder by Moores law and more so ever
since for ASICs. There were (are?) quite a few firms that used do it
but the business model has changed.

Most DRAMs from different vendors were largely similar because they
could all buy "reports" from Mosaid of the design of leading parts.
Design engineers liked to know they were at least doing the same sort
of thing as the leader, but memories are a special case. It probably
helped the consumer to mix different vendor parts without too much
fuss.

FPGAs another story.

This has been discussed many times here if you care to google groups
for reverse engineering.

John


Article: 102187
Subject: Re: reverse engineering ?
From: fpga_toys@yahoo.com
Date: 11 May 2006 12:18:43 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> There have been inquiries to vendors 'who do this for a living' and they
> have refused to quote on anything larger than a Virtex 1000 class
> (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e).

I've done code recovery and clean room reverse engineering on and off
for software projects, and pld's since the late 1960's. Tools really
make the difference. For a large project we did in 1973 it required
writing a pretty state of the art high level disassembler for the
CDC3100 series to do code recovery for an operating system and major
utilities. The whole project including the disassembler was about 9 man
months. Another project required taking some dozen large eproms of 386
firmware converting to asm and back to forth. Again it took about two
weeks to write the tools, and several weeks to reconstruct the forth
code and provide the client with a clean room specification for the
system design.

If someone came to me wanting code recovery for any sized Virtex series
fpga, I don't think that is a problem, would require a modest effort in
tools that do not exist today. A clean room specification would take
longer, and is linear to application size, as you actually have to
understand the design to write it's specification. In general, clean
room projects typically run about 15-35% of the original design labor
for software projects ... and I suspect a similar range for hardware
designs reverse engineered back to verilog or C using a decompiler
approach. A Virtext front end for boomerang to FpgaC is probably less
than months work, and would require some hand tweeking to handle odd
cases of clock edge usage into a verilog module.

> It seems that they feel it isn't worth the headaches.  Not that it isn't
> "possible."  But then, it is "possible" I could visit the moon.

When the engineering time for a hardware/software project is measured
in a few man years, with a burdened cost of $500K and up, then $75-200K
for code recovery or a clean room specification of the design can be a
cost effective engineering expense to replace an old lost design or
jump start a competitive redesign.

>
> As for once the bit stream has been encrypted (since Virtex II, 6 years
> and counting), no one has broken it (3DES).  And they have been trying.
>
> More than one outfit.
>
> It is even more unlikely that a direct attack on the newer 256 bit AES
> encryption with battery backed up keys will also be able to succeed.

Crypto attacks don't make sense .... other physical attacks would, if
required. Nice big vaults with a shinny armor door are seldom the
easiest way into a vault of the locks fail. The cinder block or
concrete back wall, ceiling, or floor are probably much easier entry
points, and cheaper to repair afterward.


Article: 102188
Subject: Re: Xilinx 3s8000?
From: Ron <News5@spamex.com>
Date: Thu, 11 May 2006 12:18:44 -0700
Links: << >>  << T >>  << A >>
robnstef@frontiernet.net wrote:
> I have no use for these items, and if Xilinx doesn't see anything wrong
> with me giving a couple to you, I could then mail them.

I sincerely appreciate the offer Rob, but unless I'm missing something 
the devices you mention are older and consequently smaller devices than 
I really need. I'm looking to target one of the larger vendors devices 
on a hobbyist budget, and my primary obstacle is the high cost of the 
design software rather than the FPGAs and development boards themselves. 
Thanks to John Bass's earlier suggestion about ebay, the cost of the 
hardware is no longer much of an issue, but if you ever happen to run 
across an old dusty box labeled "Xilinx ISE Foundation," "Actel Libero 
Platninum", "Altera Quartus II Standard Edition," or even Lattice 
Semiconductor's full version of ispLEVER that hasn't yet been 
"activated", I would surely appreciate a copy of it.

Regards,

Ron

Article: 102189
Subject: Re: reverse engineering ?
From: fpga_toys@yahoo.com
Date: 11 May 2006 12:22:10 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> There have been inquiries to vendors 'who do this for a living' and they
> have refused to quote on anything larger than a Virtex 1000 class
> (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e).

You can always "prove" how difficult it is ... follow the RSA example
and offer a $20K challenge for reverse engineering an XC4VLX200 design
to an HLL that can be modified and recompiled. And maybe $100K for a
similar design that is DES locked.

Maybe Ron and I would have a lot more fun on those projects :)


Article: 102190
Subject: Re: reverse engineering ?
From: fpga_toys@yahoo.com
Date: 11 May 2006 12:40:14 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> There have been inquiries to vendors 'who do this for a living' and they
> have refused to quote on anything larger than a Virtex 1000 class
> (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e).

Please send your customers that need code recovery for larger devices
to me :)


Article: 102191
Subject: Re: Xilinx 3s8000?
From: robnstef@frontiernet.net
Date: 11 May 2006 12:49:31 -0700
Links: << >>  << T >>  << A >>
Ron,

I have plenty of older Quartus II versions (4.2 right on up), but its
the license file/dongle that I only have one of--sorry.

If the Altera Quartus Web edition (free) will allow you to compile, but
not generate programming files, for the Stratix families, you can
forward me the design and I'll generate the programming files for you.

I guess you'll have to trust that I won't steal your design.  Rest
assured that I would never engage in such an impropriety.  But you did
mention in one of your posts that you were thinking about making your
design open source.

Take care,
Rob


Article: 102192
Subject: Re: reverse engineering ?
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 11 May 2006 13:05:35 -0700
Links: << >>  << T >>  << A >>
John,

Sure.

No problem.  If anyone asks, I'll let them know you will consider it.

I had gone to get some quotes last year from some houses, and they had 
'no bid' after looking at it.

Some of these houses advertised that they would do exactly that, and had 
done so in the past (with a XC4005!).  People were asking how difficult 
it was to do this, and we felt we should find out.

Just be careful with your quote.

One more word of caution; I have access to the schematics, the bitstream 
map, and anything else.  When we have to reverse engineer a design for a 
customer (such as "why did the part fail the way it did" in some 
critical military application) it is still very tough to find which line 
of HDL was affected by the fault (presuming we even found a fault!).

And, I agree that if the front door is solid steel then most attackers 
look for a less secure means of entry, like an open window.

Austin

Article: 102193
Subject: Re: reverse engineering ?
From: fpga_toys@yahoo.com
Date: 11 May 2006 13:43:37 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> Just be careful with your quote.

Certainly. Source reconstruction is a pretty high risk contract even in
the best cases.

The absolute WORST contract I took was to reconstruct the CURRENT
sources for 20 cabinets of two year old IBM Cobol that had been
maintained online and lost (contract operations center refused to hand
sources over when client decided to change vendors, luckily they
managed to snarf binaries). Project was a year of painfully finding and
fixing every bug and change to those sources during the previous two
years by running in parallel with the production binaries for a year
till I got it to match line for line. Most of it came up with strainght
forward debugging in 3 months ... the last 5% took the rest of the year
-- all of 1974. The entire financial and inventory system for a Los
Angeles company.


Article: 102194
Subject: Re: Xilinx ISE 8.1 Makefile
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: 11 May 2006 13:45:02 -0700
Links: << >>  << T >>  << A >>
> is there a way to handle some incremental flow with makefiles ..?
> I know the process from c-programming ... only modified files
> need to compile - but all of them need to be linked ...
> could that save some time for FPGAs as well?
> the synthezize step only needs to handle modified files ...
> as I understand the flow the next step is merging everything (and
> optimizing across modules)?

I know synplify and xst support incremental synthesis flow, but they do
it with user constraints not makefiles.

HTH,
Jim
http://home.comcast.net/~jimwu88/tools/


Article: 102195
Subject: Re: can increase simulation run time while running modelsim?
From: "gaurav.vaidya2000@gmail.com" <gaurav.vaidya2000@gmail.com>
Date: 11 May 2006 13:59:28 -0700
Links: << >>  << T >>  << A >>
I am not an expert with ModelSim but I feel this is true with
testbenches:
The testbench is run out as a script until all its input-output
verifications are complete. As such, the run length of a testbench
cannot be changed at ModelSim runtime and can only be done by
increasing the input-output test vectors in the testbench right at the
start. I hope I am able to get that through. I have experienced that
ModelSim-XE simulates testbenches of a few microsecond duration quite
quickly. So you are probably simulating a duration of a few seconds or
more and hence the hour-long running time. You may hence also
concetrate on finding ways to simulate only the time interval of
interest (I don't know how to do that, though).
And yes, if test fixtures are something quite different than
testbenches, just ignore this post.


Article: 102196
Subject: Re: sqrt(a^2 + b^2) in synthesizable VHDL?
From: "gaurav.vaidya2000@gmail.com" <gaurav.vaidya2000@gmail.com>
Date: 11 May 2006 14:03:09 -0700
Links: << >>  << T >>  << A >>
If you are targetting programmable hardware (which you most possible
are), you can get IP cores to work for you. Check out opencores.org or
Xilinx or Altera websites to find cores that provide functions you need.


Article: 102197
Subject: Re: reverse engineering ?
From: fpga_toys@yahoo.com
Date: 11 May 2006 14:56:15 -0700
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> And maybe $100K for a
> similar design that is DES locked.

hmm ... someone asks just how would you attack an encrypted Virtex
part?

There are two problems, first the key is on the chip being protected
with a battery, and second getting to the unencrypted bit stream that
passes through the chip at one or more parts.

The key to attacking the chip would be to take one or more of the same
chip and peel it apart to locate it's basic design, looking for the
section of the chip where the 3DES engine is, the bit stream data path,
and the muxes which switch the bitstream.  Then decide where the best
place to probe the clear text point is, and take a couple practice runs
on a practice chip. Probing is very likely to require a non-contact
solution if you can not easily reach a metalized trace with the clear
text bitstream on it.

Then the fun part, stripping down a live part on a board with the
battery backup intact to preserve the key, and using the knowledge
gained on practice parts to uncover the probe point on the target
device, and getting it to reconfigure while you tap into the target
clear text bit stream.

Hopefully you can get your hands on two or three such devices just in
case the first attempt has something very bad happen to the target
device.


Article: 102198
Subject: Re: Altera Equiv.
From: "Paul Leventis" <paul.leventis@gmail.com>
Date: 11 May 2006 15:37:04 -0700
Links: << >>  << T >>  << A >>
H iRob,

Just a quick correction -- our CPLD is MAX II, which is a follow on to
our MAX family of CPLDs (MAX7000 and MAX3000 series).  Not to be
confused with MaxPlus II, which was the design software that preceded
Quartus.

There's tons of info on these families available on our website
(www.altera.com).  And you can download a free copy of Quartus II Web
Edition to try them out.

Regards,

Paul Leventis
Altera Corp.


Article: 102199
Subject: Re: simulation works fine but the actual chip doesnt work
From: sandeepbabel@gmail.com
Date: 11 May 2006 15:43:59 -0700
Links: << >>  << T >>  << A >>
Hello Mark,

I have done many runs on the actual chip and also the smulation. Here
are the major differences that I have noticed and are a possible cause
of failure for the actual chip.

In the simulation, the transmission line of the UART is at HIGH when
NOT transmitting anything, when I provide it with some data value and a
write signal, It transmits it and then goes back high again. When the
transmission is completed another signal called UART_RDY is asserted
and that indicates that I can load in the next data value.

In the actual synthesised design, the TX line keeps transmitting some
random pattern over and over again, and is not held at HIGH state when
I power the chip on. In other words the UART_RDY signal is never
asserted, which implies that I cannot load data values from the PCI
bus, as it is always waiting for the UART_RDY signal to be asserted.

I have very little experience with ASIC/FPGA design, hence I am not
able to come up with a way to hold the TX line at HIGH when the chip
powers up. I have to stop the TX line from behaving in a random manner
so that I can read the UART_RDY signal and then load data values from
the PCI bus into it. 

Please advise. 

Thank you,

Sandeep




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