Die ID location and design

[anfroholic]

Hey @mole99,

I figured this was the best place to continue this conversation about the ID location, design, and layer.

You posted:

One thing to consider: we should not specify a fixed position for the ID. Instead, we provide an abstract cell for the ID that the user can place anywhere on their die, which is later replaced with the generated ID. This allows to do custom padframes (or no padframes at all). I can extract the position of the ID cell during the precheck. With the location of the die on the reticle and the offset of the ID, you can position the camera above the ID. As for the layers, I would place the ID at Metal5 (topmost layer) with a no-fill shape around it. I assume this will give enough contrast. There are ways to achieve different colors with diffraction patterns, however, I'm no expert on that :)

I want to get @mithro in this as well. How large of an area do you think we can get away with?

From my perspective, this is to be read by a machine, so something like a QR code or data matrix would be preferable.

I can extract the position of the ID cell during the precheck. With the location of the die on the reticle and the offset of the ID,
Would this kind of info be added to the csv export?

Tim do you have any thoughts on if dies get subdivided in the future? I am thinking dead center and it does not matter if it exists after?

Thank you,
Andrew

[mole99]

Hi @anfroholic,

this place is fine. Although, the actual ID insertion happens at https://github.com/wafer-space/gf180mcu-precheck :)

The required size of the ID depends on the imaging system you have available. Unfortunately, I don't have much experience with that.

Machine-readable would be great. I had a look at QR codes, and it seems the minimum size is 21 x 21 pixels. We could store up to 17 characters with an ECC rate of 30% (high).

The minimum area of MetalTop constraints our pixels to a minimum size of 0.75um. This would give us a minimum size of 15.75um for one side of the QR code (which would probably be quite small).

At most, we could fit an ID of size ~125um x 125um in the corner.
I think a good size would be to scale each pixel to 5um x 5um for an ID of 105um x 105um.

Because a QR code generates pixels that only touch their neighbours at a corner, this would result in DRC errors.

We can either:

• Waive the QR code cell (not sure if it is possible to write waivers based on a cell)
• Add some small "bridges" where two pixels touch to get the design DRC clean

Let me know if we want to go ahead with a QR code as our ID.

---

@anfroholic I don't understand your comment on subdivided dies. In future shuttles, subdivided dies should be possible. Each die should have its own ID.

Leo

[anfroholic]

Thanks for the quick reply @mole99,

If ~125um x 125um is the smallest we can go I think that's not quite going to work?? I have machined things to tolerances below here, but have no feel for what they look like.

I was hoping for something near these scales.

It seems under any circumstance, there's just going to have to be a change in optics, which is less than ideal I think, but we can work with it.

I am hoping to meet with @mithro on Tuesday (Does meeting Tues around noon maybe work for you Tim?) and we can weigh our options.

Thank you again,
Andrew

[mole99]

Hi @anfroholic,

15.75um x 15.75um is the smallest we can go for the QR code.
~125um x 125um is the largest I would recommend, since this would still fit in a corner of the padring.

I think I understand your screenshot now. You want to distribute whichever code we use over all four corners?
I don't think that's a good idea. That would mean that customers would have to place four macros in their design if they choose to make a custom padframe/no padframe at all. For subdivided macros this also adds more complexity compared to a single QR code.

FYI the ID that Efabless used is 200um x 50um:

That's why I thought we could make the QR code in a similar size (e.g. 105um x 105um). But it seems in any way we need better optics to resolve the features.

Thanks,
Leo

[mithro]

@mole99 / @anfroholic - Could of random thoughts (in no priority order);

• I'm generally okay with having a bigger identifier which makes it easier for people to identify things. (Even if it makes people grumble about wasted space on the top metal.)
• It would be nice if people with crappy USB microscopes could identify their parts. It would be even better if a modern phone camera could be used to identify parts.
• It would be good to have some type of "pin 1" corner marker so that orientation can be detected.
• Putting things in the corners seems like a good idea?
• Ultimately @mole99 has to implement whatever ID stuff we want and @anfroholic needs to be able to read it automatically as part of the die sort.

[mole99]

Hi @mithro / @anfroholic, here are my additional thoughts:

Putting things in the corners seems like a good idea?

Yes, because it doesn't waste any usable space. It would otherwise be filled with dummy metal.

I'm generally okay with having a bigger identifier which makes it easier for people to identify things. (Even if it makes people grumble about wasted space on the top metal.)

If we make the ID any bigger, we cannot place it in the corner anymore. It would need to be placed inside the design, which would take away routing resources and block the PDN straps. I would advise against this.

It would be nice if people with crappy USB microscopes could identify their parts. It would be even better if a modern phone camera could be used to identify parts.

I agree. However, I don't think it's important to be able to use the phone's camera at the expense of the actual chip design.

It would be good to have some type of "pin 1" corner marker so that orientation can be detected.

The "eyes" of the QR code enable determining its orientation. We don't need an additional marker for this. If you place the QR-code in e.g. the bottom-left corner, it by itself can act as the pin 1 marker without even being decoded.

---

@anfroholic has sent another image to the Discord chat, this time with a cheap usb micorscope. At this resolution (or a slightly better one), it may already be possible to read the QR-code, as the corner is well visible.

---

I would recommend the following:

• Using a QR code to store an ID and get the orientation.
• Placing it in one of the corners (default padring).
• Making the QR code as big as possible while still fitting in the corner.

[anfroholic]

Thanks @mole99,

There has been a bit more discussion with @mithro personally and on the discord.
I think I have pretty much conceded on wanting things to as large, but would like for us to be as considerate to people who don't have the best equipment to still be able to read these.

Personally I am veering towards Data Matrix as the preferred format.
In this case and with QR codes you can just make them up of dots so that shouldn't be a problem for the DRC checks. Let me know if there are other concerns in this area.

I feel like we should shoot at the ~125um x 125um for the size if you think that is still good--and any um would be good where we can get it.

The density likely will be in the 22x22 - 24x24 pixel range for the data density to put a whole URL.

Please let me know if there are any more questions/concerns. Thanks

[mole99]

Hi @anfroholic,

Dots are going to be even more of an issue for DRC I assume :)

We can go with ~125um x 125um for the size.

I would go with the lowest density possible and the highest ECC rate you can get. After all you want people who don't have the best equipment to still be able to read these ;)

Your reason for the data matrix is the higher density?