The end of myths -- solving one of our industry's nastiest of problems
In a series of past blog posts (first, second) I've described some of the myths surrounding component libraries. They were, in fact, merely symptoms of a chronic ailment of our industry -- I was using them as examples in order to ease my way towards the real problem.
Have you ever asked yourself why is it that 'design rule checks' (DRC) in your EDA tool do not point out apparently simple things such as signal polarity mismatches, wrong input voltages, wrong signal--pin connections, or wrong footprint dimensions? Or perhaps more "sophisticated" things like wrong/poor termination, impedance mismatches, or insufficient decoupling? Have you asked why is it that most DRCs are generally satisfied with simply automating the checking of distances between traces, pads, and pours when additionally pointing out electrical problems could save a lot of money to companies?
They cannot. I'm sure that many EDA companies thought of achieving the above, though it became very clear very soon that the data that must be available to achieve this "miracle" isn't there in a usable form. I'm talking about component meta data: dimensions, properties, functionality, and basically everything that's in tables and graphs in datasheets. For historical reasons, lack of standards, and probably a healthy portion of old-school lock-in fantasies, companies do not provide such data in a way that can be automatically processed. The best one can do today is parse PDFs or rely on "crowd wisdom", both of which don't really work for this problem.
It's a testament to the entrenched backwardness of our industry that despite knowing that a solution to this problem could very well unlock a world of innovative DRCs and tools -- and a lot of savings -- we and "they" still could not convince manufacturers to provide digestible component metadata, even if it was in something as simple as a CSV file*.
What can be done? Firstly, demand better tools -- don't fall into the 'digital Stockholm syndrome' trap of praising a bad tool just because you've spent years mastering it through an abusive relationship. Secondly, demand better data -- support manufacturers that aren't lazy with providing data, if and when those exist. Finally, be aware of the problem and support whoever is trying to do something about it.
* This isn't necessarily unique to the EDA business. I know of at least one thriving research field that could be completely eliminated if scientists bothered to provide metadata about their findings in a consistent way together with their publication.