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 102200

Article: 102200
Subject: Re: reverse engineering ?
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 11 May 2006 15:58:14 -0700
Links: << >>  << T >>  << A >>
John,

And I hope someone tries it.

We intentionally placed these points (note the use of plural) that are 
in the clear where they would be the most difficult to get at.

Not because obscurity is security, but because the obscurity helps make 
the attack more expensive (to be successful).

Also, it is a flip chip device (since V4), so you need to dig in from 
the back side, through the active layer, to get to the probe points 
(note plural again).  Cutting through some working devices that might be 
required would break it.

Finding the probe points will be loads of fun, too.  Especially without 
schematics, or a layout.  And the internal bus is not necessarily one 
bit wide (anywhere).  So that will really challenge the attacker!

In fact it is documented that a config frame is 1312 bits in V4.  Yes, 
there are 1312 wires from a register in the config logic to every frame 
across the chip.  I can see someone probing 1302, 1303, 1304 .... oops! 
  Lost the key again!

Of course, you might not need every decrypted single bit to then go back 
and break the encrypted bitstream.  Maybe someone can answer how many 
decrypted bits you need to shorten the cracking of the encryption to a 
reasonable length of time...

Of course the decryptor is all hard logic (just like an ASIC decryptor), 
so if one had a few 3DES, or 256AES ASIC layouts, and schematics, from 
other chips, they could probably make some educated guesses to identify 
where the core is, but where the signals are will take some ASIC reverse 
engineering.

And, what is to say that the chip you are trying to crack doesn't have a 
design in it that is able to dump the keys (0 them, or even scramble 
them) if it detects that someone is tampering with it?

Folks that are serious about security think about all these things all 
the time (because they do them, and have had them done to them by others).

About this time, I think the attacker will be considering other methods 
of attack....which is all we needed to force them to do.

Austin

fpga_toys@yahoo.com wrote:

> 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: 102201
Subject: Multiple Write Port Register Files
From: "Luke" <lvalenty@gmail.com>
Date: 11 May 2006 16:16:28 -0700
Links: << >>  << T >>  << A >>
I'm working on a project that needs four write ports in a number of
different register files.  I'm already aware of time-multiplexing and
partitioning.  Generating a flop-based register file would take far too
many resources.

Are there any other methods of implementing multiple write ports on a
single register file?  Any nifty workarounds people have done?  Any
paper ideas?


Article: 102202
Subject: Re: simulation works fine but the actual chip doesnt work
From: Mark McDougall <markm@vl.com.au>
Date: Fri, 12 May 2006 10:34:29 +1000
Links: << >>  << T >>  << A >>
sandeepbabel@gmail.com wrote:

> 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 can't imagine the TX line state has anything to do with the UART_RDY 
signal - there shouldn't be any feedback required here. UART_RDY I 
would've thought depends only on the state machine of the transmitter, 
and when the last bit is clocked out of the transmit register, then 
UART_RDY is asserted.

The fact that TX line isn't held high is a problem - and given the 
behaviour I'd suspect clocking problems? Have you checked the clock to 
the UART with the logic analyzer functionality of your synthesis tools?

BTW what's the UART core doing when there's nothing to xmit? Is it 
holding TX high itself, or tri-stating and assuming you have a pullup?

Is this your UART design BTW?

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 102203
Subject: Re: can increase simulation run time while running modelsim?
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 11 May 2006 17:36:00 -0700
Links: << >>  << T >>  << A >>
Subhasri krishnan wrote:
> 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.

>From the ModelSim (tcl shell) command line, type:

run 10ms

and it'll continue the simulation, from where it left off, for another
10 milliseconds.

-a


Article: 102204
Subject: Re: reverse engineering ?
From: MikeShepherd564@btinternet.com
Date: Fri, 12 May 2006 01:49:05 +0100
Links: << >>  << T >>  << A >>
>...progressively harder by Moores law...

Who needs Moore's Law for obscurity?  The way most HDL is written
would make any hacker turn pale.

Even vendors' "model" code can be so bad you wouldn't want your name
on it.  In one example project, the code is claimed to be "...built
such that both the software and hardware portions would be easy to
understand...".  On examination,  the HDL is full of unexplained
"magic" numbers and the comments gaze at each other through
long-distance binoculars.

As for unwinding the compiled versions of other people's creations,
surely life is too short, unless that's the only job you can get.

Me?  I'd rather sign up at MacDonalds.

Article: 102205
Subject: Re: Altera Equiv.
From: "Rob" <robnstef@frontiernet.net>
Date: Fri, 12 May 2006 00:51:55 GMT
Links: << >>  << T >>  << A >>
Sorry, my mistake.  I should have known better--I just used a MAXII part in 
a design :)



"Paul Leventis" <paul.leventis@gmail.com> wrote in message 
news:1147387024.723712.313290@q12g2000cwa.googlegroups.com...
>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: 102206
Subject: Re: reverse engineering ?
From: fpga_toys@yahoo.com
Date: 11 May 2006 18:42:25 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> And I hope someone tries it.

It would probably be fun to try as well, unfortunately I don't have
access to a VLSI lab and prober :(

But for a $100K bounty I might be temped to purchase the toys on eBay
:)

> Also, it is a flip chip device (since V4), so you need to dig in from
> the back side, through the active layer, to get to the probe points
> (note plural again).  Cutting through some working devices that might be
> required would break it.

or getting very creative and drilling thru the BGA carrier, attaching
wires to the standby battery bumps, and removing the carrier to get
access to the process side of the die.

While iteratively etching/slicing and scanning the die is a lot of
work, over the last 25 years high resolution image/pattern recognition
(with FPGA assist) has gotten better and faster. Attacking a 20M gate
or larger device would have to be largely automated. FPGA's are at a
disadvantage because they are highly regular, so one is mostly looking
for the irregular blocks. If I had a contract to do it, it's probably
map several die with an automated process first just to make sure the
automated etching/slicing and scanning process yielded the proper mask
design. Then work at automated reconstruction of your cell/transistor
library, and then fold it back to a high level description to identify
the odd logic blocks. Since the configuration and 3DES core are
probably larger than any other support block, it's probably not that
hard to issolate, unless somebody really tried hard to hide it in the
middle of the FPGA array highly distributed in area.

> Folks that are serious about security think about all these things all
> the time (because they do them, and have had them done to them by others).

I've done security stuff on and off over the years, but I'm not a hard
core crypto guy. About 20 years ago one company wanted me to sign an
NDA for the security projects, which was very draconian, so I refused.
After the team was done, and the security project was shipping I broke
it in about 3 hrs with a logic analyzer ... which I expected a much
better challenge for a VERY expensive security consultants fee for
providing the design.  Since security is one of those things where
people are much happier ignorant, I just let it ride rather than
pissing a bunch of blisful exec's dreams away.

There are a ton of horrible mistakes with security implementations ...
my favorite is 802.112b WEP ... the security boys committee camel that
was just a wet dream.

> About this time, I think the attacker will be considering other methods
> of attack....which is all we needed to force them to do.

That is always the hope .... but making sure the security fence is the
same height and durability all around the product is sometimes harder
that one might first think.


Article: 102207
Subject: Re: sqrt(a^2 + b^2) in synthesizable VHDL?
From: "jtw" <wrightjt @hotmail.invalid>
Date: Fri, 12 May 2006 02:10:04 GMT
Links: << >>  << T >>  << A >>
Do you need the square root, or can you work with just the "sum of the 
squares" (perhaps scaled)?  If this is used for thresholding (amplitude 
comparison), then the less-than/equal/greater-than relationship still holds.

JTW

"Marko S" <someone@microsoft.com> wrote in message 
news:44630af8$0$15782$14726298@news.sunsite.dk...
> 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.
>>
>
> 



Article: 102208
Subject: Re: reverse engineering ?
From: "JJ" <johnjakson@gmail.com>
Date: 11 May 2006 19:16:17 -0700
Links: << >>  << T >>  << A >>

MikeShepherd564@btinternet.com wrote:
> >...progressively harder by Moores law...
>
> Who needs Moore's Law for obscurity?  The way most HDL is written
> would make any hacker turn pale.
>
> Even vendors' "model" code can be so bad you wouldn't want your name
> on it.  In one example project, the code is claimed to be "...built
> such that both the software and hardware portions would be easy to
> understand...".  On examination,  the HDL is full of unexplained
> "magic" numbers and the comments gaze at each other through
> long-distance binoculars.
>

I was going to add a related point but didn't think the post was going
to go on.

I could have said that a small amount of good or bad code produces alot
of ASIC or FPGA final result with the myriad of synthesis and P/R
settings, the same code could produce zillions of different chips to
reverse engineer ie most of it is noise and very little is interesting
anymore.

When it was easy, the intent of the designer was often crystal clear
and it was almost a pleasure to reverse and quite educational on a
small scale, the layout was an exact reflection of the schematics and
floor plan. The junior engineer looking at the masters work, but that
was decades ago. Ofcourse before chip layouts were protected, many lazy
semiconductor companies would blindly duplicate the works of leaders.
Once automation set in, one is really looking up that tools rear end if
one can see anything at all.

> As for unwinding the compiled versions of other people's creations,
> surely life is too short, unless that's the only job you can get.
>

It is, and I don't think anybody really does it anymore, it has to be
far cheaper to just hire similarly skilled people and design to same
spec.

> Me?  I'd rather sign up at MacDonalds.

I'd rather die than do that.

John Jakson


Article: 102209
Subject: Re: reverse engineering ?
From: fpga_toys@yahoo.com
Date: 11 May 2006 19:20:31 -0700
Links: << >>  << T >>  << A >>

MikeShepherd564@btinternet.com wrote:
> As for unwinding the compiled versions of other people's creations,
> surely life is too short, unless that's the only job you can get.

Actually, doing traditional coding is far more boring ... after a few
decades even what appears a very different projects is writing the same
old algorithms over again.

reverse engineering is more like jigsaw puzzles on steroids ... lot's
of little pieces all the same "twisty windy little passages all the
same". Learning to recognize algorithms, FSM's, etc allows you to
abstract thru the clutter and rearrange the puzzle back into a clear
picture without getting lost in the forest.  Being able to see the
adders, multipliers, fsm's, synchronizers and data paths as higher
level objects allows you to cut thru the design more quickly and work
with it at an abstract level more effectively.

For example, when we bid the 386 controller project twenty years ago,
it was one of those projects nobody else wanted, and I took it on a
lark because it was interesting and I had a couple college kids working
for me that had never done reverse engineering before. All the client
needed was the communications protocol along with a clean room
description of how to write a control server for the machine. I took it
fixed price, for a month, with a "no delivery, no pay" clause (as I do
a lot of high risk projects). The next week a $100K machine showed up
at my door step, and we moved it into our office. I thought we were
really going to have to dissassemble a dozen eproms of 386 asm and sort
thru a hand coded assembly design. So I did that first, taking the
proms off the board, and disassembling them. Then I connected the
HP1650B to the processor bus, and started tracing control flow for
major activities. By the second day I noticed a regularity in the code
blocks which indicated a higher level structure, and sure enough it was
forth pop code functions. It took another day to reconstruct the forth
execution engine, and another day to reconstruct the forth sources that
we needed. and a few more days to reconstruct the design and provide
the clean room design documents. It took another week to track down all
the constants and variables in the protocol and document them. They
came and picked the machine back up, and we got paid for a couple weeks
of very fun puzzle playing.

Some people are challenged by deductive reasoning puzzles ... and
others are clueless how to even get started.  And even when shown, can
never connect the dots.


Article: 102210
Subject: Re: Multiple Write Port Register Files
From: "JJ" <johnjakson@gmail.com>
Date: 11 May 2006 19:21:04 -0700
Links: << >>  << T >>  << A >>

Luke wrote:
> I'm working on a project that needs four write ports in a number of
> different register files.  I'm already aware of time-multiplexing and
> partitioning.  Generating a flop-based register file would take far too
> many resources.
>
> Are there any other methods of implementing multiple write ports on a
> single register file?  Any nifty workarounds people have done?  Any
> paper ideas?

Google this group back a few weeks, the solution was presented in
detail to the exact same same question.

John Jakson


Article: 102211
Subject: Re: reverse engineering ?
From: fpga_toys@yahoo.com
Date: 11 May 2006 19:21:59 -0700
Links: << >>  << T >>  << A >>

fpga_t...@yahoo.com wrote:

Anyone here that has taken a contract to convert a schematic design to
VHDL/Verilog yet?

same problem


Article: 102212
Subject: Re: reverse engineering ?
From: "JJ" <johnjakson@gmail.com>
Date: 11 May 2006 19:44:57 -0700
Links: << >>  << T >>  << A >>

fpga_t...@yahoo.com wrote:
> fpga_t...@yahoo.com wrote:
>
> Anyone here that has taken a contract to convert a schematic design to
> VHDL/Verilog yet?
>
> same problem

I was in a project that rescued from HP a late 70s nmos chip and had to
bring into the mid 90s, all we got were the original mask tapes in a
dead layout language (with notes) and the old test vector tapes. We had
to write the layout decompiler to get the hierarchy and leaf cells and
turn those into crude schematics. SInce those were nmos transistor
level, it was only really possible to do so with a knowledge of nmos
design with bootstrapping and mostly pass logic, something the new cmos
kids wouldn't have known about.

It was alot of fun and we did give HP back a new cmos Verilog source
passing the same vectors so it should stay in production portable
fashion as long as folks want arb waveform instrument boxes. At the
time I never would have thought that I'd be doing nmos work again in
the mid 90s. They also had a sin table in nmos rom but the std cell
cmos had no rom, so got to replace that with an engine.

The problem with all these projects is the contract fee, you never know
whether your are going to lose your shirt on it or just survive another
day.

John Jakson


Article: 102213
Subject: Re: Xilinx 3s8000?
From: "Jeff Brower" <jbrower@signalogic.com>
Date: 11 May 2006 19:47:03 -0700
Links: << >>  << T >>  << A >>
Radarman-

> We are still fighting to keep an old P3 system that went EOL years ago,
> and that we are presumably paying penalties on, because it is the last
> system with a working copy of several packages we need that are no
> longer supported. It's kind of sad to see so many developers sharing
> time on what has to be the oldest PC in the department.

Yes I know this feeling.  Our "4.1 machine" is a Win9x.  Our "6.1
machine" is a slow WinXP that gets used mostly for testing and no one
will admit to being it's caretaker.

I think it's a Xilinx conspiracy to further promote FPGAs -- keep the
key design engineers stuck using slow PCs so they fully realize the
blazing potential of FPGA vs. Pentium.  Haha!

-Jeff


Article: 102214
Subject: Re: Xilinx 3s8000?
From: "Jeff Brower" <jbrower@signalogic.com>
Date: 11 May 2006 19:50:15 -0700
Links: << >>  << T >>  << A >>
David-

> Is that a licensing thing or a functionality thing?
>
> When I got my Spartan 3e starter kit a few days ago, I installed the
> included ISE 8.1 under E:\Program Files\Xilinx .
>
> When I found out that some things Do Not Work in paths that have spaces
> in them, I uninstalled it and re-installed it under
> E:\ProgramFiles\Xilinx .
>
> Have I set myself up for a lifetime of pain until I get a new computer?

No you're fine.  I tell my engineers:  back up the hard drive
completely, try it once, and if you get lucky and *everything* works,
then go ahead.  But when the first thing fails, then restore the
original drive, and keep the machine pristine.  That's our lab rule,
believe it or not.

-Jeff


Article: 102215
Subject: Re: Synplify - Not satisfactory results with re-timing option
From: Phil Hays <Spampostmaster@comcast.net>
Date: Thu, 11 May 2006 20:24:52 -0700
Links: << >>  << T >>  << A >>
"srini" <g.shrinivasan@gmail.com> wrote:

>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? 

Retiming works very well for some designs, and makes them run faster.
Other designs retiming doesn't work with, for at least three reasons:


1) The resulting design may be larger, with more routing congestion,
and thereby slower.  This is most common and most noticeable when the
part is fairly full.  The timing failure may not be in the retimed
paths, but may be elsewhere in the design.  The best way to make a
full design faster may be to make it smaller.  A floorplan might help
as well.


2) The resulting design may not pack as well.  This is fairly hard to
both diagnose and to visualize.  It is somewhat like the first case,
but from the inside out.  If the retiming increases the routing delay
by making the resulting design larger by more than it saves by making
all paths have similar logic delays, then retiming will make the
design slower.  The timing failure may not be in the retimed paths,
but may be elsewhere in the design.  Again, making the design smaller
may make it faster, and retiming does the reverse.


3) The retiming is done based on estimated routing delay.  As an
example, suppose the design had:

FF -> lut -> lut -> FF --------------------------> FF
 1                   2                              3

If the first two FFs can be close together on one corner of the part,
and the last FF must be on the far corner of the part, then retiming
that to:

FF -> lut -> FF -> lut --------------------------> FF 
 1            2                                     3

will almost surely make it slower, as the critical path in the first
case was between FF2 and FF3 because of physical placement, and adding
the lut delay just makes it slower.

The synthesis tool estimates based on "wireload models", and the
estimated delays might look like this:

FF -------------> lut -----> lut -----> FF ------> FF
 1                                       2          3

As the synthesis tool has no knowledge where on the die these items
are placed.  The weakness of "wireload models" is a large part of the
reason why "physical synthesis" can be useful, as someone has already
commented, as a estimate of routing delays based on a realistic
placement helps the synthesis, even if the placement isn't saved and
reused.


Retiming is a tool, and works well on many problems.  Other problems
require different tools.


--
Phil Hays


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

JJ wrote:
> We had
> to write the layout decompiler to get the hierarchy and leaf cells and
> turn those into crude schematics. SInce those were nmos transistor
> level, it was only really possible to do so with a knowledge of nmos
> design with bootstrapping and mostly pass logic, something the new cmos
> kids wouldn't have known about.

You've hit on the two factors that separate failing teams from those
that deliver. The vision to invest in automated tools, such as your
layout decompiler, and specialized knowledge of the technology area.

> The problem with all these projects is the contract fee, you never know
> whether your are going to lose your shirt on it or just survive another
> day.

Fixed price contracting actually has some feedback rewards that way,
you bid conservately enough after a few bumps not to lose your shirt
again :)  I find T&M far more risky, as the client is much too often to
hold you to your initial time estimate, after increasing the
requirements over the life of the project. With T&M you can not say no
to design/requirements changes, and have less control over schedule
expectations that result.

One of the most stupid things is to take a high risk fixed price
contract while you are hungy. Creates a lot of pressure that is counter
productive in making reasonable decisions about the project. If you get
into trouble, you are quickly very frustrated and HUNGRY.

I normally bid them low ball based on best case with a very short time
leash, and walk away if the project gets in trouble -- which is why the
"no deliver, no pay" clause is critical. Out of several dozen of these
contracts I've only walked away from one, and that was renegotiated a
year later after several other teams had failed as well. I also had a
year to sort out what went wrong and formulate a better attack on the
project.  I generally start those projects with a few 70-100hr weeks to
bring them into perspective quickly ... the intense focus is for me
worth several months of regular days, and very much needed to
internally visualize the architecture of the problem early.

After that, I've found these projects pay well, and generate follow on
work well worth the initial risk.


Article: 102217
Subject: Re: simulation works fine but the actual chip doesnt work
From: "sandeep" <sandeepbabel@gmail.com>
Date: 11 May 2006 20:40:19 -0700
Links: << >>  << T >>  << A >>
Hello Mark,

Yes you are right, the UART_RDY depends on the state of the
transmission. What I meant to say was that when the transmission of the
data ends, TX goes high and UART_RDY is asserted. This is a design I
found on the web. It is originally from Quicklogic, but I modified it
so that it transmits 8 bit data and then another 8 bit data before the
state machine asserts the UART_RDY.
Below is the part of the code:



BEGIN

--// Paritycycle = 1 on next to last cycle, this means when tsr[1] gets
tag2.

paritycycle <= tsr(1) AND NOT (tag2 OR tag1 OR tsr(7) OR tsr(6) OR
tsr(5) OR tsr(4) OR tsr(3) OR tsr(2));


--// txdone = 1 when done shifting, this means when tx gets tag2.

txdone <= NOT (tag2 OR tag1 OR tsr(7) OR tsr(6) OR tsr(5) OR tsr(4) OR
tsr(3) OR tsr(2) OR tsr(1) OR tsr(0));

data_latch: PROCESS(write, data)
BEGIN
	IF ( write = '0' ) THEN
data1 <= data(15 downto 8);
data2 <= data(7 downto 0);
END IF;
END PROCESS;

thr_write : PROCESS ( write, txdone)
variable count1 : std_logic;

BEGIN
 IF (write'event AND write = '1' ) THEN
           thr <= data1;
		   count1 := '1';
ELSIF (txdone'event AND ( txdone='1'))AND count1 = '1' THEN
            thr <= data2;
	    count <= '1';
            count1:= '0' ;
ElSE  count <='0';
END IF;

  END PROCESS;

   shift_out : PROCESS (txclk, reset)

   BEGIN
      IF (reset = '1') THEN
      	tsr <= (OTHERS => '0');
         tag2 <= '0';
         tag1 <= '0';
         txparity <= paritymode;
         tx <= '1';
		 txrdy <= '0';

      ELSIF txclk = '1' AND txclk'EVENT THEN
         IF (txdone='1' AND txdatardy = '1' ) OR ( txdone ='1' AND
count = '1' )THEN
--          load_data1;
            tsr <= thr;
            tag2 <= '1';
            tag1 <= '1';
            txparity <= paritymode;
            tx <= '0';

		 ELSE
--          shift_data;
            tsr <= '0'&tsr(7 downto 1);
            tsr(7) <= tag1;
            tag1 <= tag2;
			tag2 <= '0';
            txparity <= txparity XOR tsr(0);
            IF (txdone = '1') THEN
               tx <= '1';
			IF (txdone = '1' AND count = '0') THEN
				txrdy <= '1';
     		end if;
               ELSIF (paritycycle = '1') THEN
                  tx <= txparity;
				  txrdy <= '0';
               ELSE
                  tx <= tsr(0);
				  txrdy <= '0';
            END IF;
         END IF;
      END IF;
   END PROCESS;



   PROCESS (mclkx16, reset)

   BEGIN
      IF (reset='1') THEN
         txdatardy <= '0';
         write2 <= '1';
         write1 <= '1';
         txdone1 <= '1';

      ELSIF mclkx16 = '1' AND mclkx16'EVENT THEN
         IF (write1 = '1' AND write2 = '0') THEN
            txdatardy <= '1';

         ELSIF (txdone = '0' AND txdone1 = '1') THEN
            txdatardy <= '0';

         END IF;
         write2 <= write1;
         write1 <= write;
         txdone1 <= txdone;
      END IF;
   END PROCESS;


Article: 102218
Subject: Re: simulation works fine but the actual chip doesnt work
From: "sandeep" <sandeepbabel@gmail.com>
Date: 11 May 2006 20:43:20 -0700
Links: << >>  << T >>  << A >>
Hi Mark,

here is the link for the UART.

http://www.ece.ualberta.ca/~elliott/ee552/studentAppNotes/1999f/UART/uart.html

Thank you, 

Sandeep


Article: 102219
Subject: Re: reverse engineering ?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 12 May 2006 16:04:21 +1200
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Austin Lesea wrote:
> 
>>And I hope someone tries it.
> 
> 
> It would probably be fun to try as well, unfortunately I don't have
> access to a VLSI lab and prober :(
> 
> But for a $100K bounty I might be temped to purchase the toys on eBay
> :)

Nah, that wouldn't work - Austin would just claim they were 
counterfeit/grey market chips and therefore unsupported/somehow easier 
to crack.... ;)
-jg


Article: 102220
Subject: JTAG tutorial
From: "Jean Nicolle" <jean.nicolle@sbcglobal.net>
Date: Fri, 12 May 2006 04:08:46 GMT
Links: << >>  << T >>  << A >>
I created a small tutorial about JTAG.
See http://www.fpga4fun.com/JTAG.html

I'd be happy to hear about mistakes/suggestions.
Thanks. 



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

Jim Granville wrote:
> Nah, that wouldn't work - Austin would just claim they were
> counterfeit/grey market chips and therefore unsupported/somehow easier
> to crack.... ;)
> -jg

ROTFL :)


Article: 102222
Subject: clock multiplier in spartan 2
From: "Ashish" <ashish.shringarpure@gmail.com>
Date: 12 May 2006 00:04:22 -0700
Links: << >>  << T >>  << A >>
how to implement a clock multiplier in spartan2 from ref clock. I have
input clock of 25 mhz and need to generate 50 Mhz clock.


Thanks 

Ashish


Article: 102223
Subject: Re: reverse engineering ?
From: David Brown <david@westcontrol.removethisbit.com>
Date: 12 May 2006 09:12:04 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> John,
> 
> And I hope someone tries it.
> 
> We intentionally placed these points (note the use of plural) that are 
> in the clear where they would be the most difficult to get at.
> 
> Not because obscurity is security, but because the obscurity helps make 
> the attack more expensive (to be successful).
> 
> Also, it is a flip chip device (since V4), so you need to dig in from 
> the back side, through the active layer, to get to the probe points 
> (note plural again).  Cutting through some working devices that might be 
> required would break it.
> 
> Finding the probe points will be loads of fun, too.  Especially without 
> schematics, or a layout.  And the internal bus is not necessarily one 
> bit wide (anywhere).  So that will really challenge the attacker!
> 
> In fact it is documented that a config frame is 1312 bits in V4.  Yes, 
> there are 1312 wires from a register in the config logic to every frame 
> across the chip.  I can see someone probing 1302, 1303, 1304 .... oops! 
>  Lost the key again!
> 
> Of course, you might not need every decrypted single bit to then go back 
> and break the encrypted bitstream.  Maybe someone can answer how many 
> decrypted bits you need to shorten the cracking of the encryption to a 
> reasonable length of time...
> 
> Of course the decryptor is all hard logic (just like an ASIC decryptor), 
> so if one had a few 3DES, or 256AES ASIC layouts, and schematics, from 
> other chips, they could probably make some educated guesses to identify 
> where the core is, but where the signals are will take some ASIC reverse 
> engineering.
> 
> And, what is to say that the chip you are trying to crack doesn't have a 
> design in it that is able to dump the keys (0 them, or even scramble 
> them) if it detects that someone is tampering with it?
> 
> Folks that are serious about security think about all these things all 
> the time (because they do them, and have had them done to them by others).
> 
> About this time, I think the attacker will be considering other methods 
> of attack....which is all we needed to force them to do.
> 

It sounds like rubber hose cryptoanalysis would be faster, cheaper, and 
more reliable, and it's easier to get hold of experienced staff.

> Austin
> 

Article: 102224
Subject: Re: 64-point complex FFT with 32 bit floating-point representation
From: "Franco Tiratore" <trapule@googlemail.com>
Date: 12 May 2006 00:17:34 -0700
Links: << >>  << T >>  << A >>
Hi, Ray.
Thanks for your suggestions.
What do you mean with the following two phrases?


> Floating point trades accuracy for dynamic range.


and


> In the case
> of OFDM, you have 64 point FFT, so at most you'll have a growth of 6
> bits in your data.  


Ciao,
Franco




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