IC reverse engineering

Tile stitch

2012-02-11T15:36:00.002-08:00

Now that I have a microscope that can generate lots of imaging data stitching has become the bottleneck. I forget exactly how long but the large memory requirements of gigapixel (GP) sized images made it take a day or so to stitch on my desktop. I might have been fine with this except that something, I suspect enblend or one of its libraries, seems to generate a number of glitches when the images get very large. I've seen this on both 32 and 64 bit systems and should probably file a bug report... In any case, I wanted to reduce system requirements since I figured there was a way to do things better.

Recently I've been playing around with the Google maps API as an idea to use tiles instead of viewing the huge source images. I first played around and tiled a visual6502.org image, the MOS 6522 that you can find here. This is nice as people without powerful computers can view this large image at full detail. To be fair the jpg compression also significantly reduced its size although not to a point where significant quality was lost for my purposes. The tool to do this can be found here.

However, this still leaves the question of how to avoid creating the large intermediate images. After some thinking I came with the following:

nona (a "remapper": transforms source images to their location in the output image) will only output images that are in the cropped area. Note that it will still spend a small amount of time on each of the other images deciding if it needs to generate it
enblend (a "blender": resolves conflicts when two source images occupy the same area) output should only differ in areas where there's a potential conflict
There is no potential for conflict on areas where images are unique. In particular this is the edges and there is less conflict in the center 1/3 of my images since I have 1/3 overlap with neighbors

This allows the following algorithm.

Step 1: get an optimized .pto

You can get this from any source you want. I am using my pr0nstitch program (discussed in a previous post) which I then optimize for size and crop in Hugin. While the Hugin stage could probably be automated its at least doesn't take very long and gives me an idea of how well the optimize went before trying a full stitch.

For this example I'll show a smallish input image. When stitched with Hugin it looks like this:

As an aside, this is a MOS 6522 that I used HF to remove the passivisation and then ate out the metal. Then end result is that you can still see where the metal was (because there is still a lot of SiO2 leftover) while still seeing all of the bottom layers.

Heres a visual from Hugin of what the input looks like:

I think the color gradients are related to me using semi-polarized light on high quality but not strain free objectives (Mitutoyo plan apo 20X). On the bright side it makes the source image boundaries much more pronounced.

Step 2: pick the largest single panorama size you want to stitch

Ideally the supertile should be the largest size that enblend can fit into RAM (and is error free per the bugs I've had...). The software chooses 4X4 source image size by default (~2.5 X ~2.5 shown above) and has a command line option to customize.

Step 3: stitch the selected region

Remap (nona) and blend (enblend) to form a single large panorama image (a "supertile") that is a fraction of the entire output.

Step 4: generate tiles

Greedy generate all tiles that are "safe" following the criteria from the last bullet above. I assume that images around the full panorama are fully safe as well as any images that are more than a half image width in from the border. Add these to a closed list as other supertiles may be able to regenerate them.

In the visual the red crosshatched areas represent areas that are considered unsafe because they are too close to an area where the blending could vary across supertiles. The green boxed in area are all tiles that we can safely generate. Here are a few actual tiles from that full sized image upper left hand corner:

Step 5: repeat for other supertiles

Shift the supertile such that you can generate more tiles safely. This works out to roughly shifting it by the border width + a tile size. Only generate the tile if its not in the closed list.

The tool can be found here.

The first actual chip stitch I generated using this algorithm can be found here. There are a few stitching artifacts but I believe they are more related to bad optimization than the stitching process. I have been somewhat lazily always choosing the upper left hand image as the reference for position optimization. In several of my large stitches images get noticeably worse as you move away from this point. Additionally, there is a bug where I can lose a tile around the right and bottom. Presumably this isn't hard to fix as its probably something I need to just round up instead of down.

The performance improvement is also pretty good. I did several GP sized images and the stitch completes in about 3 hours. I haven't played with panotool's GPU mode to see if that results in any improvement. For reference my system has a 3 GHz Woodcrest dual core CPU (although I'm currently only using one) with 12 GB of RAM. I've been using a 10 GB enblend cache. On that note, I believe this algorithm could also be parallelized to one job per supertile without too much effort.

To be fair as part of this processed I also played around with caching options and such as I learned more about how the remapping and blending phase works. Things on the TODO list for next steps:

Fix the clipping bug
Start using a lens model
Try optimizing from a center anchor instead of a corner
Look into ways to improve the accuracy of the optimize step (ex: statistical deviations)
See what I'm losing by using jpg's over tif's / png's

Finally, my wiki Silicon Pr0n has been down for a while. Now that I have a job I decided to rent a VPS and get a domain name. The wiki is now at http://siliconpr0n.org/wiki/ This URL should now be stable regardless if the server blows up since I can always point it somewhere else. Additionally I have backups in place now. However, I'm still trying to recover some of the old data and it may have some (gaping) holes until I can get it back. I tended to post more material to that then this blog though so its a good resource to have back up.

EDIT:
For the heck of it I decided to figure out how to package this. Try it out at http://pypi.python.org/pypi/pr0ntools/1.0

Also I found that the anchor image for optimization is more important than I realized. A lot of my stitching artifacts appear to be due to my somewhat lazily choosing the upper left hand corner as the anchor which propagated a lot of errors. I'd still like to add a lens model though to see how that further improves error.

CNC microscope mk2

2011-12-15T21:25:00.000-08:00

This post will show my new imaging setup, what I was trying to accomplish in setting it up, and the design decisions I made to get it working.

A bit of history first. This is the first IC capable microscope I got some time on:

But it wasn't well suited for computer control and inverted microscopes are difficult to mount IC samples in. I also got ahold of a biological microscope that could view ICs using a strong halogen light from the side. It did however have room to mount these:

The concept which you can kinda see here:

The mechanics were kinda iffy and worked so-so but it did get me thinking. After I got some money and with a little help I was able to get a Unitron microscope. Looking back it wasn't a super high quality microscope (very old?) but it got me a lot of experience to figure out what I needed. When I was about to scrap it I decided to get a little more aggressive with it and try to retrofit it for CNC control. It turned into this:

Which was finally a working CNC microscope! Very crude but I guess it turned out pretty well for the money and effort I put into it.

And here is the new setup:

Which cost me about 10X as much as the previous setup but is closer to the sort of thing I wouldn't want to run into in a dark alley or fear that might become sentient. It is interesting to note that the first run of this used the motor drivers and motors that the original setup failed to really get working. I only bought the linear stages for the original setup so I suppose the second setup cost about 10X as the original as well. An interesting progression of what you get for logarithmically increasing cost. I don't plan on adding a new point to that curve anytime soon ;)

Objectives

I was looking for several things for this:

Mitutoyo objectives seem to be prized by many, wanted some to try out
DIC seems to give good results

Unfortunately both above are also very expensive. However, with some patience I managed to get both for at least a reasonable deal although neither was still cheap. I got a set of 5X, 10X, and 20X Mitutoyo objectives included with the microscope. They do have good optical quality and long working distance and so have been nice working with.

The DIC was a little trickier. I realized that the prisms aren't labeled very well and someone not very familiar with them might not know how to list them for maximum buck on eBay. So I kept an eye out for the two things that they might be attached to:

Objectives
Turrets

Objectives tend to be expensive and tend to be matched with DIC objectives meaning others find them as well. However, turrets are more of a long shot. Finally I got lucky and found this:

The whole assembly which I got for slightly more than a single prism sells for. Best of all they are nice Olympus Neo SPlan prisms as opposed to an older Neo prism. The set includes 10X, 20X, 50X, and 100X.

Unfortunately I didn't have any NIC objectives or polarizers. The real Olympus polarizers would easily cost me $300 for a pair surplus. However, I'm not sure how special the polarizers are or if you are really just paying for the mounts. So I bought a pair of polarizers for $8 shipped:

Other side:

Basically its 4 pieces:

Polaroid (coated I presume) glass
Aluminum case
Retaining ring (screws in to hold the glass in place), visible in first picture
Lose fitting outer ring, above writing in bottom picture

Unfortunately its too high as is. Fortunately I have a small rotary table which allows me to reduce its height as well as mill a cavity for it:

The section holding the lose fitting outer ring was milled out and it was discarded. This brings us to the device it will rest in. I found an old heatsink of the correct height and started shaping it a little closer:

Which was formed into this with the blank slider for comparison:

For several reasons I wanted the optic to be removable. The easiest way to do that tends to be to use a setscrew to hold it in place. Its a bad idea to put a metal setscrew directly against glass so I decided to use the aluminum case the polarizer came with to buffer the force. A setscrew holds the original polarizer case in the slider. The slider has a step in it so that the polarizer case can only be inserted from one side and holds things in place well. The optic is then inserted and the retaining ring holds it in place. It looks like this:

Which seems to have turned out pretty good. Fitting in the microscope:

And the matching polarizer is loosely sitting in the illuminator so that I can rotate it around:

I tried using a 20X Normarksi prism with a standard Neo SPlan 20X objective but it doesn't give you DIC so bit the bullet and bought a NIC rated one. I didn't get it at a super great price but wanted something to play with.

I also discovered that I had underestimated using polarized microscopy. You can get a number of really neat effects on semiconductors by using crossed polarizers. I think my cheap polarizers give a dark purple-blue color when crossed but I like blue so it turns out okay. I'm glad to have a reasonably high power lamp as this takes considerably more light than standard brightfield microscopy.

XY / linear stages hardware

The core of the robotics section are two Micro-Controle / Klinger / Newport high precision stages. They were listed as being from a high precision milling machine or something. This could be the case as while most stages are direct drive motor to shaft these have a planetary gearbox:

This increase their torque (which I really don't need) but it also makes it easier to move smaller distances. I'm not sure what the actual precision of the stage is but the aggregate step size I get out of the system is about 110 nm. So far this has been far above anything i've needed but it may become more convenient as I move to 100X imaging.

For whatever reason they use variable reluctance motors which I'm unfortunately not as familiar with as stepper motors. I tried making a simple stepper like driver for it but it couldn't hold up under any reasonable load. I read some papers and ultimately decided it was going to be less work for me to adapt some stepper motors on it.

The two drive motors are two slightly mismatched NMB brand NEMA 17 motors. I selected NMB motors since I was hoping that they would use the same connectors as my NEMA 23 Sherline motors but no dice. Even so it has been really nice that the motors have plugs that allow me to quickly disconnect the wires. They are mounted to the stages via some cheap flexible shaft couplers. I had to make some shims to get the 1/8" (0.125") Klinger motor shafts to fit into the ~0.2 NEMA 17 shaft couplers. Note that I didn't remove the motor as it contained the sun gear but rather replaced the opto-encoder disc at the end:

I machined them out of some old steel standoffs by carefully turning them on a rotary table and using a 1/16" endmill to mill out the center. To be honest I was quite surprised I didn't break the endmill. The adapters would have worked really well except that they deform when clamped and so it wasn't a good idea to try to move them around. Things still work okay but I might want to try to make some fresh shims or order some brass rod for a more proper solution.

Robotics electronics

All three motors are driven by Precision Motion Controls stepper drivers. These are fed by a "USBIO" PIC based microcontroller board. Basically I hammer on some GPIOs through USB. On my Linux machine I was able to get some MHz but the Windows machine this runs on seems to be limited to about 500 kHz. I'm pretty sure the motors can move a lot faster than this but it would take more care in software to try to get velocity and acceleration matched well enough so that things don't slip. Since Windows XP isn't exactly an RTOS I'd be surprised if that could be made super reliable but possibly well enough for what I need.

Unfortunately while the USBIO board is powered off of a 5V USB line it uses 3.3V logic. Logical 1 is defined as > 3.5V on my motor units which was causing unstable control. To solve this I added a simple buffer chip powered off of the USBIO board's VCC breakout:

The buffer chip (a CD4069 or something, I forget which exactly) doesn't actually give near 5V out but its good enough for what I need. I couldn't find any industrial style (ie with screw terminal) voltage level converters but I assume they must exist. Its not a terribly complicated circuit board, maybe I'll make some to clean this up a little. I have some perf board laying around which would also probably do the job.

Control software

The software is descended from the original control software. However, its very different in that it performs control in realtime instead of generating g-code. Its at roughly the same location as the original software, I'll probably merge it into the original's location one dir up but until then you can find it here..

I tried a few different imaging libraries and eventually settled on the Python Imaging Library (PIL). Although I had used PIL before for image processing I didn't realize it could do image capture as well. It has mostly worked well but I have gotten truncated images on a few imaging run. I think it may have losely had to do with AmScope software fighting with my software and so I added a check to refuse to start a job if the AmScope software is running.

The USB device has a serial driver so no real magic there. I did write a wrapper class but I already had that from previous projects.

After a little thought I decided I wanted a GUI to make moving around more freestyle instead of entering coordinates at the command line. Most of my GUI experience is using Qt so PyQt seemed like a good choice. Its a "programmers GUI" in the respect that its a jumble of UI components without much thought to ergonomic / careful placement.

Camera

The old setup used a point and shoot with mixed results. It was nice that it could auto-focus but it was bad that it would sometimes focus poorly and that I couldn't decided what I wanted to focus on. So I decided to look around for a real microscope camera and found a AmScope MD1800 (8.1 MP USB) at a halfway decent price.

Originally I was using the camera through the eyepiece but this had several issues:

Tended to move around
Couldn't look through very easily

So I acquired a trinocular head which is where it rests today:

The trinocular head doesn't seem to fix it in place or seal it super well so I made a few crude enhancements. Maybe there is a better adapter I should be using? First, I put a rubber o-ring around the base to stop dust from getting in. Second, I put some rubber strips between the camera and the base and then zip-tied them on. This crudely fixes the camera in place while still providing some stress relief for things moving around.

I attempted to reverse engineer the camera driver to get it working on Linux and kind of got it working except that I haven't figured out how to sync frames. I'll see if I can post some of the data dumps here in case someone has an idea as I'd love to ditch Windows.

Focusing

On the old microscope the sample rested on a kinematic mirror mount (not shown) which allowed basic sample adjustment:

However, this was on a boom so it was difficult to adjust without shaking things around. However, I was able to compensate a little as the main reason that it was mounted that way was so that I had focus control from a precision Z stage. This allowed to compensate a little but didn't solve the fundamental problem. Also, the Z axis was kinda shaky and held in place by a rubber band to keep backlash down (the spectrometer it was scrapped from had the mirror weight holding it down). So for the second revision I tried to improve both of these focusing elements which I'll describe separately.

Active focusing (z axis)

I focused (haha) on this first since its what I used on the old setup. Z axis control is via a NEMA 23 motor with a timing belt coupled to the fine focus knob:

After taking the focus knob cover's off I noticed some threaded rod was sticking out:

Its probably M6 but I don't really know for sure. I had a timing pulley on a 1/4-20 bearing. This sounds like a really bad idea at first since the thread doesn't match and it would just slip around anyway. However, neither of these is hard to get around. 1/4-20 is very similar but not similar enough to mount directly on. Fortunately I had an M6 standoff that fits well on the microscope and that the 1/4-20 screws into pretty well too. Finally, I put a serrated washer between the pulley and the spacer to fix it in place.

Most of my pulleys are designed to fit NEMA 23 / 0.25" shafts which was part of the reason why I wanted to use a NEMA 23 motor. So, mounting that drive pulley was easy. I'm trying to avoid mounting the motor on the microscope in hopes of trying to reduce vibrations and so its currently mounted to the adjacent optics table via 1" 80/20 t-slot aluminum. I have to re-adjust it every time I move the course Z axis but its not difficult to adjust. I've considered several alternatives (attach with damping to microscope, rail mounted, etc) but haven't settled on something more permanent yet, in part because I'm not using this much as described next.

Finally, this has considerably more vibration than the XY motors which makes me less enthusiastic to use it. I'm not sure if its because the micro-stepping isn't adjusted properly on the NEMA 23 or just that it tends to move around more than the smaller NEMA 17 XY motors. I slowed it down a lot more than the XY motors so that its at a reasonable level but I'm pretty sure the mechanics could be improved.

Sample leveling

I also wanted to improve the basic angular control. It would have been nice to have this under computer control but, since its a one time (per sample or sometimes per multiple sample run) setup thing, its not a high priority.

Theory

This is how our system might look to an observer:

The line at the bottom represents the focal plan para-axial with the objective. The pivot is the bearing on which the kinematic mirror mount mirror holder rests. Turning the screw at the end raises or lowers the end of the plate in a single axis and effectively controls a single angle. We are only interested in the top of the sample and not the mirror holder that the sample rests on. I assume the sample is flat such that its surface forms a focal plane. The second line represents some adjustment of the axis screw to form a second focal plane.

Note that this model assumes that the XY plane is still parallel to the imaging plane. This is a non-trivial assumption since this difference is likely to be signifigant and result in requiring active Z focusing to get a good image. However, for my purposes the most important thing was to level out samples like packaged chips that may need significant adjustment. My stages are reasonably precise but I have yet to determine if I need to try to level them out better. The easiest way to do that is probably to insert shims or play around with how tight I set it in. The bottom stage only has 1 out of 4 screws installed and is probably the largest source of imperfections. I have been considering either drilling out the original plate or creating a new one so that it can be secured more regularly.

In this system angles are relatively small, hopefully no more than a few degrees. This allows us to make a small angle approximation so that sin(x) ~= x to simplify the math. This gives a triangle:

The following ar proportional:

a / a' : (t + t') / t' : (z + z') / z'

a / a' = (z + z') / z'

We know a, a', and z and want to find z'

z' a / a' = z + z'

z'( a / a' - 1) = z

z' = z / ( a / a' - 1)

Taking a few simple cases to get a warm fuzzy feeling this is correct. The two simple cases are that the first angle was correct and that the second angle was correct.

If the first angle was correct:

a = 0

z' = z / (0 / a' - 1) = z / (0 - 1) = -z

That is we have to go back to where we were originally

If the second angle was correct:

a' = 0

z' = z / ( a / 0 - 1) = z / (inf - 1) = z / inf = 0

That is we stay where we are.

Practice

In practice this above turns out to be too cumbersome to do by hand. If I had computer controlled tilt capabilities (such as with a Newport / New Focus 8071) these formulas might be more directly useful. I tried to apply them and the time to whip out a calculator and try to turn the knobs "just right" doesn't work well enough.

However, you can observe that if you iteratively do the following:

Focus on a point close to the pivot, ideally the edge of the chip is on it
Move to a distant point on a single axis, ideally the other edge of the chip
Adjust the screw until in focus
Move back to original location. If its still sufficiently focused you are done with this axis
Repeat for the other axis

I'm thinking of marking some guidelines on the stage to make placing chips at the pivot point easier as this is theoretically just a single pass when that's the case. If they are not at the origin it will take more passes but typically not more than 4. For a large chip such as some GPUs I've been imaging my stages are slow enough that it can take 2 minutes to reach the other side. So, for these chips its taking about 20 minutes to level. Its not so bad though since the manual interaction doesn't take very long.

Ultimately this seems sufficient without any active Z control. On this setup the stages seem para-axial enough to the focal plane that I don't require any active focusing control. Since using an active Z axis still doesn't eliminate uneven focusing across an image this method is generally preferable. Currently the main advantage of the active Z control, although I'm not using it much anymore, is that it reduces setup time since it only requires collecting three or four points in a fairly small timeframe.

Next steps

I fed some images into the stitching software I was using before and they come out a lot better because of the closer to planar setup. I played briefly with constructing a more proper lens model and it would be a good idea to give that another go.

I'd like to share the chip images but I'm realizing they more or less take up obscene amounts of bandwidth and storage. I briefly played around with a Google maps style display but didn't pursue it very heavily as it may at least cut down bandwidth and relieve the burden of needing to open huge image files.

I played around with some focus stacking but wasn't terribly impressed. I need to see if I can find some more fine tuned options in panotools or look into alternative software. This is a real problem at higher resolutions (ex: 50X) on large chips where there may be many layers. If I only store the final focus stacked images I don't lose much disk space or imaging time and the pictures in theory can look a lot better.

Somewhat unrelated and on my TODO list is to finish digitizing the MOS 6522. I put a lot of work into getting a better imaging platform and I'm now getting pretty satisfied that I do. I want to focus future work on acquiring data and automating analysis. My first goal is to try to find techniques for automatically extracting the metal layer. Among image processing techniques I'm thinking of trying to use IR light since everything else should be pretty transparent to it. However, there are a large number of minor difficulties to get this to work so I may try visible techniques first. One thing in particular is that metal tends to saturate the video sensor without any polarization which I could probably use to my advantage.

I'd like to be able to rotate samples easier and install my larger and flat kinematic stage. The easiest way for me to do that is to remove the bottom illumination lamp housing / stand and replace it with my Newport rotary stage and a riser plate. I'm looking to see if I can get a precision lab jack like a Newport 281 but they look like they cost more than I want to spend. However, I've already had some commercial interest in some people wanting to use this system for wafer failure analysis imaging and so it might be worth the investment as it would allow me to image wafers a lot easier.

Finally, I'd like to improve the motor mounts so they are wiggle free. This shouldn't be too hard as I either just need to spend some time on a lathe (I don't have one but I have a Tech Shop membership) or to order some telescoping brass tubing and fit as needed. While this doesn't seem to effect imaging too much I'm sure its not ideal on the motors and probably causes friction that could effect repeatability, especially if I want to raise speeds.

Why basic logic chips are bad for beginners

2011-09-22T23:10:00.000-07:00

For a while I was making a big push to try to decode a basic logic chip such as a CD4001 or a 7402/74HC02 sort of thing. The justification was that they would be very simple to analyze because:

Feature size is large
Simple logic function
Many examples of the same chip to compare
Inexpensive
Non-CMP: can help to see layers

However, I've come to the conclusion they are actually rather difficult to analyze over larger chips for the following reasons.

Highly irregular transistor size

On modern chips transistors have to be cookie cutter sized in certain processes not to mention they are often used in standard cells. Even a more custom chip like the Intel 4004 has somewhat irregular transistors but they still tend to be pretty limited in size.

Basic logic chips have irregular transistors for several reasons. First, due to low transistor count, every transistor gets loads of attention. They will be molded and shaped almost like an analog chip instead of a digital chip

Less data to work with

Having fewer logic functions that you need to figure out also means that you have fewer to use as examples. I did mitigate this a bit by decapsulating several since decapsulation time / photography time isn't too bad for SMD versions.

Use of less common technology

This isn't necessarily bad in itself as it gives you more breadth, but it can still get in the way. For example, CD4000 uses metal gate which are interesting for historical reasons but not used on typical modern chips. 7400s are similar since most modern digital chips don't use bipolar logic.

To hammer on this point a bit more, lets move on to...

Use of power transistors

This one is really the killer since it makes the chips really different. Even microcontrollers will beef up output transistors, but nothing like you'll see on these chips. Heres something more or less like a textbook MOSFET:

Metal gate which isn't quite so common, but you have a clearly visible source gate and drain. This is what I was hoping to see and to be fair I did find two chips like this (above is from a Fairchild CD4011). Heres an example of a transistor for a Texas Instruments CD4001:

Top metal:

And delayered with HF (same chip, not the same die):

I saw some structures like this and thought they might be diodes since I figured they were forming a PN junction. However, if you read this you'll see that these are probably actually power MOSFETs and in particular Vertical Diffused MOS (VDMOS / Double Diffused MOS (DMOS)).

Its also worth pointing out the first image was taken on a Unitron N + Aus Jena (Zeiss) objectives with 3.2 MP point and shoot while the latter was taken on a Mitutoyo microscope + Mitutoyo Plan Apo objectives with an 8.1 MP AmScope eyepiece camera in case you are wondering why the latter looks so much better.

Conclusions

So what would the best chip to learn on be? The Intel 4004 is a really great example since it has so much documentation and Flylogic has provided very nice images. On the downside its not something you'd want to do yourself since a 4004 might cost you $150 or more. There are plenty of similar less expensive chips of that scale though that should have similar value.

Understanding the Intel 4004

2011-09-14T12:09:00.000-07:00

I have a new microscope that yields way better images than anything I had before, but, unfortunately, I'm having some difficulty getting a camera hooked up to it nicely. In the meantime since I still have images from other sources I thought I'd take some time to go through some parts of the Intel 4004. Flylogic has a similar write-up. This hopes to got a bit deeper especially showing how you can use tools to scale this up to analyze the/a full chip.

This article will use data from a variety of sources. The first is the Intel 4004 35th anniversary page which I like since it explicitly lists material as Creative Commons Attribution-Noncommercial-Share Alike 3.0 License. They also have a composite image (this is the author of the 4004 website so I presume its under the CC license?), schematics, and other assorted information. Datasheet and user manual can be found on Intel's website. I got the masks from FPGA-netlist-tools and read them in CIF format, specifically this file. if you don't want to load this up, you can find the original here. Finally, I'm also going to use a few small excerpts from the Flylogic top metal image and the Flylogic delayered image which I think should be fine under fair use but will take down if they would rather not have them here. I thought Intel had some CC or related images (had maybe even contracted the Flylogic) job) but I can't find those now. If there are no freely available images, if someone wants to donate a 4004 I could release some under a free license of your choice (or three if you have a million: one top metal, one delayered, and one for my collection!).

According to Wikipedia, the 4004 is 10 um pMOS which I was also able to verify on the datasheet ("4004 SINGLE CHIP 4-BIT P-CHANNEL MIROPROCESSOR"). This is similar to the NMOS logic I used in my JSSim inverter write-up except with the polarities reversed. Example PMOS inverter here.

However, I started getting a little confused as I started to look through things. Lajos describes pull-ups when I would expect PMOS to have pull-downs. Looking at various circuits, I also see what appears to be pull-ups. This confused me since I was thinking something along the lines of VDD = +5V, VSS = 0V with non-TTL compatible I/O (I didn't think through if the body connection is correct polarity, probably best to ignore it):

However, this doesn't really work since people would expect TTL compatible and this doesn't mask what I'm seeing in the mask as noted above. However, after looking at the user manual I found this:

Which shows that VDD = -10V and VSS = +5V which allows it to preserve TTL-compatible I/O. It was paired with this summary diagram:

The input stage shows why they want the +5V VSS: it provides the negative bias to trigger the PMOS input at 0 V while still allowing the pull-up to supply negative power for the input = 1 case. I was told that if you think of the circuit in terms of VDD, VSS, etc rather than actual voltages it should be more or less identical to NMOS logic. However, my understanding is that the depletion resistor is wired middle to bottom instead of middle to top so to speak as above. I don't have a good enough understanding of depletion modes to really know why this is the case.

That cleared up, lets see an example. I decided to look at the upper left hand corner because it was convenient. Cross referencing with the schematic a particular signal such as TEST might have been more logical if I was following the schematic rather than focusing on the masks. Here's the metal mask with VDD and VSS highlighted as well as an upper left hand corner area that I'll look at later in orange:

And a complete version also marked, but without VSS/VDD highlight:

Lets start with a theoretical closeup. Here's a dump from my CIF rendering:

The red (okay so its pink, otherwise I had opacity related rendering issues) is poly, the green is diffusion, the blue is metal (VDD), and the black are contacts. So we have two contacts tied to VDD and one going elsewhere which forms our pull-up. Note that you might have a self aligned gate for an enhancement MOSFET, but for depletion the entire area is diffused for normally on behaviour. This is what it actually looks like (Flylogic) in metal:

If the poly had blocked the diffusion we would not have seen the diffusion squiggle inside of the poly area. If they poly and diffusion masks were reversed, we could still tell that they were layered vs blocked since we can see a change on the squiggle exit rather than a solid line. And after delayering:

The poly and diffusion look almost identical. Fortunately, with whatever microscope technique they used (DIC maybe?) they get some good contrast between the traces and the background. I can't say for sure why it discolors where they meet, maybe just minor stress due to proximity.

Okay, but one transistor is the middle of nowhere is kind of hard to follow, so lets take a look at some of the nearby pins and see how it fits in. The upper left hand corner ties in the CM RAM 0-3 pins increasing clockwise starting with CM RAM 0 and 1 on the left and 2 and 3 on top:

These pins essentially provide the chip (bank) selection outputs to the RAM chips (4002). Since you can operate the system with a single 4002 this is an optional pin. Nonetheless, its fine for demonstration purposes. Lets arbitrarily focus on CM-RAM 0. Detailed picture of its layout:

The first thing I did was label all of the transistors that looked like they were involved in this input stage:

There is an identical input stage above that shares a small bit of poly with Q4 (diffusion just visible), but this does not influence us so ignore it. I then created a schematic with transistors arranged like in the above:

This is fine for layout capture, but a little ugly to read. Lets rearrange it to something a little nicer:

And then simplify by converting transistors to resistors where appropriate:

Cross referencing against Lajo's schematic:

They are equivalent. I'm particularly happy with this because this would have taken me a long time before but I got this pretty quickly and without having to fudge anything.

Okay, but that's only part 1 where we've managed to reverse the mask into the schematic. For part 2 is we need to see if we could figure this out from just the optical image. Here's top metal:

And delayered:

Which I've just roughly cut by using a box select + copy/paste from the full size images. I could of course work with the full size images, but they are large enough that they take up a significant amount of memory.

Anyway, I then imported them into Gimp by creating a new, slightly oversized canvas (700 X 700), importing them as layers, and setting their opacity each to 50%:

You'll notice the two images aren't quite aligned. This is why I wanted the oversize canvas as it allows me to move them around. Move them around until they line up. I should mention that I am by no means a Gimp expert, so don't take anything I do as to be the best was possible.

Next I created a layer for each mask. Since its difficult to tell buried contacts from contacts just by looking, I just created a single contacts layer (there there aren't any in our example). Since metal is very clear and un-ambiguous, I started with that by turning opacity back off and hiding the delayered image.

Press B to select the path tool. Click around a metal segment to form a polygon, remembering to click on the start portion to close it. You should now have a dashed line around your metal segment:

Then press shift-V to convert the path into a selection. Then press shift-B to select the fill tool and select a color (I used blue). Finally, fill the color in by clicking the mouse on the selection and then de-select your polygon by press ctrl-shift-A:

Make sure you put it on the metal layer by toggle show/hide for the metal layer. I believe this is the technique that was used to create the masks for the visual-6800 (plus a tool that converted the masks to JSSim input). A few tips:

You don't have to de-select the previous path. Just start working on the next one after fill and previous will automatically de-select when you convert it to a new path
You don't need to close the polygon. Last and first points will be assumed to be connected

One metal is done contacts are good to do next. As we saw with the original pullup, diffusion and poly can be difficult to tell apart just by looking at them. However, we know that IC designers have specific goals, so we can use those to figure out which is which. That said, some ICs are obfuscated, but we'll ignore that for now. Poly will usually cross diffusion areas. In particular look for it jutting out to complete a diffusion cut-off. That said, in the Flylogic 4004 example poly tends to get a lot of brown discolouration while the diffusion does not.

My first cut looked like this:

A few issues:

Need to figure out how to make level paths in Gimp so that it looks nicer. Right now it looks more like a kindergarten or abstract art drawing
The bit of diffusion that forms the pullup is not connected. Cross referencing with the masks, it is suppose to jut out to the side to go to a buried contact / via stack. However in the image it looks pretty clearly to NOT do that to me as I clearly the the edge of the diffusion. Maybe I'll get some feedback to clear this up
I also made an error with some poly to the right of this going to a buried contact, but this is visible in the images and a double check would have caught this. I also cared less since it wasn't part of the circuit I was analysing
What is the stuff under the pad? Maybe diffusion, but its not in those masks. There is a matching passivation mask but that should be on top and this is on the lower layers

This is close enough to the original that I think I could have derived the same schematic although maybe with low confidence on the pullup part. The rest of the chip can be decoded be continuing this exercise.

Hopefully this served to augment the Flylogic article and not just repeat it. In any case it helped me to make sure I really understood it.

Probing sneak peak

2011-08-08T23:40:00.000-07:00

I was going to hold off on this since its a bit premature, but since Hyna wanted some details on what I was hoping to do for a probing station here is some quick info.

Since this is still just a part time hobby for me, I didn't want to spend too much on a probe station and waited patiently (course of a year or two of saved eBay searches...). I picked up several micropositioners for pretty good deal but had a much harder time finding a halfway decent probe station inexpensively. My goal was:
-Under $500, especially if it didn't have a microscope
-Have XY axis
-Have a solid platform for mounting probes
-Either have a microscope or not be too much trouble to add one

With that in mind, I eventually found this

Which was decently within budget and even had a Nikon microscope of sorts. The base is pretty solid which was the main thing I was after. The plugs (not visible) happily fit my micropositioners.

Unfortunately, the microscope is not in the best condition and not made with high quality components. However, there is a lot of mounting support and so I kept my eyes peeled on eBay for something I could replace it with. I was looking for something like a Nikon Optiphot since I knew a few people use that with good results. Eventually I found this:

the core of an Olympus BHMJ which seemed like a good match since you can mount it with a boom stand like on mine. It seems well cared for and in good condition. Before purchasing I did some measurements on my station and cross referenced some Olympus documents and was under the impression that the post was even the same diameter. Unfortunately, this turns out not to be the case, but I have access to lathes and so can make a new post without too trouble if I allocate some time for that. This is more of an industrial class microscope that I can buy numerous accessories and high quality optics for as I want to upgrade. I need to take a picture for comparison, but these are 25 mm compared to the standard ~20 mm thread RMS objectives most microscopes use.

You may have also noticed that the microscope didn't include an illuminator. However, I have one in the mail and should soon be able to do a test drive. The Nikon parts are not compatible, but the Nikon lamp setup was pretty bad anyway.

I also might want to switch out the stages for something more accurate. I use to play with lasers and so have a pile of optical quality micropositioners. On that note, you may have noticed the odd orange cord wrapped around the microscope. For some reason the camera port is loaded with a colminator with an FC fiber port + fiber. The exposed end of the fiber is in poor shape, but fiber is relatively inexpensive if I want another. I am not entirely sure what purpose it served though. I asked someone in the photonics business and he mentioned he'd used similar equipment for testing at his facility. I have some YAG lasers...maybe could be retrofitted for microsurgery?

I may look into getting a trinocular head to mount a camera. In the short term though I can put my camera in the eyepiece.

I also decapsulated a chip with some RFNA the other day with good results. For a sneak peak see https://picasaweb.google.com/JohnDMcMaster/First_rfna_decap?authuser=0&feat=directlink but otherwise I'll wait until I can try a second chip and do a more careful job (although the first chip did work, shown below "blinking" although all you can see is a solid on LED)

Edit: some more sneak peak https://picasaweb.google.com/JohnDMcMaster/Ic_live_analysis_08142011?authuser=0&feat=directlink

A less simple experiment with JSSim

2011-07-10T16:45:00.001-07:00

In short:

This post builds on a previous post where I described how to manually build a NMOS clock driven inverter in JSSim. It gave this (see it live):

I concluded by saying I was going to look into automating it and here's the first cut. I tried poking around for tools to automatically convert image files to JSSim files. They seem to either be not fully automated, don't exist, or are squirrelled away somewhere where I can't get to them.

The squireling possibility comes from that I would find it hard to believe that someone actually typed up all of the content in the *.js files. They are difficult to read as is (polygons are position dependent x/y coordinates in a long array) and it seems it would be error prone and tedious to generate that much data from the image files. That said, it did take them a large number of hours to complete the 6502 and it may not have been worth it.

Quietust wrote a toolchain more recently that you can find at here (my sandbox copy on Github). Since it only appeared recently it could not have been used to generate the 6502 meaning there is still a missing link even if there is an alternate route. I messed with it briefly and could not get it to parse my input SVG files. I've since learned more about SVG and probably will have a better idea of why it couldn't parse them (SVG is a huge specification, can specify a rectangle as a rectangle, polygon, patch ,etc), .

Finally, the first point that they are not fully automated comes from the fact that FPGA-netlist-tools. This toolchain is centered around producing synthesizable HDL from a variety of sources (images, JSSim). It has some good tools that pull in a lot of support from Magic VLSI, KLayout, Icarus Verilog, potrace, ImageMagick, gdspy, scipy/ndimage, and more. For example, I was impressed with how little code masks_to_netlists.py (136 lines including comments) used to create netlists from chip images. I was told that it may be possible to convert the output into JSSim files but haven't thoroughly explored it yet. It might not be too much work but I do need to learn more about various EDA CAD formats (CIF, GDS, spice, tech, etc) to figure out what I need to do.

Ultimately I decided I'd rather see how hard it is for me to do it with what I had available and then add support, rework, and integrate with the other tools as I learn more about them. I probably learned a lot more about for example, SVG format this way than I would have by blindly using the other tools/libraries.

For my test case I started by redrawing my image in Inkscape:

after deciding SVG would be easier than a raster image (ex: .tif) to parse. I tried a few conversion utilities with the following results:

Open .tif in Inkscape and save as .svg: .tif embedded in .svg, not useful
Convert using ImageMagick "convert" utility: created an element for every (non-white?) pixel. Impractical

Fortunately my chip isn't large enough where re-drawing is an issue. FPGA-netlist-tools seems to use potrace with good results for this type of conversion. I'd like to experiment with FPGA-netlist-tools and/or potrace directly in the future to see what I can leverage.

In order to convert an image into decent JSSim code you need to do the following:

Render polygons to screen in correct layer in correct net
Figure out net connections: which components are connected
Identify transistors
Identify pullup resistors
Identify net names for inputs (and potentially outputs too)

You should also do the following although they aren't critical:

Provide transistor geometry. Its used to find transistors which isn't used in main simulation

I wrote the tool in Python and somewhat arbitrarily chose "xml.parsers.expat" to parse the XML. I'm not sure if I could have leveraged anything by using a more integrated SVG parser. One thing I found I had to be careful with was how SVG / Inkscape liked to throw viewports around which led to nested coordinate corrections.

Rendering the polygons is fairly straightforward input to output conversion. After a small bit of research I decided to use Shapely's libgeos GIS library Python bindings for polygons. My simple SVG files were only rectangle, so I only had to parse rectangles. My core engine is built on polygons though and does work with them as demonstrated by the fact that I was able to merge rectangles into single polygons. However, since I drew the polygons as rectangles, I had to combine them. Otherwise you get results like this:

The alpha transparency on the metal doesn't overlay well and shows the underlying construction. I eliminated this by simply using a polygon union function on intersecting polygons on the same layer, replacing one of the polygons, and removing the other. You may also observe the image is upside down. SVG uses an upper left coordinate system and JSSim uses a lower left which means final conversion requires a horizontal flip.

Nets were decided by first assigning each node to a net. I then merged nets when one of the following happened:

A polygon intersected itself on the same layer
A via intersected diffusion, poly, or metal

Nets were then renumbered for the final output rather than trying to eliminate holes during the merge process.

I thought transistors were going to be difficult to identify but it turned out to be rather simple at least for this simple case. Transistors occur when two diffusion regions are separated by a poly gate (or metal gate for old school CMOS, but uncommon and not supported right now). I expanded each diffusion and poly polygon around its center of mass by a few pixels to find near neighbors and plotted the intersection (plotted using Tkinter):

I'm not sure how this method will scale but will see as I try it out on actual chips. In particular it will only accept the match if there are two intersections but I could easily imagine two gates being controlled by the same poly segment. I'll have to add some arbitration logic to sort out the connections if/when that becomes an issue. With two diffusion nets and a polygon net, we now have the two connections and the gate nodes respectively. I'm currently using the entire poly segment as a rough approximation of where the transistors is but maybe a better approach would be to try to protect between the two intersection polygons.

Pull-ups aren't that hard to identify once the transistors are identified. A pull-up requires the following:

One connection to positive voltage / VDD
Other two connections shorted together

Simply iterate over the transistors and mark the doubly connected net as a pull-up net.

Finally we have to identify the net names for input and output so that we can actually play with the chip. FPGA-netlist-tools specifies node names as a text file with the various coordinates and names specified in the file. However, I figured I could take advantage of SVG's being able to store text and place that information directly in the layers. From a conceptual standpoint I look for the intersection of the textbox polygon with a net and label that net which is similar to the point concept. This seems fair to do for the following reasons:

Most important signals are on the pads which typically don't have wires running under them in a non-flip chip padframe
Current chips don't have enough layers that they can't be unambiguously identified. In theory a very dense chip could have multiple metal layers that make resolving which layer we refer to ambiguous
Could potentially allow layer specific labels if there were collisions which would allow unambiguous identification. Alternatively could put some markup in the name such it gets identified. For example, instead of "clk0" put "metal2:clk0" to say that clk0 belongs to metal2 which would otherwise be ambiguous

Here's an example showing the text boxes (displayed using a rendering glitch in gthumb):

You have to careful though since text boxes can be much larger than the text. For example:

If this box was any bigger it would have hit diffusion and caused issues.

When the tool runs it looks for layer files in the current directory and spits out *.js. Running in JSSim (see it live):

We now have straight polygons! Mostly anyway. Zooming in:

In particular you'll notice this since it makes segdefs.js larger with the extra 2 points we added. If you look back at the non-merged metal it should be pretty obvious where this comes from. If I care to remove this I'll have to implement some sort of smoothing function to remove points close to each other.

My next step is to try to convert some of the chips in FPGA-netlist-tools into JSSim chips. I believe polygon intersection is somewhat computationally expensive and may have to implement a quadtree map for efficient large scale operation.

Until next time.

Epoxies

2011-07-10T14:10:00.000-07:00

Plastic chips come in a variety of epoxies. Some sample chips:

Chip 1 was in acid for a short amount of time so its not a completely fair visual, but it looked about the same before going in. Anyway, In order of increasing glass content, these chips are 2, 3, 1. 3 is a PDIP-40 Microchip PIC, 2 is a TI chip, and I forget what 1 was although I'm tempted to say it was made by ST. Chip 1 decapsulates very qiuckly, 2 is what I'd call normal or a little better, and 2 is difficult. You can see what 1 looks like being in acid for a few minutes, here's what 2 looks like after sitting for a while (with 1):

It forms a hard sediment at the bottom of the beaker instead of really breaking up. There's so much epoxy that acid soaking in actually become noticeable instead of the chip breaking up like usually happens.

1's surface looks like this under a microscope (maybe 10X):

Notice all the junk in there. It makes dissolving it much easier since not only do we not have to dissolve that stuff, but it falls out, pitting the surface and making it corrode faster.

Here's the side of 2:

Interesting that the top and bottom look a little different, I'm not sure if its related to it being hard to dissolve as I haven't got a chance to compare it to similar chips.

And here's 3 (maybe 10X):

You can see some particulate in there (maybe not as apparent in this lower res picture?) and its lighter in color than the 2.

To finish off a few things not related to epoxies but came up during this. This thin package had the die close enough to the surface that it actually managed to poke through long before the package was dissolved:

Also when you do a large lot you get a pile of that junk leftover:

I use to use HNO3 to get rid of it, but it tends to dillute quickly and dilute HNO3 attacks aluminium. Fortunately its unlikely that you'll need to decap any valuable chip in volume so you can safely just pick these out with tweezers for most chips. I'm afraid of the chips scratching but the passivation is pretty strong.

Until next time.

Preparing for live analysis

2011-07-04T19:37:00.001-07:00

I have a probing station on the way and am going to try to start learning about live analysis because it will allow me to confirm my understanding of chips. That is I'll predict the state, apply voltage, and then check the levels on the chip. Later on it will of course be useful for numerous applications (probe lines, change signals, etc).

My very first attempt was using 70 % HNO3 on a hot chip a while ago (maybe a year?). Rinse, repeat until exposed. Unfortunately, this method is very slow and takes about an hour of work for a PDIP. Even if you don't care so much about your time, so many handling cycles is dangerous for the chip (thermal stress, break bond wires, dissolve Al, etc).

My next attempt which I only partially went through with was an attempt to automate the above a little. I Dremeled a hole in the bottom of some glassware and filled a beaker with a small amount of nitric. It was then RTV'd onto the surface of a chip and the whole assembly heated. Early results were promising, but its somewhat dangerous if you run out of RTV before the chip is done. Additionally, you can't see the chip's surface so cannot gauge progress easily. I was also left with some residue on the chip. I'm not sure if it was from improper cleaning or more than usually since it was all pooling into the acid cavity.

I didn't go back to this for a while mainly because without a probing station it wasn't a good use of time when I could just throw the chip in an acid bath with much less work. I've recently been moving onto more complicated scenarios and now consider live analysis to be a key objective for the reasons stated at the beginning. However, I value my time and don't want to spend a lot of time putting drops on a sample or dealing with RFNA for assorted reasons. Professional shops use decapsulation machines that squirt acid jets. Could I do something similar?

I started to think and I decided the first thing I should try is to see if I could build an automatic decapsultion with equipment I had. I had a rusted out peristaltic pump which seemed like an okay place to started. I gave up on the motor and rigged up a flexible shaft to it. See it in operation here.

This fed an H2SO4 from the bottom of a beaker which was to squirt a chip on a raised platform in the same beaker. I knew someone that said UL would approve anything, but probably not this. The machine was flat out hazardous for the following reasons:
-Exposed spinning shaft
-Pressurized heated acid on surplus / scavenged parts
-If the acid flow was uneven it could stress the glass and break it

It also suffered from some practical problems:
-I could not get the acid hot enough. I guess a combination that the glass insulated the chip too much and the acid cooled too much (although it was still pretty hot) before it reached the chip
-My platform was just an inverted beaker (inside a larger beaker) and the chip could easily get knocked off

I'm not a man easily defeated though. I spent some time to think about what I could do better. I got some PTFE beakers which I drilled out to make PTFE baskets so that I could take chips out of acid baths easier. Probably a short post on that at some point. It got me thinking: although I couldn't machine / shape glass very easily, I could easily machine PTFE. My goal was to make an assembly that would shield the chip from the acid except for a milled out impression where I wanted it to etch. I ordered some stock, ordered some PTFE bolts, and already had a PTFE sheet.

Before chips can actually be used, its a good idea to mill out a cavity (I used 3/16" (0.1875") TiN coated endmill for 0.3" pitch) so that the die will be reached much faster. Make it less wide than your chip so that you don't collapse the lead frame from excessive etching on the sides. Professional shops x-ray the chips, but you have a few options:

Rule of thumb: mill halfway to the top of the leads
Sacrifice one to find where the bond wires are. Might be worth it if you have a pile of them, although it still will probably only be an approximation
Don't mill it at all if its very thin. Certainly shouldn't be your first sample though as you'll have more issues with the lead frame collapsing
Some professional units short all of the pins and wait for continuity to the bond wires. I tried putting some water in the cavity to help detect when they were getting close, but could not do it reliably

In any case, inspect after milling. Try adding water to make bond wires more apparent.

When I was experimenting with the continuity method I got sloppy and didn't pay attention to depth. The endmill hit the Si. While not dangerous to the user, it did ruin the tip by dulling it and taking off the TiN coating (as a reference, silicon is 7.0 Mohs hardness but even titanium is only 6.5) Afterwords packages would heat up instead of being cool to the touch. I'm also told that excessive heat can burn the epoxy and make it difficult to dissolve although I haven't seen this yet. Healthy endmill that went too far:

Dull endmill that went too far:

You can see the wires are more smeared around than cut. For example, in the first image you can make out the bond wire arc cross section but they are more scattered around in the second. Both will still feel pretty sharp to the touch so I'd reccomend you start with a new endmill or be very careful. Another problem with using a dull endmill is that it requires more pressure to start a cut. You need to take off very thin slices and a dull endmill will tend to "bite" and then take a larger slice out. I had good luck using a sharp endmill in a breadboard. The breadboard / pin contact provided a small spring factor which allowed very slow, precise cuts. Additionally, I was able to place it back into position after inspecting depth.

I assembled my piece and lowered it into a beaker after milling a small cavity into the top of a PDIP. To avoid letting the epoxy slag accumulate in the cavity, I put it into the beaker upside-down. This aspect seemed to work rather well. Unfortunately, a few things didn't. First, I misunderestimated PTFE's thermal expansion coefficient. The block expanded a fair amount and wedged itself up against the glass. I feel lucky that it didn't break. Second, related to the first point, PTFE becomes soft at higher temperatures. This had two effects: making the gasket droop down, breaking the seal, and shearing the bolts from the added stress and being softer. Another thing that I did was to tack the chip in place with RTV. Initially I used just a small amount, but I tried to fill it in after seeing the gasket wasn't going to hold the chip in place. I then went so far as the flip the assembly over, but this caused the predicted slag problem. Although there was a clear separation between the epoxy that was still part of the package and that which wasn't, it couldn't be removed without destroying the fragile bond wires. Finally, the larger volume of RTV was significant since it got attacked more readily than the epoxy.

Although it didn't work out, it was a step in the right direction. The PTFE bolts were kinda expensive though so i was a little bummed about that. What if I just made a sold piece? I could prevent circulation at the top by not filling the bath above the top of the assembly. Acid would then stay stagnant in the middle and most likely cooler. And here it is:

After adding some handles to take it out of the acid easier:

The idea worked quite well. I was able to see though that the stirbar:

wasn't knocking the bubbles out like I thought it would. I solved this in two ways. First, I filled the cavity up more carefully from the side to let the acid flow in from the side rather than letting air bubbles get trapped if the acid was just poured in. Second, I drilled two holes on the side to let air escape. While it does increase package corrosion, it didn't see to signfigantly since the acid was mostly hitting the milled out portion.

The first chip gave very good results:

Die before any cleaning:

After pressurized water (although acetone would be preferred if I was serious about keeping it alive, water is hazardous to circuits. 98% H2SO4 is hygroscopic and should not contaminate the chip):

Ultrasound would probably clean it up nicely. Beware though if the connections are weak you may knock them off. Try shielding the ultrasound / user lower power or soaking first and see if it will take it off before running at full force. On a related note, be absolutely sure that you've cleaned the chip thoroughly to eliminate acid. Use acetone, 98 % rubbing alcohol, other other things that won't add water. Put it on gentle heat after to drive out any leftover moisture and store in a sealed container away from moisture and dust. Dissicant is probably a good idea. I had a chip I just flat didn't wash after doing this to, need to take a picture of it.

I need to also test to see how much this special jig helps vs just milling and dumping in the bath. Since the acid doesn't corrode the pins very fast, it may very well be sufficient to just dump it into the bath as is.

I'd like to eliminate the RTV completely by making some PTFE spacers. They'll go on the side of the chip so that it gets held in place better and allows less acid to flow to the top.

An associate has started to experiment with making microprobes which turns out to not be that hard. I think he told me its something along the lines of put tungsten rod in 20 % w/v KOH and run some current through it with a certain polarity. I was told the other parameters but just can't remember them off of the top of my head. Hopefully he'll do a writeup on at some point or I will once I have a need to start making probes. I recently received a probing station and so this might be in the near future.

To summarize, here are the key points

Your first chip should be easy to handle. Try a PDIP as they are heavy duty and have lots of room for error. Whatever you chose, you'll probably want to mill it and will want a way to securely hold it
Start by milling out a cavity. Use something narrower than your package to avoid collapsing the lead frame. Halfway from the top to the top of the lead frame is a good rule of thumb
Mount the chip upside down in a acid proof jig. I used PTFE, glass would also work fine.
I used a stir bar to increase circulation although I have yet to prove it actually helps
Make sure you can take the chip out of the bath to check on it. You can't under-etch and over-etching endangers the integrity of the chip. Be aware though that thermal shock can kill the chip
Avoid using water when rinsing. Use hygroscopic and / or water free solvents. Use ultrasound carefully as it may knock off bond wires.
Gently heat dry it when done to be sure you've driven out moisture
Store in a dry location. I use centrifuge tubes. Desiccant is probably a good idea although probably not needed

A simple experiment with JSSim (visual6502)

2011-07-03T16:36:00.001-07:00

The folks at visual6502.org have really done a great job on their project and I've been meaning to get more familiar with their work for a while. Now that I graduated I have more time for these projects and was able to dig in over the past week and especially yesterday. Bottom line: my experiment can be found at http://johndmcmaster.github.com/visual6502/ and a demo at http://johndmcmaster.github.com/visual6502/tutorial-inverter.html This writeup is based on my git commit 6a613ee1131bbdec9a8bf4b6eeb02d13147842ab which was forked from mainline's de265ecdb89d8c5d299f09ad69aaf8b87b1aed5d. Changes are as noted, but most code snippets are copyright Brian Silverman, Barry Silverman, Ed Spittles, Achim Breidenbach, Ijor and maybe some others that I missed. See the github source for details.

I don't have much experience with JavaScript but I have enough experience with C like languages that it isn't really hard to use and just try to follow the syntax of things around me. I started by moving the 6502 into its own folder like later chips have been tending to so that I could focus on the relevant files easier. For those not familar with visual6502, here's a screenshot of the 6502 running in JSSim (Java Script Simulator):

Although its not obvious from the still picture, metal, poly, and diffusion are being colored according to their voltage potential. Wow! An outstanding way to learn about chips. However, the complexity of the simulator scared me from really trying to understand how it worked. Fortunately, most of the work is put into the data and the simulator core is easy to follow. In this post I'm going to step you through how visual6502 works and how to create a clocked inverter circuit using simple tools.

The first thing that you'll need is a reference diagram. I somewhat arbitrarily decided to try an NMOS inverter since I knew the 6502 was NMOS logic and could look at an example if I got stuck. An inverter just seemed like something I could easily clock with a single input. Lets start with a brief review of NMOS logic since these days its all about CMOS. In NMOS logic, we use a single transistor polarity and short out voltage through transistors to invert outputs. Here is an NMOS inverter from Wiki:
When A is 0 the switch is open and current can flow from VDD through R to OUT (A: 0, OUT: 1). If we put voltage on A (gate) the switch is closed and shorts out OUT (A: 1, OUT: 0) through the drain at top and source at bottom. NMOS was discontinued because CMOS didn't have the issue of needing to short out a resistor (power consumption when input is 1), eventually became faster (better noise margin), and also took up less chip space.

Converting this into a (simplified) layout:
I used gray for metal, black for contacts, red for poly, green for N diffusion, and white for P substrate. The blue lettering is an arbitrarily assigned net (electrically connected group) number which we'll use later as we convert this into a simulatable data file. I might use the term node and net interchangeably, they mean the same thing here. As a reminder, the distinction between source and drain is less important at a fundamental level. For our purposes we only care that the ends of the green blocks are the switch contacts and that the switch is controlled by the red part (polysilicon aka poly). Finally, assuming self aligned gates, the poly protects the silicon under the gate and so we only have diffusion around the poly and not under it. Early CMOS used metal gates but later switched to poly (not regular Si because you can't grow good crystals on an amorphous SiO2 glass surface).

Notice that we really try to avoid conventional resistors. While they can be made from strips of poly or diffusion, the easiest way is to make them out of transistors. I am not deeply familiar with this and initially had the drain and gate connected instead of the gate and source as above. So if you see images with them reversed its because I was too lazy to re-take screenshots after I fixed it. On my TODO list so that I can better recognize and understand them. The transistor below is more interesting and we'll mostly focus on it.

Pretty picture, but its also pretty lifeless. Time to start digging into the codebase. If you grab a copy of the visual6502 source code (either from my repo listed above or from the main repository at https://github.com/trebonian/visual6502) you should see chip-6800 subdirectory which defines the files you'll need to create for your own simulation:

nodenames.js: defines human friendly node names such as clk0
segdefs.js: defines how to draw the non-transistor parts and their connections
transdefs.js:transistor to net connections and transistor drawing
support.js: utilities and overrides to stub out unneeded functions
testprogram.js: CPU instructions. Since we won't have a CPU we don't need this file

nodenames.js contains the nodenames variable and looks something like:

var nodenames ={
gnd: 2,
vcc: 1,
clk0: 3,
}

vcc is net 1, gnd is net 2, and clk0 has been aliased to net 3.

segdefs.js contains the segdefs variable and looks something like:

var segdefs = [
[ 4,'-',5, 177,94, 193,95, 193,179, 178,180],
[ 1,'+',4, 128,214, 177,214, 177,265, 129,264],
[ 2,'-',3, 128,95, 179,94, 177,146, 128,146],
[ 4,'-',0, 66,163, 192,161, 193,179, 64,179],
]

Which probably looks pretty cryptic at first glance. The first element is the node number. The second is the pullup status: '+' for pullup and '-' (although I think any non-'+' value will work) for regular. That is a '+' indicates a resistor is connected to the positive supply and will turn on attached gates if not shorted out. Each pair thereafter forms part of the polygon used to draw the chip. All of the above are rough rectangles.

The next number is the layer number. This does not effect the simulation to my knowledge but we do want the visual aspect to work correctly. If you look in expertWires.js you should see:

var layernames = ['metal', 'switched diffusion', 'inputdiode', 'grounded diffusion', 'powered diffusion', 'polysilicon'];
var colors = ['rgba(128,128,192,0.4)','#FFFF00','#FF00FF','#4DFF4D',
'#FF4D4D','#801AC0','rgba(128,0,255,0.75)'];
var drawlayers = [true, true, true, true, true, true];

Which defines the layer numbers (0 indexed). Thus the sample data above defines the layers poly, powered diffusion, grounded diffusion, and metal. Switched diffusion is diffusion that will change state during simulation because its on a switched side of a transistor. In the sample image the two diffusion segments on the right are switched since they may or may not have a voltage potential on them depending on whether the transistor is on. The upper left diffusion is powered since it always has positive voltage and the lower left is grounded diffusion since its always at ground potential. Hopefully poly and metal are self explanatory.

We render in the order given, so make sure to place them in a good order. Make metal last as its semi-transparent and anything else will just cover it up. None of the other polygons (except transistors, but they aren't usually rendered) should overlap but if they do just arrange things as needed.

The final key file is transdefs.js which contains the transdefs variable:

var transdefs = [
['t1',4,2,3,[176,193,96,144],[415,415,11,5,4566],false],
['t2',1,1,3,[177,191,214,265],[415,415,11,5,4566],true],
]

The first element is the node name which is followed by the gate, first, and second net connections respectively. Like in the layout we don't distinguish between the gate and drain.

Now that we know what data we need we need to generate it. While I could learn to use or develop my own tools for converting layers to *.js files, I decided to go with the KISS strategy. I used the Kolourpaint toolchain to generate my *.js files:

I generated the points by hovering the mouse over the various coordinates and typing them into the *.js files. With both windows open at once it went pretty quick. If you're wondering why its upside-down, its because the simulator has the origin in the lower left hand corner and kolourpaint has it in the upper left hand corner. By flipping upside-down the coordinates come out correctly.

But its not over yet. I've glazed over utils.js but its actually necessary for this to work. The stock functions are more specialized for a full blown MCU, a 6502 in particular, and we will have to override these functions as appropriate. Finally, we need to set the canvase size by setting grChipSize which sets width and height. My images were 400 X 400 so I set grChipSize to 400. Lets step through initialization so that we know what we need to fixup.

We start in the main .html file by including a bunch of stuff. In particular you'll need to change the paths to reflect your files instead of the template's. For example, I used chip-6800 so had do substitute things like:

<s cript src="chip-6800/segdefs.js"></script>

for

<s cript src="chip-tutorial/inverter/segdefs.js"></script>

or whereever you put your files. Trusting the general structure and skipping over the HTML layout, the key item is

function handleOnload() {
...
setTimeout(setup,200);
...
}

Which launches setup() in expertWires.js after 200 milliseconds. The other key item in the main file is the play button:

<a href ="javascript:runChip()" id="start"><img class="navplay" src="images/play.png" title="run"></a>

which calls runChip(), but we won't worry about this for now.

This function is mostly just a bootstrap for the next stage. They do a lot of this and I'm not sure why they don't just make function calls.
EDIT: I've been told this is related to not letting scripts run too long and make the browser complain. By re-submitting the request the browser doesn't get so angry. They aren't sure if this is standard for web services but it seems to work.
Anyway, here it is:

function setup(){
statbox = document.getElementById('status');
setStatus('loading ...');
setTimeout(setup_part2, 0);
}

And this gives:

function setup_part2(){
frame = document.getElementById('frame');
statbox = document.getElementById('status');
setupNodes();
setupTransistors();
setupParams();
setupExpertMode();
detectOldBrowser();
setStatus('loading graphics...');
setTimeout(setup_part3, 0);
}

setupNodes() works on segdefs to setup the visual portion. For historical reasons (in a comment I read somewhere) it also contains the pullup status as noted earlier.

setupTransistors() does the actual transistor and net setup. One point of interest is that C1 will become "interesting" if C2 is but C1 isn't (ie GND and VCC will be moved to C2 if they weren't in transdefs.js). We also build a list of all of the transistors connected to each net. That way when we simulate an event we only have to reference the net instead of iterating through all of the other transistors looking for relevant gates by exchanging memory for CPU usage.

setupParams() parses query parameters (page.html?key=value) and so isn't important for basic usage. setupExpertMode() sets up the probe control panel and you don't really need to worry about it. Finally, detectOldBrowser() is compatibility related (makes rendering faster on certain systems?) and you also don't need to worry about it.

We now move onto setup_part3():

function setup_part3(){
if(chipLayoutIsVisible){
updateChipLayoutVisibility(true);
}
setStatus('resetting ' + chipname + '...');
setTimeout(setup_part4, 0);
}

The chip layout should be visible and so we start to render the layout and move onto part 4:

function setup_part4(){
setupTable();
setupNodeNameList();
logThese=signalSet(loglevel);
loadProgram();
setupConsole();
if(noSimulation){
stopChip();
running=undefined;
setStatus('Ready!');
} else {
initChip();
document.getElementById('stop').style.visibility = 'hidden';
go();
}
}

Glaze over things and go to initChip() which is important since you'll need to define it. initChip() is responsible for setting the startup logic state. Unfortunately the default implemetnation in macros.js has statements like setHigh('rdy') which are 6502 specific. I cut that stuff out to give a very basic chip initialization instead. See my support.js, but basically it sets all transistors to off and then recalculates all transistors (recalcNodeList(allNodes())).

recalcNodeList() is a core interface. Its a discrete event simulator where we propagate switch information when things change. Since there's no guarantee it will settle, it will abort after 100 iterations if we did something dumb like create a ring oscillator by accident.

setup_part4 finished by calling go(). This will start looping the simulation. Usually this is by hitting the play button in main, but I hard coded the running variable to true so that I didn't have to hit the button. Also worth noting that I added a step delay variable (go_timeout). It may make sense for larger chips to run at full throttle, but for this simple simulation I limited at 1 Hz. step() will look for the net clk0 and invert its state. It also does a few other things so I added the following stubs:

/*
Simple logic chip stubs
*/
/*
Print registers and such, we have none
Could use the input and output pins I guess if we really wanted to
Used extensivly in macros.js
*/
function chipStatus(){}
//Simple logic chips have no bus to read/write, skip over
//Executed as part of clocking (halfStep()) in macros.js
//Alternativly we could have just re-implemented these functions
function handleBusRead() {}
function handleBusWrite() {}
//Stub implementation in case not using memtable.js
//No memory to track
function setupTable() {}

Whew! We should be ready to run. Check my data files for how I defined the*.js files. Allright, lets see what we get:

?!? Upon a little investigation, we see that there is a 400 pixel gutter. Since our image is 400 pixels, if we set grChipSize to 1200, we will see it centered at the bottom:

But really we want it to look nicer and so take of the 400 pixel left gutter:

Alternativly we could have made the transistors big enough so that the gutter doesn't matter. I added the variable main_area_left_gutter and set it to 0. I'm not clear why they added a gutter to the left but not bottom. In any case, lets see some clocking action! (The above image was taken before I added the clock) Clock on:

Clock off:

And it works! As you can see, the powered and grounded diffusion stay the same and the active diffusion area changes along with the metal. Not too much work overall even if you don't much about web technology.

Thanks to the visual6502 folks for providing such great software and making my inverter be more correct instead of "just work"! My next steps will be to start cross referencing the *.js against the die images and also to generate *.js automatically from layer images. On a final note, I've also learned a relatively simple technique for preparing ICs for live analysis that I'll hopefully make a post in the near future about.

Studying the CD4001

2011-03-02T20:20:00.000-08:00

Somewhat arbitrarily I decided a CD4001 would be a good chip to really study to get a better feel for how a chip was put together. While I can recognize bits and pieces of larger chips, I still lack the fundamental understanding of how to recognize raw transistor arrangements. Although such basic logic chips have heavy optimizations which can be somewhat undesirable as a study tool, I'm hoping their simplicity makes up for it.

The original chip I was going to look at was a Fairchild CD4011:

I decapsulated it and found it had nice coloring:

Hopefully "POS" doesn't refer to their confidence in their design. This was only intended to be a preliminary quick photo before cleaning, but my metal tweezers slipped and sent it flying to who knows where. I now have plastic tweezers which tend to chip the dies less and less susceptible to slipping. Anyway, take a look at what I think is a National Semiconductor 4001 (was in a tank of 4001's):

In a similar area:

Maybe its just the "natural" arrangement for this sort of configuration? I'll figure out more as I etch out the transistors. Its interesting though that ones a CD4001 and the other is a CD4011.

Another item is interest is that older Texas Instruments datasheets had top metal included. Compare a datasheet with one of my snaps:

...and the (rough) stitch:

One interesting thing with the TI parts is that you can identify pin 1 with a bullet shaped pad. Other vendors have similar things and it seems the shapes tend to be unique per vendor. For example, it seems Motorola may use an octagon like pattern (all taken from what appear to be different revisions of the same 4001):

The first two are nearly identical. The last one has a full octagon where as the first two had a square corner.

I have some etching chemicals coming that will hopefully come by this weekend and I can use to expose some transistors. I have a roll of 100 Phillips 4011's (about $6 from Jameco):

which I'll practice on and then expose other chips that I have more limited capacities after I have some results. Since these chips are so simple, I can actually make guess as to what a lot of things do, but I would like the transistors as well to complete the picture. If successfull, I'd like to write up a tutorial that takes someone through decoding the chip.

On a random note, I get a lot of my chips by scrapping old electronics. I heat gun the board (wearing my 3M industrial respirator so as to not get too many fumes) and collect chips into a tray. Usually there are only a few I really care about, such as the main CPU or some FPGAs. There are lots of leftover small chips. Its not cost effective for me to use them in anything I design for a number of reasons. So, what to do with them? How about throw them in a beaker and decap in mass:

The larger chip is an i960 that I savagely ripped out of a computer that was being junked. As such, it got cracked in two spots. Setting up for mass photography:

They are on a microscope slide with sticky tape. I estimate I spent only about 1 min on each chip. Granted, this has limited usefulness, but it does show a number of interesting designs and I was never going to use the chips otherwise. For the curious, I uploaded a bunch of them to http://intruded.net:8080/uv/UVSG/

Scaling up image stitching

2011-02-17T23:21:00.000-08:00

In summary, find the Python program I wrote here (works, but work in progress), you'll need the entire repo though:
https://github.com/JohnDMcMaster/pr0ntools/tree/master/stitch

Now that image capture is getting reasonably automated, stitching is the next bottleneck for mass scale IC -> netlist conversion. The Visual6502 team is working at scaling up their image -> netlist conversion. I recently got in contact with them and am hoping to try to get more involved. In the meantime, I suppose I'm a turbo nerd and just even looking over the layouts.

Knowing that Visual6502 had the best images, I managed to convince Christian Sattler to give me his stitch code and get it under an open source license which I somewhat arbitrarily called csstitch. You can now find it here along with some of my patches. Unfortunatly, I quickly realized that the high quality imagery from the confocal microscope had simplified a lot of the stitching. For example, no photometric optimization was being done and it was based off of autopano-sift-c (SIFT based), which I've always gotten far inferior results compared to autopano.kolor.com (also SIFT based, which I call autopanoaj since that's the author's initials and autopano is too vague). From what I can tell, autopanoaj's secret may be that it has a very good outlier detection algorithm. If you turn it off, it produces many very poor control points (features). I've also been playing around with panomatic (SURF based). My general feel has been that the quality is less than autopano-sift-c, but I haven't had enough time yet to give it a fair trial.

Having this experience and getting some ideas from csstitch, I had dabbled at making my own higher performance stitching app. With the CNC producing very accurate XY coordinates, it seemed I could heavily optimize the control point finding process. Unfortunately, there turned out to be a bunch of gotchas along the way. Some of them are due to some oddities of the .pto format, some of them due to the fact that I run autopanoaj under WINE (yuck...) since I don't want to run Windows and the Linux version is out of date.

The first step is to arrange the images into a rectangle. Since the Python Image Library (PIL) and .pto like the origin at the upper left, this seemed the natural coordinate system. At first I tried lower left since that's what I was taught in math class, but quickly realized this was a bad idea and converted the code to use upper left hand coordinate system. I added a series of flip options so that as long as you started in some reasonable grid layout, you could flip it to the upper left hand corner convention. I also pre-process the images with something like "find '*.jpg' -exec convert -strip {} {} ';'" to get rid of accelerometer data and other stuff that I found over-smart programs used to mess things up. For example, gthumb will flip images based on this and made me arrange the images wrong. Anyway, start by getting them into some intuitive grid and then flip them as mentioned earlier:

And I had a picture demonstrating flips...but don't know where it is. In any case, these pictures are already in the correct order above, but are not named correctly for the column/row convention. I might allow parsing rows first to make the above arrangement possible. If you add a transpose, the image matrix is arranged correctly.

Next, it generates all of the adjacent image pairings (as a generator). The images are cut down to only stitch on a common overlap area. This cuts down processing time considerably, reduces false positives by limiting where matches can be placed. However, we've added some complexity with merging project files, discussed later. Image pairs look something like this:

A lot of the distortion you see I originally thought was due to camera-lens or other similar alignment. I eventually realized it had to do with the non-uniformity of my light source. It has a diffuser filter wheel which seems to have helped a lot. I also put it more off center which decreased intensity, but made the light more regular. In any case, it should be obvious from the above images that photometric optimization is a must for my images.

Next running autopanoaj under Linux required some magic. First, it doesn't behave well to a number of file related options, possible due to WINE imperfections. The only way for it to reliably work is to let it generate its own project file(s) by running it without any file options in the dir you have the images and want the project file(s) in. This requires post-processing to convert the WINE file paths to Linux file paths for the image names.

After that, projects are combined with pto_merge. While autopanoaj produced fairly lean projects, pto_merge seems to shove a bunch of junk in. This was creating some issues, so I decided to filter a lot of this out.

Finally, I do some post processing to get things closer to the final output. This includes changing the mapping to rectilinear and changing variables to only d (x) and e (y) optimization. Currently, stitching has to be finished in the GUI. This should be fixed if I can eliminate more control point gaps by image processing.

.pto documentation is surprisingly scarce among panotools. I don't know if I'm just not looking in the right place. I eventually realized that the suite that pto_merge is part of has some good documentation and was quite happy to find good documentation on the .pto format. Would be something good to add to the panotools wiki. I just requested mailing list membership and might bounce some of my ideas off of them.

One of the issues is that some of my images are of such poor quality that RANSAC / min result thresholding rejects the control points entirely. This is usually due to a blurry image. Example troublesome pair:

If I remove RANSAC, I can get it to generate a very poor match:

After a suggestion from someone, I played around with Kolourpaint image transforms and observed that softening the images (blurring sorta) causes the features to be uniform in both and can successfully generate accurate control points. Although the images look somewhat different, the control points are still in the same location on the original images. Example transformed images:

Wow! What an improvement. The new set was ran with RANSAC since it generated so much better data. I have yet to figureout how to implement an equivalent transform in Python, although I did some preliminary tests with ImageTransform.* and haven't tried very hard yet.

I've also been working on fully decoding a CD4011. Hopefully I'll have a write-up of that soon. In some ways, large CMOS designs are easier than small jobs because standard logic cells and other components have to be more regular for large designs to scale. That aside, the schematic is rather simple and other factors make the number of permutations fairly small. The main issue has actually been how to record the circuit nicely. My main choices so far seem to be the visual6502 Python GUI and Gimp. I've found GIMP not so user friendly, although I hear its not so bad once you get use to it. I'm not sure if any pictures of the layout editor have been published and I don't remember any restrictions not to publish them, so for those of you who have never seen the layer editor:

I now work for an aerospace company, Skybox Imaging where i'm now starting to learn about rad hard parts. Don't think I can get any from work, but if someone happened to have something, it might be fun to image and compare to other parts (maybe not be able to publish if ITAR issues though). Finally, someone suggested I submit something to kickstart, so I figured why not. Better toys, better research.

EDIT:
Kickstart rejected me, was worth a try. Looking back over tools, Degate is really what I should be using. I played with it a little and and if I really want simulatable results, I'll look into writing a plugin for it to export to visual6502 jsim format. Its too bad I lost the Fairchild CD4011 I had, it looked a lot more like textbook CMOS I had seen. I only got initial images from it and then lost it. Since then, I've gotten better (plastic now) tweezers that tend not to slip and launch things.

Metalurgical microscope CNC

2011-01-27T20:29:00.000-08:00

I now own what is possibly the worlds first combination CNC milling machine and metalurgical microscope.
I've realized among things, I just like looking at dies to admire the work put into them. Unfortunately, its a lot of work to take the many thousands of pictures required to get a good level of detail on even something like a 386. Plus, if you want the whole circuit, you need to repeat this for many layers.
Fortunately, I have some background in robotics and since I'm planning on getting a better microscope in the next few months, I don't feel bad being a little more aggressive with my current setup. A Unitron N, the model I have, is suppose to look something like this (image from http://microscopesonline.info/):
The z-axis gear got partially stripped at one point when I was trying to fit a shim as mine was missing. One thing in particular I hated though was the upside down sample mounting. I usually used post-its or similar to hold the dies to a drilled out petri dish. Which of course brings to the next annoyance that its also annoying to even get something mounted onto the stage at all.
Not too scared to be a little aggressive then at my half loved contraption, I got this after a few modifications:
See a crude video of it working here.
Some time ago I ditched the polaroid setup since I wasn't going to use that in any form. Next, I mounted the microscope upside down on some t-slot aluminium to make it much more convenient to view samples. Next, I wanted CNC control and I didn't really like the XYZ set-up anyway, so I replaced the XY with my Sherline 2000 CNC XY stage. Turns out, the CNC head can also still fit, but I didn't have it there during early testing.
The Z axis was a bit trickier. An earlier picture that shows the basic idea:
Also you can see I had to tape the eyepieces in so they wouldn't fall out. At first I tried to figure something out with my rotary table since it was the only other heavy duty CNC equipment I (thought I) had. I also had a Z stage for optical work, but the thumb screw was very hard to turn and adapting a servo would be difficult. The dimensions were also awkward to actuate it using the rotary table. I eventually realized I had a CNC micrometer from half of a UV-VIS spectrometer I found and scrapped at RPI. The brackets were close enough to easily adapter to the XY t-slot with an l-bracket. The sample tray base is a largish l-bracket which I've attached several different holders on to experiment. Ultimately I'll probably replace it was a kinematic mirror mount so I can correct tilt errors easily. An early test was to instead use a largish petri dish for the same purpose, but I found that Z axis movement tended to move things around too much. I should still try to couple it tighter to the main axis to reduce vibration, but it doesn't seem suitable enough unfortunately. Finally, the original set-up depended on gravity to remain stable. To compensate, I have it tightened with a rubber band:
The rubber band goes around the brass part which was suppose to be pressed against the shaft by the weight of the equipment mounted to it. As its been turned on its side, this is no longer true. At some point I might see if I can make some more proper spring loaded replacement.
One issue came up was that although you still can view through the eyepiece, its pretty awkward. With the camera over one and not wanting to re-adjust, it becomes difficult. So, I wanted to get the view onto a computer screen which is probably nicer on the eyes anyway. A 1/8" audio style jack breaks out composite where I convert it to an RCA type plug so it can go into my composite -> VGA converter box. The VGA then goes to an LCD display that was affixed to the t-slot. The second display behind the first, possibly not obvious in the above image, was arbitrarily fixed there to get a display up on a media server nearby and get the screen off of the floor.
The camera is mounted on t-slot aluminium as well. My Canon SD630 doesn't have a remove capture cord port and USB only supports PTP, so there is no built in way to do remote capture. So, I removed the top cover and soldered some wires onto the capture button. There are two spots: focus and snap. Shorting snap by itself is not enough to take a picture, focus must be depressed first. A DB25 breakout box runs to some optoisolators to short the signal. I figured out the correct polarity by using a volt meter on the leads coming from the camera button.
Electronics hardware is very simple. DB25 goes to a breakout board and then continues onto the stock Sherline driver box. I made a simple adapter to use the Vexta motor on the a axis with the Sherline box. The camera driver circuitry is very minimal:
The unused IC there is a CD4050 buffer I was going to use on the parallel port. I got lazy and didn't wire it up as the parallel port was already putting out near 5V.
Finally, there are several pieces to the software. At the core, I'm running EMC2. I set the step speeds and acceleration low so as to try to discourage the sample from vibrating. The camera is actuated from M7/M8 (coolant mist/flood) and then reset with M9 (coolant off). I use dwell instructions to give the camera enough time to take pictures, the necessary length of which I'm still working out.
The second part of the set-up is the software that generates the g-code. I wrote a Python program that you can find on my pr0ntools github repo. Its very crude currently, but may be sufficient. It assumes you are scanning a rectangle. One point is assumed to be the origin and the other is supplied on the command line. In order to make a plane, I assume the most level plane you could form from those. I'm currently always starting scans from one side on the theory it might make backlash issues less, but I'm not sure if it matters.
The test wafer I used looks like this:

An interesting piece in its own right, from what I can tell it came from an Intel Journey Inside the Computer educational kit. Of course, I didn't scan the entire wafer, but just one chip. While the plastic distorts the image, it does make a good test as its easy to level and rotate.
From a combination of my lenses are kinda dirty (probably can fix this or upgrade to modern optics, think it uses DIN components), not washing the wafer holder, and the plastic layer, the first pictures came out relatively nice. Why it may not produce quality images like the visual6502 team or Flylogic team does, it should serve to efficiently create a number of relatively high resolution shots to my hearts content. As I get a better microscope, I might also look into CNC retrofitting it, but more likely I'll focus on improving this one as better microscopes are current beyond my budget as a high risk project.

Berlin and CCC/Berlinsides

2010-12-29T00:33:00.000-08:00

Just wanted to say I'll be in Berlin for a few days if anybody wants to say hi.
Lab is moving and I'm on the move, but I should also finally get settled and $$$ flowing in in the next few months, stand by for cool stuff.

Sulphuric acid decapsulation

2010-11-30T09:46:00.000-08:00

Something I've been meaning to try for some time. Somewhat arbitrarily I decided to go analog, the victims were a 741 op amp and a 555 timer. The torture:
The victim (I snapped the pins off since they are easy to remove and had more of an impact of nitric reactions):
Initial setup:
I didn't take a picture of this, but the solution started to turn brown and diffuse out around the IC before too long. Began to turn darker:
And eventually black:
The acid behaved differently in the 555 flask (misty, no creeping along sides in 555 vs creeping and no mist):
After draining and some initial acetone rinse:
The die is seen in the leftmost object. I've been told that sulphuric is useful for live decapsulation and it certainly shows here. Much of the "wiring" was preserved despite prolonged exposure to acid. Nitric on the other hand would have obliterated these. Not as visible, but also all of the bond wires were preserved.
Since they were both analog ICs made by ST, it less likely that they were different epoxies. Both used fresh acid. Probably due to some contamination in the flasks.
I'll try to update with some IC pictures. Nitric tends to leave a lot of residue. This on the other hand had overall clean dies, although one of them had sort of a grainy appearance, maybe from certain residues? Apparently the 555 didn't have a passivation layer and the 741 did which resulted in scratches on the 555 after I was careless during plucking and didn't realize it wasn't protected.

In summary, this is what I thought
Advantages
-Less fumes than nitric acid, MIGHT be safer with less equipment / ventilation. With the cover on my glassware and the top being somewhat cold from the environmental temperature, it seemed to reflux the acid and I didn't even really notice the fumes. Contrast with nitric where fumes are an inherent problem from the nitrate decomposition.
-Inexpensive
-Readily availible materials? Battery acid and drain cleaner are readily availible. Battery acid tends to be purer and would likely need to be distilled first, but drain cleaner (ex: Bull Dozer) is much stronger but with contaminants. In any case, generally not a controlled substance and one should be able to order it without too much trouble.
Disadvantages
-Higher working temperature. Might literally take your hand fall off if you spilled on it. When I was younger a single drop of cold concentrated sulphuric landed on my hand and caused a severe burn to which I'm reminded to this day by a scar. I can't imagine what a broken boiling beaker could do.
-From the solution turning black and the lack of bubbles, no clear indication of when its "done." Combined with the larger cool down time of the acid and glassware, this can make it inefficient for doing small batches.
Overall, probably a good compromise for those that want to try some of this stuff
-Grainy appearance on dies? Need to look more into what that came from

With this in mind, one good application might be to use it as a wash after nitric. Since I've found issues with particulate residues after nitric, a brief sulphuric bath might be able to clear them off. I think sulphuric works at lower (ie room) temperatures, albeit much slower, so it might not even require heating. I'll probably try to soak a fully encapsulated IC overnight and see how it goes as a starter.

Back to Troy, NY

2010-11-08T21:49:00.000-08:00

After spending the summer in Cambridge, MA and back to SF Bay area for a few weeks, I've been back to Troy, NY. What makes Troy special? I'll tell you...

Luxurious homes

Expensive cars

Booming industry

And fine art

Okay, so its not quite as bad as I make it look, but most of these were taken pretty close to my apartment. To be fair, they've been knocking down a lot of the old buildings and graffiti is pretty rare except when this construction wall went up at RPI and people went nuts. I'll omit those pictures as if the first pictures don't get me hate mail, I get the feeling RPI might give me a "strong suggestion" to take down the latter.
Now that the small talk is out of the way, on to business. Although I haven't been posting anything, a lot has been happening. First, the microscope I previously mentioned never came, but eBay refunded me. However, my room-mate bought a metallurgical microscope with USB camera, so I'm better off than ever. Being off campus now, I also have less restrictions and don't have to deal with RA BS and such. One perk of my apartment is that I got some lab space in an area that's being remodelled. Its going to go away in January, but I'm hopefully moving out then anyway, so that shouldn't really effect me. The end effect of this is that I'm finally getting a chance to do all of the stuff I wanted to before and actually have some time and space to try things out.
I've imaged a bunch more IC pictures. In particular, I have images of discrete transistors, fully delayered 7404 hex-inverter, and other ICs.

3906 top metal
Old TMS320 logo section

On that note, a die image archive was started at http://intruded.net:8080/wiki/ Since I like Wiki's, I got myself an account and you should expect to see any die images I publicly release to appear there. I posted a few from a bit back, but haven't gone on a rampage yet. One of the things they are working on is getting a "Google Maps" style IC viewer for larger ICs. A crude test page is at http://intruded.net:8080/map/ (you'll have to zoom to correct level).

Map view test for large ICs

Regarding http://siliconpr0n.wikispaces.com/, I recently got permission from Sergei P. Skorobogatov to include images from his Semi Invasive Attacks paper on the Wiki as long as they are credited to him. So, along with the other material I've been accumulating from my own research, expect some rapid expansion on the Wiki in the near future.
After delayering a few 7400 series ICs, I've realized I had in fact been at the transistor layer before, but just didn't understand what I was looking at. Probably bad been confused by all of the MOS pictures I had seen? In any case, I tried a 74163, but found it was too complex to start with. I could only recognize a handful of components. A few days ago I delayered a 7404 which should provide a much cleaner reference circuit since its small and more or less split into 6 regular units. Unfortunately, I let it sit for a while without agitating it, so it crystallized a bit, but should be fine for my purposes.

7404 transistors

A quick overview of the techniques I currently use and why. Most ICs are in epoxy. I boil them in 70% nitric until the epoxy is removed. Lacking an ultrsonic cleaner, I wash them in room temp 3% HF for about a minute to clean the surface. This takes a thin layer off the top, which removes most debris. Then, depending on how patient I'm feeling, either room temperature or near boiling 3% HF to delayer the IC. If I want to keep it suitable for live analysis (mostly my roommate has been doing this), a Dremel "drill press" with a small endmill is used to make a cavity above the die. We use a rough estimate, usually slightly above the pins, to guess how far to go down. The package is pre-heated to 300F and a drop is put on top, allowed to etch, and washed with acetone before it dries out. Heating the acid doesn't seem to make a difference as its heat is negligible (plus transfer cool off) compared to many IC packages. I also played around briefly with another low cost method that is more automatic but less selective, I'll try to post something on that soon.
Finally, I'm interviewing with various companies and looking for a job, so if you think you might be interested in me, feel free to send me an e-mail at JohnDMcMaster gmail.com.

End of summer plans

2010-07-25T09:57:00.000-07:00

As my summer internship comes to a close, I was never able to get access to microscopes over here. If i had bugged a large number of people I might have, but there was so much else to do in Boston that its just as well.
That doesn't mean that I haven't been preparing though. For starts, I've accumulated a small hoard of Intel CPUs that I will hope in the near future to image. The microscope I bought a bit back wasn't as good as I thought it was, although it should still be fine for short term work coming up. I'm very grateful to be able to borrow the microscope at RPI, but for a number of reasons it is good to get my own. After searching around for a large portion of the summer, a decent quality Olympus microscope showed up on eBay finally:
What made this affordable? Two things. First, it was a first time eBay seller. Second, it coming from Thailand. So there's a bit of risk involved. Usually people don't scam on scientific items and if they do I can probably do a chargeback or possibly even a PayPal dispute. I'm not sure on their policies with other countries. If you scream loud enough, someone will usually do something if bad things happen.
The other part is I looked briefly into what it would take for me to order RFNA. From the companies I saw, they required you to be associated with a business. I'm not sure if I could play any tricks with my school, but from the business standpoint it would be very expensive. Yearly business registration fees seem to be pretty high in CA (something like $800 a year if I recall) which is not justified for this project.
Next, I've aquired some ground glass glassware, which has been on my TODO list since early high school. If I need to produce any chemicals for analysis now, it should be considerably easier and of higher quality.
I fly home for CA in two weeks. While there, my plan is to image a number of 7400 series logic chips to form a practical foundation. This should also be useful for others to study from. I could have bought some from Digikey etc, but I am thinking they probably use newer process technologies that would be harder to analyse. So, I heat gunned some off of old circuit boards and will be using those. Assuming those three weeks go well and my microscope arrives at RPI, as permitting during the school year I will start imaging the Intel chips.
Finally, I may be involved playing a small part in a commercial project coming up. While I will not be able to disclose the details of it, part of it would include them buying all of the acid and such I need to decap the chips, giving me an idea of how using commercial grade equipment contrasts. My role will be focused on the decapsulating and possibly aiding in the analysis.

Biological, inverted microscope layer image comparison

2010-05-15T22:06:00.000-07:00

Biological, top metal (220X):
Biological interconnect doesn't image well as all black. Sample for comparison (not same area):
If you are stuck with a biological microscope, set the intensity as high as you can and you should be able to make things out with your eye, but cameras might have more difficulty.
Inverted metallurgical (inverted), top metal (440X):
Inverted metallurgical (inverted), interconnect (440X):
Although all three are from the same chip type, only the two inverted images are from the exact same chip. NOTE: I have done a vertical flip on the inverted images to correct them to what the actual object is like (as in the biological image).
For those wondering where the magnification levels come from, it is a combination of the eyepiece, objective, and camera magnification. For the biological microscope, the image was shot at 10X eyepiece * 10X objective * 2.2X camera = 220X. For the inverted metallurgical microscope, the images were shot at 10X eyepiece * 20X objective * 2.2X camera = 440X. Thus, I (poorly) manually stitched two images together from each to get closer to the size of the biological image.
Alas, despite my best efforts, I still can't see transistors. Today I tried some extended hot baths in HF acid on the chip above and even tried adding some 30% H202 which dramatically increases the action of the HF. I'm letting it sit overnight (or maybe till Wed after finals) and see if it ate through. Maybe these chips are just resistant? I'll have to go back to sanding though to get other sample since I haven't gotten another technique to work yet on epoxied ICs.

Image stitching

2010-05-13T20:44:00.000-07:00

One of the challenges of using computer analysis is that it is highly desirable to assemble a full image of the chip, but only a small section of the chip can be imaged at a time.
For the DRAM example chip that's been used throughout several of these posts (its because they are easy to decap and I have a lot of them), I started by manually pushing the chip around since I didn't have linear stages and taking pictures, trying to get 1/3 or so overlap on each side. However, these initial sets resulted in far inferior results compared to those made by using linear stages. That said, I need to make a comparison where I manually paste the images together. In any case, I first tried to use Hugin to manually stitch the images together. Unfortunately, while Hugin works very well for standard images, it seems to have issues with the vectorized patterns typical of ICs. I was only able to paste two well formed pictures together after setting 15 or so control points:
Thinking that I could do better, I looked into how to automate this process better. I cam across some information on the SIFT algorithm. Unfortunatly, while the SIFT algoirthm is patented by University of British Columbia, there are still some free implementations of it. The first I evaulated with autopano and later, after a reccomendation, was autostitch. Using the screwdriver pushed around die (as opposed to linear stage), with autopano, I go this:
However, I can't find a result using the linear stage version. I need ot rerun on that to confirm that autopano can't do better.
Next I tried autostich. After some help from my friend on the linear stage set, I go this:
My friend that reccomended it to me is a bit better at using it though, and was able to get a much nicer image seen here (warning: 16MB). Scaled down local version:
His version is slightly more linear. My original image was quite distorted before he gave me the setting advice. In order to get good images with autostich, adjust quality settings to 100% (otherwise it will shrink it), set to linear, and adjust theta value low.

Inverted metallurgical microscope

2010-05-13T19:48:00.000-07:00

A few weeks ago, Tom Ditto was kind enough to lend me this:
A sample image:
It has a number of differences over a standard biological microscope.
First, its primary advantage is that it does not require light to shine through the sample. Instead, light is injected directly into the view path, allowing easy view of opaque objects. I get around this with the biological microscope by shining intense lights to the side of the sample. I'm currently using a small 650W cone shaped halogen on a rheostat. Before I was using a 500W with a roll cage. I don't push it anywhere near full power. I had to make a shield to only allow in the needed amount of light and not toast the microscope with the intense heat it puts off.
Second, it inverts the image. As an example, here is an image of of an Intel 80486 ("486") copyright on the die:
Note it is flipped. After cropping and inverting, a much nicer image is produced:
Those black spots are dirt on the lenses. I've cleaned a lot off, but some of the larger spots are still present. In order to use this analytically, I will obviously have to fully clean it so spots of dirt don't appear where some critical interconnect image should be.
Various filters are available. I haven't played much with these though. I think the options include regular, polarized, and green. Here is a regular image, showing interconnect layers on some DRAM:
With the green filter:
Finally, although many do, for some reason the biological microscope I have doesn't have a movable stage on it. Maybe you were expected to push a slide around with your fingers? On the other hand, this one has an XY knobs for smooth, precise movement of the stage.
For future work, first on the TODO list is a proper camera mount. I'm using a clip on type mount that Tom let me borrow, but, unfortunately, its not stable enough for good images. This should fix alignment issues resulting in fuzzy, darker colors at the bottom and will allow me to zoom in, removing the dark circle. Next, I'm working on fitting some timing pulley's to the XY knobs for CNC control. I have all of the parts assembled for that and could probably due the fit in several hours. However, I need a larger peice of particle board to mount it on. Unfortunatly, I probably won't get back to this until August when I'm done working for the summer. With luck, I'll find someplace to continue work with it at MIT over the summer. Extra lab space anyone?

Why I'm not to the transistor layer yet, initial NaOH etch results

2010-05-13T17:40:00.000-07:00

Several factors behind this. First, I'm approaching finals and haven't had a lot of time to delve into the deeper layers. Second, I haven't had much success in the few tries I've done to get below the metal layer. Although I should try this more, the initial sanding I tried with a dremel was too course. It had a tendency to produce a relativly uneven surface and take too much off. The HF would take off the top metal layer, but nothing else. I talked to Travis Goodspeed last night and he pointed out I should be (near) boiling the HF. Yum. Tried today briefly and I think I have some progress. However, I really need to take some pictures as I go to get a better idea of exactly what is being corroded.
I had also tried with some NaOH on a P3 die since I heard that is also corrosive to glass. I ordered some KOH which I read somewhere is preferred more in the semi industry, but it got sent to my home in CA by accident, so maybe I'll play with that in a few weeks. First, this is your typical P3 slot 1 die after being tin snip cut from the BGA carrier:
This is actually a metalic blue, but apperas more black in the image. There is a gray epoxy holding it in place and a brown carrier around that. After inspecting the blue area under the microscope, I realized its just a coating to make heat dissipation better and not actually part of the silicon. In fact, you can see crystals poking through it (100X biological microscope):
Unfortunatly, it was somewhat difficult to get a good picture of them, but you get the idea. Thinking this, being a large chunk of silicon, was a good canidate for NaOH etching, I boiled it in some NaOH for a bit. Result (note this is not the exact same chip as above):
Hmm...what are those cracks? I think its stress from using the tin snips. If I was doing this for an imaging sample, I should probably dremel or carefully hacksaw cut them out. In any case, you can see the silicon crystalline surface much better (100X biological microscope):
in this picture, one of the cracks is also visible. I'm actually not sure how much the NaOH etched the surface since I didn't realize the blue wasn't silicon and wasn't really paying attention to see otherwise. I'll try the other side of thise or some other dies I have laying around in the near future.
Also on the not going so well side, this is how my first attempt at a rosin decap ended:
After ordering some borosilicate test tubes, I tried with a heat gun instead since I could control it with a variac and gave more regular results. After a few hours of boiling, a small nick came out of the underside of the chip along the die area, but not corroded as I was hoping. However, a large portion of this time was also devoted to boiling off the petrollium jelly after which the solution darkened and roes in temperature. The CCC IC RE Wiki page (written by Martin Schobert I think) shows the rosin doing more of a higher temp boil. I was at a lower boil. So, I might try to get a propane torch or a more proper alcohol lamp and try that. I'll have a few weeks soon to mess around at home and can probably figure something out. Also, this killed the TCO in the heat gun after I was done.

Paypal payload

2010-04-20T18:08:00.001-07:00

There have been several advancements including work on finishing the automation of the biological microscope and automation of the inverted metelergical microscope, but school has kept me busy and I haven't had time to finish those. In the meantime, here is a small deviation on taking apart a security key to get to the IC. In such situations, there is a double decap. We not only have to decap the IC pacakge, but its a bit of an effort to even get to it.
At DEF CON 17, there was a side event of sorts called BSides/Neighborcon (thanks Travis!). This actually had my favorite talk of the entire trip by HD Moore on WarVOX. In any case, PayPal handed out stacks of the PayPal (or someone anyway, I think it was them) Security Key.

From some articles such as this it is based off of RSA’s Securid. I'm not a crypto guy, but I figure if I take some images of this and work out some of the logic, someone else more experienced in the field who can't do this type of hardware analysis might be able to build off of this work. I won't be be imaging the chip until I can get some more experience since future cards will cost me $5 a pop. Plus, I haven't made any agreements at this point not to tear it to shreds. I originally had a lot, but I gave them away to a number of people who thought they were cool.
One cool feature of these things its display Basically, it will retain the image on it even with power gone. It is the same (class?) of technology used in the more famous Amazon Kindle.
From what I hear, GM week at RPI use to be about getting wasted and they use to bring large amounts of beer for students to drink. But they don't do that anymore. I don't drink, but it would have been hillarious to watch. On the surface, its about elections...w/e. I still have my mug from last year which is better and I needed some glassware to dissolve the card in. To top it off, it had a Vegas theme, which seemed appropriete to make the card go full circle.
In any case, lets get started with the teardown. After a few minutes in acetone, the outter cover is starting to shed:
A side view showing the ridges a bit better:
I think peeled this off to speed things up and soaked it a bit more:
The other half is starting to break apart a bit:
A little dissolving later, I can peel off the outside plastic to reveal the circuit board:
Closeup of the label section:
There are very small surface mount components on the board. The label says "InCardIC006AV11". There's also a number 2, whatever that is for. My guess is that five dot gold pattern is for programming and/or testing. That black dot should be the IC, which is what I'm primarily after. Unfortunately, it has no external labeling of any kind. Finally, the last component is what appears to be a lithium polymer battery based on its shape. Voltage reading:
Amazingly, the card still works! (the battery was removed later, still had battery here)

The acetone was getting a bit dirty. Time to clean it up a little:
After soaking for the last time, I wasn't able to get much else to come off even after soaking for a while. I had been hoping the board was going to dissolve at least slightly and release the IC package. Final front board image:
The battery came off with minimal force. Final back image:
The black IC package was then forcably removed and stored into a vial for later analysis. As I get better suited to dissolve the resin, I'll dissolve it and take at least a top metal layer picture. In the meantime, I'll keep practicing on expendable chips so scarcer chips like this can be properly analyzed.
To top things off, what kind of person would I be if I let flammables go to waste?

IC decapping round 4: burnt perfection

2010-04-15T19:16:00.001-07:00

As you can hopefully see from some of the previous posts, people employ many techniques to remove the irritating resin casing. I've seen suggestions of simply burning away the casing, which I was somewhat skeptical of, thinking this would annihilate the chip. However, I am open to ideas, and thought I'd give it a spin.
First off, burning is probably a bad word. The image I had in my head of how this would work was the physically heat the chip until the resin was utterly destroyed, like burning away a piece of wood. It turns out its not hard to make the resin brittle through heating. Or in other words, all one has to do is apply a short burst of intense heat and you can crumble the casing away with minimal chip damage. A picture is worth a thousand words, lets see an example. This was the result of the first chip I tried:
It came out amazingly clean like this in under a minute. Microscope inspection seems to indicate the die is healthy. More on this later. Starting from the beginning, here is a virgin chip:
A CP82C59A interrupt controller. All torch images are of one of these, but not necesarily the exact same unit. A tube of them was being kicked around in the RPI Electronics Club junk drawer. Torch meat now:
You shouldn't heat the chip too strongly. If you get this, you've gone too far:
I actually would have never guessed you could get a red hot IC package. In any case, as will be seen in the video, the most important thing is even heating. I'm not sure what the shock temperature is, but there was a certain cutoff line where the chip was extremely brittle vs very hard. In the video I don't heat the lower half of the chip good enough and it only breaks moderately well.
After removing the torch, it will burn like a well down marshmallow for a few seconds:
It should go out by itself fairly quick, but I was waving or blowing it out. Result:
Breaking now:
This final image is the die from the video. The one from the sequence above is the one on top shown here (contrasted with the very first one I flame decapped):
The heat managed to separate the die and the carrier! So that's what happens when you apply too much heat. I wasn't paying attention at the time and I'm not sure what happened to the die. I figured it had been melted in some weird way where as it probably fell to the floor when I cracked the casing open. The first one I tried (bottom die above) couldn't have gone any better. The case split perfectly and no resin was left covering the die.
Seeing how well the die withstood the heat, I wondered how far can we go? So I torched a die red hot. Although it was not as clear under the microscope as before, it still was of decent quality. I'll try to add a pic in a bit comparing an area of the first die extracted with the one that I tortured.
Here is a short video showing an heat based extraction:

In this test setup, that blue thing is a filter system to help reduce fumes. I also have a gas mask handy for exactly this sort of work. It really does help a lot. The resin was really brittle and very little force was required to break it. However, I didn't heat it enough towards the bottom, so one side of the die was still relatively well set into the case. This can be easily fixed though and is partly due to me trying to get this on film and not doing for an ideal setup.
For some future work, I may have gotten away with this due to the relatively large traces the 2 um test die I used had. Thinner traces may be much more sensitive. Still, the results are much more promising than I was expecting. As I move down the semiconductor technology roadmap, I'll revisit this and see how well it does against finer masks.
Thanks to Will Carder for lending me the torch!

PLACE SANDWICH HERE: the camera

2010-04-11T18:04:00.000-07:00

The original camera setup involved zip-tying t-slot aluminum to the microscope neck and positioning the camera based on a series of adjustments to the slot angles. There were a few issues with this setup. First, I didn't have any t-slot nuts, so it was always a pain to tighten things. I at first didn't have any t-slot L brackets either, but I had some nearly equivalent aluminum brackets, so that wasn't as big of a deal. Next, the small distances between the neck and the eyepiece really limited the flexibility in positioning the camera. It was very hard to position it accurately. Finally, the zip ties were only moderately stable, so if you hit it too hard, it would shift around.
The second setup I tried was to use a neck lamp as a flexible mount. It was abandoned because the camera was so much heavier than the light bulb that it caused it to sag. I took an old style fuse and ran a 1/4" bolt through it so it could mount to a camera. The camera isn't mounted to it here, but here I am disassembling it since I'm not going to use it anymore and bad things would happen if someone plugged in the lamp by mistake:

As the current setup is being upgraded for CNC control, the camera positioning will still remain manual since it doesn't need to be moved as the die is being scanned. Here is an overview of it:
Basically, this has two easy to position axis, which really help. The microscope eyepeice is on an angular axis and there is a linear slide that the camera is mounted on. Usually only minimal adjustment is needed with the t-slots, mostly for height. The slide was spring loaded to keep accurate positioning. When viewing the image manually, the eyepeice is swung around to the front of hte microscope where the neck is rather than at a 90 degree offset to standard orientation. This makes switching between manual and camera based viewing convenient.
Interesting to see the focal length as it relates to magnification. Here is 10X objective:

And here is 40X objective:

It looks like its touching, but its not. However, its very, very close. You can still get it out of focus by moving it closer. If you move it too close, the spring loaded objective lenses will move up rather than break. Here is what you see on the camera at 400X (more like 800X actually since we are zoomed in on the camera itself):
There is also a 100X objective, but I haven't looked into what it would take to use it. I believe I need to do something with immersion oil.
The original setup used an incandescent light. However, it only provided moderately acceptable light levels with the 40X objective. I recently bought a 500W halogen light that has really helped. However, its not very directional, so I installed a sandwich wrapper as a deflector to increase directionality to the sample and not blind the operator. As my friend Alex finished his lunch, he probably never thought about his burger wrapper again until he reads this. Little did he know it would become a critical ingredient in the camera setup after being banished to the gray cylinder labeled "TRASH."
Although it is festive, I'll probably replace it with some aluminum foil when I get a chance to go to the store or something.
This setup is pretty stable and I'm a lot happier with it over the previous one. It seems like a flexible mount would have been nice, but with the stability I've gained from the T-slot, this setup is probably best.
Thanks to Dane Kouttron (http://transistor-man.com/Index.html) for the pictures! Also thanks to Magesh Alagiriraj for lending me an SD card since mine died :(

Stepping things up

2010-04-11T15:23:00.001-07:00

One of the goals for an effective setup is to automate taking pictures of the dies. Current technique is to manually move the chip around while snapping pictures. As the chips get large, technology shrinks, etc, it becomes increasingly desirable to get more precise and automated control. The plan: use EMC2 controlling some linear stages and gphoto2 controlling a Canon SD100 to scan across a die to be assembled by Hugin.
The control system doesn't necessarily have to be EMC2. In fact, I've heard people have difficulty using it outside of the GUI. So, I might just use raw outp() calls to pulse a parallel port as needed to control the stepper drivers. I have some old Precision Motion Control drivers that can just barely be seen to the right in this image. The motors I'm using are fairly small, but the drivers are current limited, so it might work out. Otherwise, I'll make up a transistor based driver which shouldn't take too long. On the same note, I might end up using that stage setup if I want to scan some larger images later under high precision. I have a few other things I need to get detailed images of that are much larger.
The original plan to control the stepper motors was to couple them with springs to the stages. Something like this:
However, in early testing before even mounting things, I realized that they would build up enough force to overcome the static friction, but the stored energy in the spring would cause a large movement. Higher spring constants would only lead to the stiffness problems I was trying to avoid in the first place, so this solution was a no go.
Here is the current attempt at linear motion control:

It uses two stepper motors with longish gears to overcome issues from the micrometer moving in and out as turned. The Y axis (one on right) will be slightly trickier as the gear will move back and forth as the X axis is actuated. To overcome this, I'm going to try to put a spring force on it. With the small distances being moved, it shouldn't move enough to become a problem.
My luck with libgphoto2 has been mixed so far. It tends to get into internal error states fairly easily. Also, I've had difficulty building it to get the latest version. I tried to use a VM which could get a better version, but still same issues. In particular, I need to disable the flash, but this results in internal errors. Since I really need this, I'll probably put in the effort to get the newest version working and/or get in contact with the libgphoto2 team to help develop a patch to fix w/e the error is. This is an issue because it severely lowers the exposure time, resulting in bad pictures despite my relatively bright levels of light. I got this camera because gphoto claimed very good support for it and they were available on eBay at quite a reasonable price ($15 + S/H for used units, maybe $40 + S/H for newish units). I bought a SD110 originally, but it turned out to be much worse condition than the seller claimed, but since it was so inexpensive I didn't find it worth the effort to pursue. I found a SD100 buy it now for $15 without charger and get a good condition one for around $40. So all in all, I have a SD110 for parts and two SD100s. This has been quite good as the major complaint of the units is their relatively short battery life. With a spare battery or two, I can let one charge while I use the unit, which leads to good usage. The batteries tend to charge faster than then are drained.
My experience with Hugin has also been mixed. Under Linux, when I try to stitch together pictures, it crashes. I tried to use it under Windows to stitch together some of my dies, but they ended up coming out more like pretzels than beautiful images. In theory, use of the stages will make this process much easier as the images should be able to be precision aligned to each other.
Thanks to Robert Reeve for helping me with the design of this stage setup and for fitting the gears on the ends of the micrometers! Also, thanks to Jim Schatz for letting me borrow the microscope!

IC decapping, round 3: chemical etch

2010-04-11T14:56:00.001-07:00

In my last post, I discussed some of my early experience with sanding. After sanding, I tried some simple chemical etching. Unfortunately, my memory card died and I lost some cool stuff such as a microscope etch video, but I will hopefully be able to get some new, better images and videos later.
In any case, there were two areas to try: etching the case and etching the die. Etching the resin case is usually done with nitric acid. Travis Goodspeed has a good blog post about doing this at room temp here. I was able to get 70% nitric considerably easier than RFNA, so I decided I'd try that first. If you use non fuming nitric acid (but still required to be high conc I think), you must strongly heat the mixture. But, I did try a few other things first to see if there were alternatives. The first thing I tried was just to let it set overnight. This ate away the metal leads pretty quickly, but not the resin. The next thing I tried was to adding HCl to form aqua regia, hoping such a strong mixture would eat it away. Alas, this did not help either. Out of simple ideas, I then moved on to heat it to 80C using a hotplate. Unfortunatly, I didn't have a fume hood availible (someone is workong on getting me access to one), so I could only do it for a short time before having to cut if off due to fumes. I did not see signigant chip etching on the time I was working.
However, since I had other ways to get to the die, I figured I'd still try chemically etching the die. Using one of my cermic packaged dies, I was able to easily place HF into the die cavity so I could watch it etch under the miscrope. Defintly want to get another video of this. I was able to get a clean etch of what seems to be the top layer off and reveal the intermediate connection layer with vias. If I let it sit for longer, I imagine I could easily eat layer by layer. The top layer was taken off quite quickly even at the low concentration of acid.
I later tried to see if HCl would etch the chip. I saw initial high activity followed by not little activity. I then tried to put fresh HF on the chip and saw no reaction. I'm wondering if a protective SiCl4 or w/e coating formed on the surface, making the chip highly reistant to further chemical attack by a dilute acid. If the concentration was stronger it may have been able to dissolve this coating if thats what had happened. I ran out of decapped chips and couldn't easily decap another one at the time, so I'll go back to heat gunning some caps off. I have a stash of centrifuging tubes that I've realized work well for clean storage of dies.
I need to work on getting better storage for my HF acid. I've ordered a set of plastic test tubes with rubber stoppers for stage. Ideally I wanted screw cap, but couldn't find them at a quick look and stopopers is probably just as good. I had two different types of glass test tubes I stored it in intermitantly and one was corroded by it and the other wasn't. I'm not sure if this is simply because it had been used up by the time it got to the second test tube. In any case, it couldn't etch the IC after this, so I assume it was just that it got rapidly used up.

IC decapping, round 2: sanding

2010-04-11T10:55:00.001-07:00

The earliest way to view chips was to "cheat" and use old chips that were more readily accessible by soldering their physical caps. However, modern chips generally don't do this. The ones that do do similar things include chips like Xilinx Virtex or Intel x86 chips that run very hot. These can probably be decapped simply by throwing into some moderate acid to eat away the metal.
There seem to be three major techniques for decapping, but only two are used in the hobbyist space. From what I can tell, professional shops use plasma etch machines (http://www.stockly.com/forums/archive/index.php?t-16.html). These are slow, but accurate, and the machines can be had for only a few thousand dollars for a small one. I've even seen presumably working industrial sized ones for under a thousand on eBay. While a few thousand dollars is nothing to the core of a busines, its a bit much for a hobbyist.
The first technique I was introduce to was from Karsten Nohl's talk at the 25thCCC (http://events.ccc.de/congress/2008/Fahrplan/events/2896.en.html). He advocates the use of sanding techniques. Since I didn't need a particular chip to start with, I started with a wide DIP I could mount in a ZIF socket.

This is after I just started doing a thin amount of Dremeling. I then used a Dremel to go down until I could see the wire bonding arcs. Wikipedia has a good picture to help visualize this (http://en.wikipedia.org/wiki/File:DIP_Cross-section.svg):
On some chips I could see this with naked eye, but usually had to be made wet with something first. It was easiest to just use a 10X lens to do periodic inspection when you think you are about there. In practice, this might look something like this:
You can't see the wires very well in this one, but just note how we are almost at the leads. Here is a (slightly) better picture with some zoom:
They are barely noticeable as gold dots. Much more visible if you put some fluid on there. Basically, I could see them easily by getting it wet or by inspection under a 10X lens.
The rest will need to be carefully sanded and polished. After a brief bit of sanding, the bonding wires become much more visible:
Some sanding later...

We can now begin to see the die. I didn't sand it very evenly as you can see one corner much sooner than the rest of the die. This takes a bit of practice to learn how to sand evenly. Basically though, once you begin to see this, tilt your peice slighly so as to try to get the other parts to catch up.
I decided this uneveness was probably just as well anyway since it would give me a gradient slice of the die. After sanding away until we have a good gradient:
You can see resin still in the upper right hand corner. It turns out you can see through this more than you might expect:
The top section still has some resin and the bottom section doesn't It gets a bit fuzzy, but not too much more so, even on the deeper sections. Here we can see some damage from the sanding:

Two types of damage occur: planar depth going too low and particulates causing die scratches. Both need to absolutely be avoided for a decent die image. In any case, after polishing up one of the better sections a bit with some mystery paste substance:

Although we have a lot of damage, we are getting a smoother image. Future work will be around getting better images. A key factor will probably be higher quality polishing pastes instead of the mystery brand dried out paste I tried to use. In any case, I still can't see multiple layers and even sanded down very finly until I saw raw silicon.
And to top it off, I sanded it down really far just to get a feel for it.

Basically, you'll notice some cement used to hold the die in place under the silicon and how the leads go through the package. I'm curious what those two extra leads are for...someone suggested to me something related to power.
Well, that was what came out of round 2. Since I did this, I bought some more polishing compounds including a bottle of actual Dremel brand.
In conclusion, sanding seems like a viable option to get to the die, but I've had some bad luck actually getting multiple layers out of it. As you will find out in later posts, I had decent results with chemical etch of the die, but bad resulsts with chemical etch of the resin. Here, I had good resulsts with sanding off the resin, but bad results sanding off the die. So, I will probably be focusing on this hybrind technique in the future.

IC decapping round 1: very first IC images

2010-04-11T09:41:00.000-07:00

Some easy IC chips to work with are the old gold capped ceramic chips. Something like this:

This particular chip is labeled MD513 76R / 7407. Since a 7407 is just a line buffer, I can't imagine it being that complicated on silicon and it must be some military grade other chip with an obscure part number. I did find similar chips that were listed as DRAM, which seems consistent with the very regular, memory like die image. Although it took a bit of practice to figure out how to do this, you can use a heat gun to take the cap off. I tried doing this again the other day and I couldn't get the caps off. Thinking back, before I used a vice with a plastic jaw and held the chip in the end, just barley not burning it. This time I put it full in a metal vice which wouldn't release it even under extreme heat. Maybe I'll Dremel them slightly to get a small hole I can grab with pliers. In any case, this is what you get:

Well the first thing to try is to use a bright light and a magnifying glass or similar. I had a 10X objective from a projector, microscope, or something. Setup:

And an idea of the image quality you get:

You can just barely read the text on the die if you strain your eye, but probably not in that picture.
Next, a biological microscope was acquired. I seem to not have a picture of it, but later setups will anyway, and you probably used one at some point in your life or Google can help you. Anyway, you can now get pictures like this:

If you use the camera optical zoom, you can get slightly higher details and also eliminate that eyepiece ring. The biggest issue is probably that the zoom level is then a bit hard to tell. I need a standardized length object to calibrate against. Looks like this:
This was an old die I wasn't protecting well and you can see some dust on it. The electronics club is sorta the anti-cleanroom. More on how the camera was mounted, lighting and such later.
Oh and don't drive yourself mad trying to line up the pictures. I think they were from the same chip, but not entirely sure.

This blog

2010-04-11T09:30:00.000-07:00

This blog is my adventures as I try to unravel the mysteries of silicon based life. The ultimate goal would be to create a toolsuite that can take raw collections of chip images and convert them into VHDL or verilog. Under the hood it might use something like Hugin to stich the images together and Degate to create the netlists. I'd probably make the HDL decompiler as a stand alone program with a library core that could make tranformed into a Degate plugin.
There also a wiki setup at http://siliconpr0n.wikispaces.com/ to provide a more summarized form of what I learn. Another RPI student has been working with me on a few things here and there with this as well. Additionally, I'll probably be collaborating with Travis Goodspeed and Karsten Nohl throughout this process. Travis seems to be a big fan of chemical etch, where Karsten seems to favor physical etching techniques more such as using a Dremel. As I get better with the imaging process, I might see if I can get in touch with the Degate authors to provide patches and such.
I've already explored a few things and had some good starting results before I start writing this, so the first few posts will be about past results.