Manufacturer part numbers in the grammar

[kasbah]

@dvc94ch I noticed that you are adding MPNs for semi-conductors into the grammar itself. I am wondering: is this the best place for them?

It might work well for really common parts but ultimately it embeds preferences into the grammar that we might not want to embed there. People's preferences vary and new parts are introduced all the time.

My approach for exact MPNs was going to be to use the ignored output of the lax parser to query a parts database. Maybe we should restrict electro grammar to parse specs but ignore MPNs? What are your thoughts on this?

[dvc94ch]

Aren't most diode and transistor mpn's structured? For other components it makes sense I guess, although what kind of information would you like to extract other than if it's a diode/transistor/ic?

From a hdl perspective it should be possible to compile without internet access, and compilation should be deterministic, so involving an online database is not ideal. I can introduce caching into the build system for when 'offline', so rebuilds would work.

[kasbah]

Structured how? I guess the manufacturers will follow a convention and there are a lot of common designs that are shared between different manufacturers. It may be a good optimization to include these in the grammar but I am not 100% convinced.

I didn't mean and online database necessarily, more like the a lookup like we do with the CPL parts.

In one of your emails you described the transistor support as something that would parse descriptions like "npn sot23 125mW beta=200 ic>=200mA" and that made a lot of sense to me.

[dvc94ch]

ah ok. there are as far as I can tell two standards in common use for discrete semiconductors. maybe a database would be better. the reason why I added the rules was because it was causing lexer ambiguity.

[0] https://en.wikipedia.org/wiki/JEDEC
[1] https://en.wikipedia.org/wiki/Pro_Electron

[kasbah]

Ah, I wasn't really aware of these. Will study them. Sorry, what was causing the ambiguity?

[dvc94ch]

it was parsing 1N4007 incorrectly as 1 nano or something like that.