Reverse engineering ASIC into FPGA

In article <42517aee_4@x-privat.org>, Symon wrote:
> 
> Naahh, I sent a copy of the databook to Pune, India. Three months later...

Black box... as in I do not have the databook.

-- 
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

MikeJ wrote:
> mmm, next time you want one done send me to India ! Haven't been there yet
> :)
> 
> Depends how big the asic is and how much info you have on it.
> 
> www.fpgaarcade.com
> 
> I have cloned a few early NAMCO asics and made plug in 28pin replacements.
> No documentation on them, but functionally simple. Very small amounts of
> code compared to my normal large virtex4 type stuff, but lots of debugging
> and trial and error to get exact behaviour under all (tested at least)
> cases.
> 
> I have also (almost) finished the atari st custom chip sets, for which there
> is a lot of documentation.
> 
> What are you after ?
> /Mike.
> 
> 
You are almost done with your ST chips? Cool! thats one i personally am
looking forward too ( but dont have the time, or experience yet, to do 
that on my own )

Austin Lesea wrote:

> All,
>
> <snipped>
> One big advantage they have, is they have schematics, verilog, or 
> VHDL, so they can simulate, and put together test benches.
>
> Without the schematics, or HDL, it is a very tough job to convert to 
> anything at all.
>
> Austin

Right you are.  Without the source, it is usually easier to start with a 
clean sheet and design to the specifications.  Having a device with the 
original design in it but no source is only good for verifying the 
design and perhaps for extracting the specification.  I've been down 
this road more than once, usually on legacy FPGA designs that no longer 
have source and either need a "minor change" or need to be migrated to a 
newer device family.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

In article <CvC4e.13846$Tn.9577@lakeread06>, Ray Andraka wrote:
> 
> Right you are.  Without the source, it is usually easier to start with a 
> clean sheet and design to the specifications.  Having a device with the 
> original design in it but no source is only good for verifying the 
> design and perhaps for extracting the specification.  I've been down 
> this road more than once, usually on legacy FPGA designs that no longer 
> have source and either need a "minor change" or need to be migrated to a 
> newer device family.

If I had specifications, I'd not waste my time on trying to reverse
engineer the ASIC.  :-)

-- 
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

<quote> How do you go about quoting that, or is it by the hour?
If it's by the hour, how do you even give a vague estimate? </quote>
No I dont think its by the hour, more like a package deal with a
ceratain time frame. it dosent have the time to market urgency of a new
product.

Not true, most of those that were in the cloning business had the same
urgency as the original if not more so, if you want to eat somebody
elses lunch you have to be quick. The longer an alternative compatible
takes to come out, the less crumbs left over for them, its a well known
model, even worse the price is falling and you get squeezed into the
little part of the curve.

regards

johnjakson at usa dot com

On Mon, 4 Apr 2005 15:49:44 +0000 (UTC), weingart@cs.ualberta.ca (Tobias Weingartner) wrote:
>Does anyone have experience with reverse engineering ASIC (black box)
>into equivelant FPGA devices (pin equivelant with a sub-board if necessary)?

I did a project like this about 8 years ago, except it was
ASIC to FPGA to ASIC.

The original ASIC was a standard product from a company you know,
as in it was a standard product, but they used ASIC design methodology.

A data sheet was available, but had insufficient info about behavior
for all possible input scenarios.

The client was using thousands of these parts per month, and had big
expensive boards that they could not respin for a different package.
The original ASIC had a package and pinout that did not match any
FPGA. The original vendor was surprisingly unhelpful, as no more chips,
no hand over of product to one of the after market silicon houses,
no willingness to find their design files to help us.

We did find an ASIC vendor that could match the package and power,
ground, I/O pin requirements. (FPGA on carrier board was also considered
but we didn't have the vertical clearance.)

I reverse enginered the original part based on the application circuit,
the incomplete data sheet, and common sense about how the original
(reasonable I hope) designers must have done things. I created an FPGA
design. The customer created a very large set of test vectors, and ran
it through their system, and recorded the results.

I designed a PCB that plugged into a PC, and had a socket for the original
ASIC, and the FPGA. I got one of the original ASICs, put it on my board
and ran the test vectors from the client against the ASIC, and checked
that their result vectors matched. I wrote a test coverage program and
ran their vectors through it, and identified what they weren't testing.
I wrote a few million more vectors, and ran them through the original
ASIC. I updated the test vector set, and the expected response. I wrote
an addendum to the data sheet that covered the ommisions and ambiguities.

I ran the test vectors against my FPGA design in a simulator and resolved
any mis-matches.

I then ran the test vectors against my FPGA design.
I got the customer to sign off on the results.

A new ASIC was designed from the FPGA design. I ran the test vectors
against my ASIC design in a simulator. There were no mis-matches.
I got the customer to sign off on the results.

The new design was sent off to the ASIC vendor, who insisted on adding
scan test to the design. Their ATPG program got 93% coverage. My test
vectors were about the same size and got 99.8% coverage. The scan test
was removed from the design. Chips were fabricated.

The new ASICs came back, and I plugged one into my test board, and
ran all my test vectors. The chip worked perfectly.

The client loaded one of their production boards with the new chips
and it worked fine.

Philip Freidin

Philip Freidin
Fliptronics

Tobias Weingartner wrote:

>If I had specifications, I'd not waste my time on trying to reverse
>engineer the ASIC.  :-)
>
>  
>
If you have a working copy of the ASIC, you can develop your own set of 
specs based on observations of the ASIC's behavior, no?  Granted, it may 
take a bit of work to ferret out all the operation, but it is likely 
still easier than trying to reverse engineer from masks.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

Ray Andraka wrote about reverse-engineering ASICs based on behavior vs.
analyzing the mask layout:
> it may take a bit of work to ferret out all the operation, but it is
> likely still easier than trying to reverse engineer from masks.

Speaking of such things, I have a number of old chips from which I want
to extract masked ROM and PLA contents from.  Since those are very
regular strutures, and they in parts with single layer metal in 5 micron
and larger geometry, it should be fairly easy.  In fact, here's an
example of someone doing this:
    http://www.pmonta.com/calculators/hp-35/

He extracted code from 10 micron PMOS masked ROMs that were packaged in
metal cans, by the simple expedient of removing the top of the can with
a dremel tool or the like.

I want to do basically the same thing with other chips from that era,
but they're in plastic DIP packaging.  I don't want to mess with
high-temperature fuming nitric acid and such things.  Can anyone
recommend a lab that will do this, and take photomicrographs, at
a "reasonable" price?

Before everyone jumps on me about piracy, I'll explain that the ROM
and PLA code in question is NOT copyrighted.

Thanks!
Eric

Eric Smith wrote:

> Ray Andraka wrote about reverse-engineering ASICs based on behavior vs.
> analyzing the mask layout:
> 
>>it may take a bit of work to ferret out all the operation, but it is
>>likely still easier than trying to reverse engineer from masks.
> 
> 
> Speaking of such things, I have a number of old chips from which I want
> to extract masked ROM and PLA contents from.  Since those are very
> regular strutures, and they in parts with single layer metal in 5 micron
> and larger geometry, it should be fairly easy.  In fact, here's an
> example of someone doing this:
>     http://www.pmonta.com/calculators/hp-35/
> 
> He extracted code from 10 micron PMOS masked ROMs that were packaged in
> metal cans, by the simple expedient of removing the top of the can with
> a dremel tool or the like.
> 
> I want to do basically the same thing with other chips from that era,
> but they're in plastic DIP packaging.  I don't want to mess with
> high-temperature fuming nitric acid and such things.  Can anyone
> recommend a lab that will do this, and take photomicrographs, at
> a "reasonable" price?
> 
> Before everyone jumps on me about piracy, I'll explain that the ROM
> and PLA code in question is NOT copyrighted.
> 
> Thanks!
> Eric
...and, pray tell, how do you get to that conclusion?
   Every time one generates a document or a pattern (in this case the 
codes, masks, etc), such items *by FEDERAL law* are copyrighted!
   In fact, your missive to this NG, and my answer here is copyrighted!
   Now, if anyone wanted to make some lawyers rich and go to court over 
mis-use of copyrighted material, then copyright *registration* would be 
considered as the ultimate proof that judges cannot go against.