Add cmp & dev for OPA858 and LMH6629

[eto-]

SUMMARY

• Added wson8 2x2 mm and 3x3 mm packages.
• Added opamp with compensation components.
• Added devices
  • LMH6629
  • OPA858

DATASHEETS / REFERENCES

https://www.ti.com/product/OPA858
https://www.ti.com/product/LMH6629

OPEN QUESTIONS / UNRESOLVED ISSUES

• WSON8 package is specific to TI
• On could argue if the opamp with compensation components has to go to a generic library, but I'm not aware of other devices of other brand with this configuration.

CHECKLIST

• [x ] I have read and followed the library conventions¹.
• For packages, I followed IPC7351C (see details in library conventions).
• For modified elements, I bumped their version number².
• [x ] I already used the new library elements in a design and verified their correctness (optional).
• [x ] I'm the copyright owner of the added content (i.e. the changes are made by myself, not copied/imported from somewhere else).
• [x ] I agree to publish all my changes under the CC0 Public Domain License³, allowing everyone to use and modify the content without any restrictions.

¹ Library Conventions: https://docs.librepcb.org/#libraryconventions
² Minor version bump if only metadata was modified (e.g. "0.1" -> "0.1.1"), major version bump if functional changes were made (e.g. "0.1" -> "0.2")
³ CC0 Public Domain License: https://en.wikipedia.org/wiki/CC0

[eto-]

news?

[ubruhin]

Sorry, I'm very busy these weeks :/ I did not forget it, I'll try to review soon.

[ubruhin]

I took a look at the datasheet now. as far as I can see, the packages look standard - even if the actual dimensions are non-standard, it makes sense to generate them with our generator. I even wonder if the DFN generator would already be able to generate WSON packages 🤔

The DFN generator also already generates packages with non-standard dimensions:

https://github.com/LibrePCB/librepcb-parts-generator/blob/64cf5e9adba65b4bd0399cb730411f7aef8704bb/dfn_configs.py#L399-L412

But the package is located in the Base library anyway, because the shape is standard, and the non-standard dimensions are encoded in the package name. I think this would make sense for the WSON packages too.

However, unfortunately at the moment I really don't have time to work on that - even for reviews it's hard to find time :-( Thus I'd suggest to leave this PR as-is for now. I'm really sorry for that, I know this situation is not satisfying.

[eto-]

I checked the dfn_config.py and I think it is enough to add these 2 lines
DfnConfig(2.0, 2.0, 0.5, 8, 0.75, 0.8, 0.30, 1.6, 0.9, 'WSON-2mm,WSON', False), # no nominal exp_pad
DfnConfig(3.0, 3.0, 0.5, 8, 0.75, 0.8, 0.40, 2, 1.6, 'WSON-3mm,WSON', False), # no nominal exp_pad

I'm not sure which keyword would you prefer, therefore I did not apply for a PR on the parts_generator repository.

[ubruhin]

That would be awesome if these two lines create the correct packages! Regarding keywords, I think "wson8,wson-8" should be fine.

I'd be happy to receive a PR in the parts generator repository :)

[eto-]

The only difference is that the original texas instrument package does not have the engraved dot on pin 1.
But it is very very minor.

[eto-]

I updated the devices with the dfn package.

[ubruhin]

Oh no, I just realized there are also issues with the components 🙁

The datasheets clearly state a separate pin for FB. Even though it is internally connected to OUT, the component should provide it as a separate pin because that pin is specifically made for the feedback circuit. Therefore we need to add a new symbol & component.

Also I'd swap the Comp and EN pins for consistency with the other OpAmps (EN at top), but that's a minor issue.

And the new component should rather be added to our integrated circuits library, since it is generic.

[eto-]

Oh no, I just realized there are also issues with the components 🙁

I would call them a feature

The datasheets clearly state a separate pin for FB. Even though it is internally connected to OUT, the component should provide it as a separate pin because that pin is specifically made for the feedback circuit. Therefore we need to add a new symbol & component.

I strongly disagree on this: the FB pin is there to shorten the feedback loop in the WSON which is 3x3 mm. It is needed because the LMH6629 has a very high GBP and it is not compensated for Av = 1. But this is a caution needed for the PCB and not for the schematics. Whoever want to use a chip with a bandwidth extending to GHz has to take precaution for long loop: this pin is just a courtesy (to avoid components on the bottom layer).

Schematics with the FB pin would hide the feedback loop creating confusion to gain practically nothing. As you see all the schematics in the datasheet are all with the classic symbol and even literature use the standard symbol:
https://arxiv.org/pdf/2403.02948
https://arxiv.org/pdf/1706.04213

You can argue that the schematics for the LMH6629 are shared with the sot version, which has not FB pin and therefore a generic schematic with the FB pin could not be used. However the same can not be said for the OPA858 that exists only in WSON package with the FB pin as well. Here the vendor show the FB pin only a PCB drawing and not in the corresponding schematic:

If you really really want to change the components, please use different UUIDs, so that I can keep my own local version.

Also I'd swap the Comp and EN pins for consistency with the other OpAmps (EN at top), but that's a minor issue.

This is not a problem.

And the new component should rather be added to our integrated circuits library, since it is generic.

In my knowledge this configuration is only present for the LMH6629, therefore I added here: but I have no problem if you want to change.

[ubruhin]

I understand your point and I agree it would be nice if the schematic was independent of the package. But unfortunately, it is not that easy.

If you use a single component signal for OUT and FB, you will end up with several problems in the board editor:

1. The airwires do not guide you to connect the feedback resistor to pad 1. It will just pick the closest of pad 1 and pad 6, so if the feedback resistor is initially located closer to pad 6, it will guide you to connect it to pad 6 which is misleading.
2. The DRC does not verify that you connected the feedback resistor to pad 1. It will be happy if you connected it to pad 6.
3. Since pad 1 and pad 6 are both connected together in the schematic (resp. in the component), air wires & DRC even force you to connect both pads to the same net in the board, i.e. they tell you to connect them with a trace, which would be totally wrong.

This can only be avoided by having two separate component signals, ending up with two separate nets in the schematic. Then the airwires and the DRC will guide the designer to do the right thing. IMHO this is a huge benefit compared to the rather small drawback of having separate components.

This is a case where components cannot be as generic as we would wish they are. Sometimes such special cases exist, and my opinion is clearly we should then go the safer, more intuitive way than following the ideology of generic components.

It is clear that in datasheets the symbols have only one OUT signal, because those are just drawings, not schematics from which a PCB is made of.

Btw KiCad also does it this way. It doesn't mean anything (sometimes I disagree how KiCad is doing things), I was just curious so I checked it:

[eto-]

3. Since pad 1 and pad 6 are both connected together in the schematic (resp. in the component), air wires & DRC even force you to connect both pads to the same net in the board, i.e. they tell you to connect them with a trace, which would be totally wrong.

This is the only argument: for the rest a designer that creates long loops in a multi-GHz amplifier has bigger problems than the suggestion of the program for the right place where to connect the resistor.

In general it should not be mandatory to short pads with the same name.

This can only be avoided by having two separate component signals, ending up with two separate nets in the schematic. Then the airwires and the DRC will guide the designer to do the right thing. IMHO this is a huge benefit compared to the rather small drawback of having separate components.

The component is already separated, since there is one specific for either LMH6629 and OPA858. My issue is about readability of the circuit.

In past I saw variants with the FB pin next to the in- pin (on the left-side): and these are a no go for me. The design of kicad is not my preferred solution but it is acceptable.

[ubruhin]

for the rest a designer that creates long loops in a multi-GHz amplifier has bigger problems than the suggestion of the program for the right place where to connect the resistor.

Generally I agree, but from out point of view as maintainers it is also our responsibility to avoid any wrong/misleading guides by the tool, as this would raise new complaints by other users ;)

In general it should not be mandatory to short pads with the same name.

It depends on the component. For a microcontroller with 5x GND pins it is important to connect all of them, so the current behavior of LibrePCB is correct for those. But I have also thought that we might need a different mode too, such that the library designer can choose between "connect any of those pads" and "connect all of those pads". I think this is a valid feature request.

My issue is about readability of the circuit.

I'd say with the KiCad variant the readability is affected only very little (though I'd put the FB pin below OUT, since our negative input is at bottom too).

So how do you like to proceed? I'd really prefer to add the "safe" variant without misleading airwires/DRC to the libraries, but if you disagree, of course you can do it the other way in your local libraries.

[eto-]

So how do you like to proceed? I'd really prefer to add the "safe" variant without misleading airwires/DRC to the libraries, but if you disagree, of course you can do it the other way in your local libraries.

Ok proceed with the "safe" variant. Keep the current UUID, I will change my design when needed.
Do you want me to change the symbol?

[ubruhin]

OK great. I think I can take care of the symbol & component in the IC library, I'll try to do it in the next few hours.

[ubruhin]

See LibrePCB-Libraries/LibrePCB_ICs.lplib#43. Would be nice to get a review :)

Do I see correctly those two configurations are very very specific to the OPA858 and LMH6629? I'm now struggling a bit whether those components should really be generic if no other devices will use them 🤔 But if in doubt, maybe generic components are still better than specific components...

[eto-]

See LibrePCB-Libraries/LibrePCB_ICs.lplib#43. Would be nice to get a review :)

Do I see correctly those two configurations are very very specific to the OPA858 and LMH6629? I'm now struggling a bit whether those components should really be generic if no other devices will use them 🤔 But if in doubt, maybe generic components are still better than specific components...

Yes the configurations are VERY specific to those ICs, that's why I put the the sym and the cmp initially in the TI library. I do not know any other device, i.e. from Analog, with a simular structure.

[ubruhin]

Symbols are now merged into the ICs library. Components and updated devices are pushed to this PR. I hope it is now everything fine.