Die shot features help - Page 1
Forum section: electronics / projects

author: dnotq
author_rank: Contributor
timestamp: July 01, 2020, 09:23:21 am
content: Hello,I'm trying to do a little investigation on a die for the AY-3-8910 sound chip. This is my first time trying my hand at figuring out the polygons, and I was hoping to get some tips or help in identifying some of the bits? There are several features that I thought looked like they might be obvious to a more trained eye.The first are some zig-zag metal layers on what I think are the pins for the 8-bit bi-directional bus. These pins are tri-state capable, and I was wondering if anyone knows what the zig-zag is?The next two photos are the main part of what I'm trying to figure out. I know this is one of four counters in the chip, 12-bit in this case, and it is fairly easy to see the segments of the 12-stages (probably the flip-flops that make up the counter). I have also included a close up of one of the stages.What I am ultimately trying to determine with this is, does the counter count up, or count down? Also, it has a reset or load feature, which would depend upon the direction it is counting. If it counts-up, then the would have to compare-and-reset. If it counts-down, it could have to zero-detect (on overflow most likely) and load. I believe the compare or load value is stored above the counter, and if it counts down then maybe the extra bit to the right of the lower-counter section is the overflow detection? This is all speculation at this point, I'm just wondering if this is clear or obvious to a more trained eye?In the detail image, the metal layer is clear, but the poly and other layers are a little harder to see (I think, I'm still trying to work out exactly what is what).Any insight would be greatly appreciated. And of course, thank you to Sean Riddle for decapping the chip and making the die shots!Thanks,Matthew

author: RoGeorge
author_rank: Super Contributor
timestamp: July 01, 2020, 09:38:44 am
content: I don't know to directly answer your question, but there are a few HDL implementations for that chip, and from there you might deduce the correct answer. That chip was already reverse engineered.First 3 results for a FPGA AY-3-8910 search:https://github.com/FPGA-Code/AS-2518-51_snd/blob/master/ay-3-8910.Vhdhttps://www.reddit.com/r/FPGA/comments/dzj8r3/reverseengineered_ay38910_chip_transistorlevel/https://opencores.org/projects/sqmusic

author: dnotq
author_rank: Contributor
timestamp: July 01, 2020, 10:56:23 am
content: Yes, I am aware of those. I am doing my own HDL implementation because there are bugs in those cores. I find a lot of HDL cores are done by programmers who don't necessarily understand hardware, or they take a software implementation from an emulator as a reference (which has the same problem, i.e. software is not hardware).In this case, there are comments in a lot of the emulators and subsequent forum discussions that say "the counters count up", despite the datasheet for the IC saying, over and over, that the chip counts down. Looking at the functionality from a "software perspective", sure, it seems counting up and comparing a value as >= would make sense. But that is not always true for hardware, and you can add a lot of subtle errors when you do something like that, especially when you are trying to make an accurate HDL core.I also like to verify my own information when doing things like this. I have reinvented a lot of wheels, either because I want to how the wheel works, or because all the other wheels out there are not quite right.There has been a lot of great work done already for sure, I am looking at those sources, and I appreciate all the work that has gone into them. I'm just trying to go a little further, standing on the shoulders of those before me, and try to confirm a critical aspect of the original chip so I can be sure my design is as correct as I can make it.I'm trying to learn to read the silicon and polygons so I can do my part and contribute to making the emulators and HDL cores better. It is a tall order, and I'm hoping there are some people out there who can help me along while I'm trying to figure it all out. Knowing what you are looking at, and knowing when you are right or wrong is critical when you are trying to learn.

author: amyk
author_rank: Super Contributor
timestamp: July 01, 2020, 10:03:53 pm
content: The first image shows a set of pin driving FETs. The fact that you misidentified/couldn't recognise that means you have a lot more to learn before trying to do any transistor-level RE.As for the counters - does it matter? They could be using inverted logic. XNOR chains, or something else. The only thing that matters in simulation is whether the outputs are correct.

author: dnotq
author_rank: Contributor
timestamp: July 02, 2020, 08:51:22 pm
content: Quote from: amyk on July 01, 2020, 10:03:53 pmI agree, I have *much* to learn. Do you have any suggestions on how to start? My usual way is to dive-in and see where it goes. I find that silicon-level IC design and layout is not exactly the kind of topic people are talking about on forums, blogging about, etc. so learning and getting feedback has been hard to come by so far. I have books on the topic, and I have been reading them, but books cannot tell me if my understanding is correct or if I'm interpreting some part of a die-shot correctly, etc.Quote from: amyk on July 01, 2020, 10:03:53 pmIt probably does not matter too much, but when possible I like to describe the hardware as accurately as I can. I tend to find that the designers of the real chips put a lot more thought into the silicon, and the way they did things was probably done for good reason, made things simpler, or worked better than some other method. If there is a nice side-effect of counting down vs counting up, because one method lends itself to nice coupling with other functionality, then I'm really interested in learning and understand that detail.Another reason is that I find when making assumptions, or doing something differently, when trying to make a reproduction (or emulator, simulator, or whatever term is preferred), it is very easy to introduce errors that are sometimes really subtle and hard to find.In this case, the direction of counting also helps explain how and when a register update from the host computer actually affects the counter. Does it happen immediately, or does it happen after the current cycle? There are also two parts to the counter, and does changing the MS-bits affect things the same as changing the LB-bits?Some of this can be characterized, and people have done a lot of good tests to suss out some information. But, when decapping has been done and die-shots are available, some of the assumptions can finally be definitively confirmed, or not, and everyone benefits.Rather than expecting someone else to do the work, I like to contribute where I can. In this case, unfortunately, I have a big learning curve in front of me, so I was reaching out for some guidance in trying to get my bearings.

author: dnotq
author_rank: Contributor
timestamp: July 02, 2020, 11:29:29 pm
content: Quote from: RoGeorge on July 01, 2020, 09:38:44 amRoGeorge: My apologizes, the reddit link you posted contained a link to this github repo:https://github.com/lvd2/ay-3-8910_reverse_engineeredWhich is actually a reverse engineering to schematic and Verilog model (simulation only, but great info) from an actual die-shot. I was too hasty to think I had already seen those links. Pretty much all of my questions have been answered now. However, I would still like to learn the skills to be able to perform that kind of analysis myself.Thanks again. My arrogance was uncalled for.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 03, 2020, 01:51:45 am
content: @gnif, it's happening again, the top image in this thread seems to be pulling from the attachment in this thread instead:https://www.eevblog.com/forum/fpga/xilinx-ise-how-to-improve-erratic-timing-optimization/msg3115150/#msg3115150Tim

author: RoGeorge
author_rank: Super Contributor
timestamp: July 03, 2020, 07:04:12 am
content: Quote from: dnotq on July 02, 2020, 11:29:29 pmNo apologies are necessary. Glad to hear you found the answers you were looking for, and yes, I would like to learn that skill, too, of reading schematics in silicon like reading them on paper.Quote from: T3sl4co1l on July 03, 2020, 01:51:45 amAll the 3 pics attached in the OP appear correct to me, 3 die shots, same content in thumbnails and when clicking on them.

author: Ysjoelfir
author_rank: Frequent Contributor
timestamp: July 03, 2020, 07:54:04 am
content: Quote from: T3sl4co1l on July 03, 2020, 01:51:45 amSame for me.

author: RoGeorge
author_rank: Super Contributor
timestamp: July 03, 2020, 08:25:45 am
content: That's strange, I still see all 3 pics correctly.Maybe some bugged version of the forum was replicated to different areas.Does EEVblog servers have any geolocation mirroring (Amazon cloud style, or similar)?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 03, 2020, 07:48:43 pm
content: We're on CloudFlare, but I don't know what if any caching is done. No amount of refreshing or cache-clearing fixes it; it's not my browser settings as far as I can tell.Tim

author: mawyatt
author_rank: Super Contributor
timestamp: July 03, 2020, 08:54:54 pm
content: Quote from: T3sl4co1l on July 03, 2020, 01:51:45 amTim,We get the same result? I'm using a a Mac, and maybe that's the issue?Best,

author: RoGeorge
author_rank: Super Contributor
timestamp: July 03, 2020, 10:55:32 pm
content: It was my browser who was caching something.If I open this page in a private window (Firefox/Ubuntu) or in another browser (Pale Moon), then first thumbnail opens a wrong picture, some Xilinx pinout.