wafer.space Community - waferspace_die_sorter/discussions/id

7:48 a.m.

Hi @Andrew Wingate, why do you prefer a data matrix over a QR code?

Data matrix is my personal choice for now. 

At macro scales this can also be used as pin 1 designator

They also can be dots and not full squares.

This all applies to QR-codes as well, doesn't it? I would say that the orientation is easier to decode in a QR-code. If there's no major benefit to a data matrix, I would choose a QR-Code. Simply because for "normal" users this is much easier to read (it is supported by a lot of software nowadays). What is the maximum ECC you can get for a data matrix?

This all applies to QR-codes as well, doesn't it?

It does yes I also believe data matrix does not need an orientation to read. Seems you can lose 30% with Data_Matrix_ECC_200 I think the benefit is size but I have not done the math

Data Matrix

A Data Matrix is a two-dimensional code consisting of black and white "cells" or dots arranged in either a square or rectangular pattern, also known as a matrix. The information to be encoded can be text or numeric data. The usual data size is from a few bytes up to 1556 bytes. The length of the encoded data depends on the number of cells in the...

Leo Moser (mole99)

Hi @Andrew Wingate, why do you prefer a data matrix over a QR code?

Data matrix is my personal choice for now. 

At macro scales this can also be used as pin 1 designator

They also can be dots and not full squares.

This all applies to QR-codes as well, doesn't it? I would say that the orientation is easier to decode in a QR-code. If there's no major benefit to a data matrix, I would choose a QR-Code. Simply because for "normal" users this is much easier to read (it is supported by a lot of software nowadays). What is the maximum ECC you can get for a data matrix?

QR codes are similar but need more dots per stored bit

7:57 a.m.

I thought your main concern was being able to reliable read these? If so, I would go with QR-codes, lowest density and highest ECC. I would just store the first 8 places of a hash ("AABBCCDD") to distinguish the dies like Efabless did. People can always add more "Chip art" if they feel like it.

Leo Moser (mole99)

I thought your main concern was being able to reliable read these? If so, I would go with QR-codes, lowest density and highest ECC. I would just store the first 8 places of a hash ("AABBCCDD") to distinguish the dies like Efabless did. People can always add more "Chip art" if they feel like it.

I think the bar has slid towards a url. Machine readability makes things super easy for me. With a cheap microscope you should be able to read one if we get to use the whole area in that corner. (That is the 125um square, correct) example in pasted pic This choice may make things a little harder for me, but that can remain my problem, but should be easy enough for someone with cheap tools to resolve--keep in mind that I was unable to resolve any of the numbers with the Efabless versions of the numbers.

Whatever you do, please don't use a URL shortener. It wouldn't be great to scan the dies after 10 years have passed, just to see that the URL is dead

8:23 a.m.

Yes, we can use that area.

8:24 a.m.

Although, I'm wondering why the corner is differently colored...

8:24 a.m.

We might even get 140x140um

The density may be very similar, so I am going to say it makes little difference to me. I suppose more people would recognize a qr code as something they can get information from, so that may be the best choice in the end.

1

Leo Moser (mole99)

We might even get 140x140um

Thanks! I can try testing a few things, but my gut says there is enough resolution here not to worry You mentioned something about the dots causing problems? What would work best?

Arbitrary angles aren't allowed in the GDS afaik. We can use 45° angles however. I'll look into it.

Something like this is a compromise, but there will always be single dots some places

8:28 a.m.

Yes, but with 45° angles the corners won't touch, so it should be fine :)

I'm sure octagons could work

No, here you have edges touching

These are diamonds, but was just showing a few of the options

1

8:30 a.m.

Ignore my artistic skills ^^

haha yes, if those are easy for you, I don't see why that's not viable.

1

Nevertheless, I would still use the lowest density QR-code. As you said, having such a small ID will make your life difficult, so why make it even harder by increasing the density? If the URL fits in the given encoding, use it. Otherwise, use a hash.

This is another example, but figure some regular pattern is easiest for you

Yes, a regular pattern would be nice.

8:33 a.m.

Whatever will be decided on, I can already get started with the QR-code generator.

Leo Moser (mole99)

Nevertheless, I would still use the lowest density QR-code. As you said, having such a small ID will make your life difficult, so why make it even harder by increasing the density? If the URL fits in the given encoding, use it. Otherwise, use a hash.

Tim has told me to get over myself

So we can disregard a lot of that.

The main purpose of the ID is to enable automatic sorting of the dies. Therefore, we should use what works the best for this. A hash would suffice. If not, you need to be ready to invest a bit more into microscope equipment to be able to read the ID. (And some people might not be able to read it with their equipment.) If you want a URL in the layout just for "coolness" (I get it

) you can simply add it to some projects. In the core are you're not limited by size and can scale it up so that even a phone camera can read it. @Tim 'mithro' Ansell something to think about. (edited)

1

I think the die ID for sorting can be different to any url / project info ID?

I agree. And the die ID should be the only requirement for tapeout. Users can include a project URL or ID in their core area if they wish and if applicable. For example, I don't think a URL would make sense for proprietary designs.

@Leo Moser (mole99) - Here is a potentially horrific idea -- Librelane should have a (optional) pass which adds an "Open Silicon Chip Identifier" into the top metal fill?

That's not a horrific idea, that's actually what I'm doing the precheck flow :) I added a custom step that replaces the ID in the dummy macro with the actual ID that we want to set.

@Leo Moser (mole99) - I mean one which is kind of like the OSHWA registered ID or something?

2:19 p.m.

BTW I was thinking it would be good if the chip ID was something like <processtech><runid><projectid><checksum> - processtech == 1 character, runid == 2 characters, projectid == ??? character -- "Character" could be a-z0-1 eliminating the confusing ones like l/1 and 0/O ?

LibreLane already has the functionality to add macros to your design. I'll push my changes soon so that you can see how that is done. If you like, I can create some DRC-clean logos that users can add to their designs if they wish (e.g. wafer.space, OSHW).

Tim 'mithro' Ansell

BTW I was thinking it would be good if the chip ID was something like <processtech><runid><projectid><checksum> - processtech == 1 character, runid == 2 characters, projectid == ??? character -- "Character" could be a-z0-1 eliminating the confusing ones like l/1 and 0/O ?

That should be possible. I think we have 8-10 characters with the highest ECC rate. I'll have to check again later.